Really stupid things that people have said about Modded MC(Off topicness makes moderators tired)
- Thread starter Qazplm601
- Start date
- Status
Computer back up, just so you know, what I was talking about at the end was my idea for adding a basket to hold food, flowers, dirt and other such items, and I've made it so that dirt drops dirt piles instead of blocks and a variety of new foods and items
Well, you could re-add all of the existing recipes through the reflective invocation of RotaryRecipes.addRecipes() or just doing it before RC's load phase.
Generally, yes. However, there are also some recipes added in post init, usually ones involving mod materials, and these recipes are not added by the global addRecipes function.
Also please ensure you are not bypassing isLocked() on the three mods that have it.
You have many mods! I think I'll add DragonAPI as a soft dependant to make my postinit remove the recipes occur before yours are added. I'll double check that all your recipes remain intact.
I'm just curious Is there a certain number of entities. This might be a dumb question because I know zero code.
That's not how it works. Their IDs are stored in an int, which in Java, is 32 bits (or 4 bytes) no matter what. Metadata is a different matter (not to mention a different data field) entirely. Unless you work your arse off with bitwise operators, you can't even manipulate data that's less than 8 bits in size; even a boolean (which is either true or false) is always, at minimum, 8 bits.
When IDs have a fixed limit (technically, they're all limited, but I'm speaking of a limit below MAX_INT), that typically means that what they're doing is creating an array of blocks (or items) of a fixed size. That is bad design. One, its inflexible: if you want to resize arrays in most languages (raw arrays, not wrapped arrays like ArrayLists in Java or vectors in C++), you'd have to create a new array of the desired size and copy over the original array, something that is extremely cumbersome, and is thus almost never used as most people who want or need such functionality will go for the standard array wrapper classes available to them. Two, its inefficient: if you have less than the maximum number of blocks and/or items allocated, you're wasting space, since every member of the array exists in-memory as a blank instance of the appropriate type. Granted, two is somewhat mitigated because blank instances don't have as much data as regular instances, but that's still wasted space.
And, seeing how Mojang waited until the game had been around (and popular) for several years before releasing a critically needed overhaul on their obscenely badly-designed engine, do you honestly expect them to take the efficient, sensible option first, when a sloppy kludge is available that gets the job done faster? Ya don't need a degree to know some design decisions are just...bad. Minecraft may have started out as an indie project by a lone dude (and maybe his friends, I dunno when Jeb and Co. joined in, exactly), but once it started showing signs of being popular, Notch really ought to have taken the time to refactor the code and make it not only make it more efficient and more stable, but also make it more easily-extensible to speed along future content additions.
One of the first rules of programming I learned a long time ago: raw arrays are bad. Avoid them like the plague whenever possible.
But I think that's how they're stored on the disk. I don't know how chunk data is being stored in memory, but storing IDs and metadata as fully fledged 32 bit integers would severly increase the size of savefiles.
I agree it's suboptimal though.
If the number of elements doesn't change after the array is created it's fine to use them. If the number is dynamic then indeed an ArrayList or some other data structure is better.
If you are talking mobs then yah there are like 2 mods that add a whole mess of them that can't be used together.
Celestialphoenix
Too Much Free Time
- Status