Hm, I thought of something.
Usually, we don't have problems with item ids, but we have problems with managing used\unused block ids
so, why can't we change game behaviour in a way:
that it thinks of blocks not of block ids, but rather then specific pattern of items\an block recepie?
so example - we have a machine block, which is 8 ref. iron - when we craft it it turns from 8 irons to a block with specific id, but can't we hold this new entity as a
"itemname" (somewhat like block id)+ "recepie" (which is like characteristic)
so generally when we would say "machine block" we would rather say "8 refined iron in pattern "patterndescriptrion" "
Basically, why can't we turn "blocks" into special type of "items" ?
This would allow to ease things alot ~_~
Forge idea.
- Sliderpro
- Closed
-
Ouch, that Suggestion (which should btw be in the Forgeforum even if this is the Offtopic-section) is not that easy to make, and it also wouldnt ease things. The 8 Refined Iron in a Pattern is already part of the Craftingrecipe, and Blocks are btw already Items. So what would be a change expect that you have one Classfile less, but therefor one even more complicated one?
-
So my idea is already greatly outdated
I had an idea and wanted to share it, that's all. Topic solved -
I would say that item ids conflicts are worse than block ids conflicts. With block ids you have clear information which mods are conflicting on which block id, with items you only see after a few hours of gameplay, that assembly table can make white stained glass instead of blue pipe wire. Of course it would be a lot better if there were some system of automatically assigning block ids/converting worlds, but your suggestion doesn't seem really thought out.
-
Ask Lex that and he won't stop laughing. It's not feasible without a major, time consuming and lag inducing change to the world format, the engine, existing mods, EVERYTHING - almost a whole new game.
Just wait until cpw implements @Block, which is his proposed way of autoassigning block IDs and syncing them from server to client in multiplayer and per world in singleplayer.
-
Just wait until cpw implements @Block, which is his proposed way of autoassigning block IDs and syncing them from server to client in multiplayer and per world in singleplayer.
ooh, shiny, the block id sync has been needed for a while. Would also vastly simplify adventure maps if it stores IDs in with the save. -
IC2 already stores your IDs alongside maps and fails if IDs mismatch
-
IC2 already stores your IDs alongside maps and fails if IDs mismatch
already know that. the nice idea is that if you can just hand out a map with a mod list and it'll handle the IDs that'll vastly simplify things. -
nice idea..
-
nice idea..
You necroposted a thread with ideas that are pretty much impossible to do, just to say two words? -
Well current state of forge mods for first installation is you place your mods in folder and run the game without ID conflicts. There can be some conflicts when adding another mods (which could be solved automatically), but in 1.2.5 it was almost necessary to add mods one at the time and resolve conflicts as they show up.
However there is room for improvement. IMO in an API like forge IDs shouldn't be accessible to modders and be just an internal implementation. From what I read in official API proposals from Mojang developers, it is planned this way (when it will be released and if it will be powerful enough is another story).
