Yea I was wanting to add the items to the chests already saved in the region files. Which I guess means reading the nbt data. Which I was hoping there was a way to do this. With either a tool or some sort of code that doesn't involve having to read through the files byte by byte and make my own parser
Couldn't you just tag the parsed chests's NBT's and then avoid the chests with tags the next run through? And by hooking into when a player sets a chest you could add the tag and prevent any future duping of items
So it takes time? So if it's a waste of your time why should someone should spend their time making something you want...? Because you think it's a good idea? There's plenty of good ideas out there. Issue is that no one wants to bring their own ideas to fruition.
this was his idea (and most of mine) so unless we give you permission, no! not our ideas! make your own ideas!
Pretty sure fetus_tree was the first to mention it-
But hey it's not like coloring torches has already been put in other games like Terraria /sarcasm
And you can stop him- you'll just need to prove your intellectual property over the concept, preferably via patent.
you love modding? i need help over here on my elemental mod elemental destruction mod i think of ideas and itms and crafting, you do the coding, and someone else does the textures!
No thanks, I'd much rather do my own thing at my own pace, which usually renders very little releasable content these days
Well I don't mean have the color of glow around the torch/glowstone colorful. I know that would be very hard to code, though it would be awesome if that was possible.
It's not all that difficult to code- it's been done if you look at some betas and alphas in the past- The issue is updating, It's really... tiring going through and making the same changes with each release- going through every class that has to do with lighting and applying your patches. And the lighting system is a bit unique to say the least Hex code is integer based so you could just follow that with the lighting system- but it's a lot of patching to get done
The idea is a pretty simple one too- you wouldn't even have to create new textures- just make a special block renderer to color the vanilla torch and viola it's done
I have yet to find an issue with FML 1.8- All the mod loading capabilities are there.
The issue is for the mods that utilize forge's hooks. But if they really wanted modders could ASM in their required hooks and be entirely up to date.
But hey definitely worth someone's else's time to get you a few components from 1.8 because you're too impatient to either A] learn to do so yourself for yourself or B] to wait a few weeks or so for Lex to port the hooks into the new code. I mean totally worth someone else's while- it's not like the time and effort you're asking from someone else will be thrown out with a single 1.8 forge release. It's not like they could actually spend their time making something new, enjoyable and unique that will be relevant for more than a single version of minecraft. While we're at it why not port everything back from vanilla 1.8 so that you can play old and outdated mods in 1.1? Wait just a darn minute, it'd probably be a bit easier to port the outdated mods forward... and woah then you can continue to update the mods so you can have all the future features... without the mod guaranteed to become redundant in future minecraft versions.
How would I go about writing a coremod to stop the thing that loads coremods from crashing?
I don't take anything he says about fixing this as good as he has said he wants to shame people into not using 1.6.4 or 1.7.2 anymore.
Justifiable shaming. He puts how much effort into getting the forge platform up and running for the community at large and the community refuses to move forward because what? Laziness? His hard work put to waste because of modders not wanting to update? Pretty insulting that his time and effort supplying a free and stable API gets ignored because people don't want to "waste" their time porting their mods forward and then complain that new java releases are messing up old and outdated forge releases.
If you want a real fix you should uninstall the latest JRE and install a previous working version since it doesn't require demanding further work from anyone but yourself. I mean you're fine using an outdated forge build, why not an outdated java build too?
Actually if you think about it, it is good coding practice. It is explicit and clear. It might be a bit of a bother, but it is the whole point of parent-child stuff. Think of all the coders that prefer to use "this." everywhere. Again it is a bother, but it is also explicit and clear.
Fun fact, it comes out the exact same in the resulting byte code. this triggers loading the same object as just calling an in class method. All comes down to appearances, like spacing and brackets.
As an example very single entity has a super call to its parent class in the constructors.... Not bad practice. Necessary in java. If you think about it, calling to the super method sure as hell beats copying the parent method and injecting it into each child.
An issue I can see coming up if you use a .obj file is the ease of access to changing it which minor editing like opening and closing/saving it in the program it wasn't made in can corrupt the file. Most of the corruption would be minor and hard to tell, for example, a vertex could follow a bone other than its parent, minor issue but could brake the overall experience...
.obj importing is a fairly common method now with the forge object loading... and yeah it may result in a more fragile modfiles if people open them and rummage around... but that's not really the issue of the modder's or the general user if people are rummaging through the files.. especially when mods tend to stay in their happy little zip files. It's more for if someone wants to just throw their own models in that it'd be beneficial, as well as increasing the efficiency of adding new models on my end
Currently the set up will be DRASTICALLY different(should be much more efficient), And I've decided to make the planning public so that the community can have some input
Plans so far:
Game Mechanics
Okay to start out with, there is going to be more emphasis on integrating it into Minecraft instead of trying to create a standalone which took forever and ended up with a lot of glitches in builds.
Pikmin seeds are instead an Item which must be cultivated like crops. Still given by an Onion, and throttled to limit to 100(default) Pikmin in the field at a time.
Treasure randomly generates like structures and also will pop out of certain mod enemies and can be exchanged for emeralds.
Onions will instead be generated like End portals. Limited number per map. You will have to find them in game. They will instead follow the Pikmin 3 style onion, And will be movable (how so far I do not know)
Mod Enemies will be quite tough to kill as a player. Non mod enemies will be difficult to kill with Pikmin. Keeping an eye on balance here.
Nectar will be cultivatable.
Onions are fully functional.
Treasure can be redeemed at a special building in villages.
Will integrate as many game enemies as possible.
System mechanics
I plan on having 3 levels of detail for the Pikmin, fast, classic, and fancy:
Fast will be 2D sprites, think Wolfenstein or DOOM, making the drawing of Pikmin easier on the GPU
Classic will see the return of the blocky 3D Pikmin from the original mod
Fancy I want to upgrade to blender models (.obj format). May be a little taxing on some(most) GPUs.
SMP integration will be present from the get go. Will have everything disabled in non enabled servers (no more Bulborb spam in SMP)
Instead of trying to remember carrying coordinates, Pikmin will follow Steve(last player to direct them) with what they are carrying until they can see a location to drop it off at.
Settings will be allowed to adjust max no. of Pikmin, so that you do not need to worry about killing your pc with the mod once set up.
Treasure will have its own scripted setup. So instead of spamming the mod with classes, a resources folder will be parsed for carry formation, model file(.obj), and textures will be loaded at start up, meaning people can add their own treasures if the so desire.
Code will be backed up ONLINE. So if my PC blows up it's not lost again.
Items
Pikmin seed: Allows for planting of Pikmin
Whistle: Allows for calling of Pikmin as well as setting a way point.
Spray bottle: Reusable potion bottle that sprays the contents for AOE effects, has a set durability.
Spicy potion: Increases attack and speed of Pikmin only. Imbibing sets fire to the consumer.
Bitter potion: encases entity in stone for a limited time, halts movement, causes flying mobs to fall.
Overall there will be a ton of work to keep my free time sparse... Hopefully not too much though So feel free to post your ideas and outlooks on the second rendition!
I think it would be cool to make a mod that adds player AIs where they would mine, build, farm, explore, etc. and maby some of them would try to raid your chests or maby attack you if u try to grief/raid their stuff. It would probably be a complex mod but it would be awesome
or you could just use SMP and get all that with unparalleled AI
can you please update it to work in 1.5 I don't want to downgrade my minecraft. Thanks!
As I've said I've lost all mod content. The style I used for this was... slow and inefficient to say the least. If and when I pick this mod up again (hopefully with something better than a netbook) it will be entirely rewritten in forge with server sided integration.
0
Couldn't you just tag the parsed chests's NBT's and then avoid the chests with tags the next run through? And by hooking into when a player sets a chest you could add the tag and prevent any future duping of items
0
0
0
Pretty sure fetus_tree was the first to mention it-
But hey it's not like coloring torches has already been put in other games like Terraria /sarcasm
And you can stop him- you'll just need to prove your intellectual property over the concept, preferably via patent.
No thanks, I'd much rather do my own thing at my own pace, which usually renders very little releasable content these days
0
It's not all that difficult to code- it's been done if you look at some betas and alphas in the past- The issue is updating, It's really... tiring going through and making the same changes with each release- going through every class that has to do with lighting and applying your patches. And the lighting system is a bit unique to say the least
The idea is a pretty simple one too- you wouldn't even have to create new textures- just make a special block renderer to color the vanilla torch and viola it's done
0
The issue is for the mods that utilize forge's hooks. But if they really wanted modders could ASM in their required hooks and be entirely up to date.
But hey definitely worth someone's else's time to get you a few components from 1.8 because you're too impatient to either A] learn to do so yourself for yourself or B] to wait a few weeks or so for Lex to port the hooks into the new code. I mean totally worth someone else's while- it's not like the time and effort you're asking from someone else will be thrown out with a single 1.8 forge release. It's not like they could actually spend their time making something new, enjoyable and unique that will be relevant for more than a single version of minecraft. While we're at it why not port everything back from vanilla 1.8 so that you can play old and outdated mods in 1.1? Wait just a darn minute, it'd probably be a bit easier to port the outdated mods forward... and woah then you can continue to update the mods so you can have all the future features... without the mod guaranteed to become redundant in future minecraft versions.
0
0
Justifiable shaming. He puts how much effort into getting the forge platform up and running for the community at large and the community refuses to move forward because what? Laziness? His hard work put to waste because of modders not wanting to update? Pretty insulting that his time and effort supplying a free and stable API gets ignored because people don't want to "waste" their time porting their mods forward and then complain that new java releases are messing up old and outdated forge releases.
If you want a real fix you should uninstall the latest JRE and install a previous working version since it doesn't require demanding further work from anyone but yourself. I mean you're fine using an outdated forge build, why not an outdated java build too?
Nope FML loads coremods. Forge is the API back end with the additional methods and the events for hooking into vanilla methods without ASM.
0
Fun fact, it comes out the exact same in the resulting byte code. this triggers loading the same object as just calling an in class method. All comes down to appearances, like spacing and brackets.
As an example very single entity has a super call to its parent class in the constructors.... Not bad practice. Necessary in java. If you think about it, calling to the super method sure as hell beats copying the parent method and injecting it into each child.
0
.obj importing is a fairly common method now with the forge object loading... and yeah it may result in a more fragile modfiles if people open them and rummage around... but that's not really the issue of the modder's or the general user if people are rummaging through the files.. especially when mods tend to stay in their happy little zip files. It's more for if someone wants to just throw their own models in that it'd be beneficial, as well as increasing the efficiency of adding new models on my end
1
Original mod:
http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/wip-mods/1439757-wip-v0-5-pik-mine-1-2-5-outdated-dead
Currently the set up will be DRASTICALLY different(should be much more efficient), And I've decided to make the planning public so that the community can have some input
Plans so far:
Game Mechanics
Pikmin seeds are instead an Item which must be cultivated like crops. Still given by an Onion, and throttled to limit to 100(default) Pikmin in the field at a time.
Treasure randomly generates like structures and also will pop out of certain mod enemies and can be exchanged for emeralds.
Onions will instead be generated like End portals. Limited number per map. You will have to find them in game. They will instead follow the Pikmin 3 style onion, And will be movable (how so far I do not know)
Mod Enemies will be quite tough to kill as a player. Non mod enemies will be difficult to kill with Pikmin. Keeping an eye on balance here.
Nectar will be cultivatable.
Onions are fully functional.
Treasure can be redeemed at a special building in villages.
Will integrate as many game enemies as possible.
System mechanics
I plan on having 3 levels of detail for the Pikmin, fast, classic, and fancy:
Fast will be 2D sprites, think Wolfenstein or DOOM, making the drawing of Pikmin easier on the GPU
Classic will see the return of the blocky 3D Pikmin from the original mod
Fancy I want to upgrade to blender models (.obj format). May be a little taxing on some(most) GPUs.
SMP integration will be present from the get go. Will have everything disabled in non enabled servers (no more Bulborb spam in SMP)
Instead of trying to remember carrying coordinates, Pikmin will follow Steve(last player to direct them) with what they are carrying until they can see a location to drop it off at.
Settings will be allowed to adjust max no. of Pikmin, so that you do not need to worry about killing your pc with the mod once set up.
Treasure will have its own scripted setup. So instead of spamming the mod with classes, a resources folder will be parsed for carry formation, model file(.obj), and textures will be loaded at start up, meaning people can add their own treasures if the so desire.
Code will be backed up ONLINE. So if my PC blows up it's not lost again.
Items
Pikmin seed: Allows for planting of Pikmin
Whistle: Allows for calling of Pikmin as well as setting a way point.
Spray bottle: Reusable potion bottle that sprays the contents for AOE effects, has a set durability.
Spicy potion: Increases attack and speed of Pikmin only. Imbibing sets fire to the consumer.
Bitter potion: encases entity in stone for a limited time, halts movement, causes flying mobs to fall.
Overall there will be a ton of work to keep my free time sparse... Hopefully not too much though
1
or you could just use SMP and get all that with unparalleled AI
0
0
As I've said I've lost all mod content. The style I used for this was... slow and inefficient to say the least. If and when I pick this mod up again (hopefully with something better than a netbook) it will be entirely rewritten in forge with server sided integration.
0
public ModelBiped getArmorModel(EntityLiving e, ItemStack i, int s){}you may need to wrap the model biped renderers