ratchetfreak

that would require ALL tile entities that can place blocks to record who track who owns it and pass that info along to each potential block it places that may place a block itself, there is currently no system in place to do anything like that

but that requires mods to link the ticket to the user this not trivial once you start using items that can place blocks (RP2 deployers, CC turtles) who is then responsible for the chunk loader

no I'm not doing anything for crappy mods that hardcode ids; those will still break the lot like they would now also I have yet to see a mod using post-init to get ids. as that is quite hard when getting the id involves going through the config which can assign you ids and there is no real difference in use between when you have a config file yet or not (by design nota bene) unless you check whether categories.isEmpty() also the prepopulation of the config arrays make it more new-mod proof even when you don't change the getBlock and getItem functions all it really takes is static { Arrays.fill(configBlocks, false); Arrays.fill(configItems, false); if(USED_BLOCK_IDS_FILE.exists()){ InputStream inputStream = null; try{ inputStream = new BufferedInputStream(new FileInputStream(USED_BLOCK_IDS_FILE)); for(int i = 0; i < configBlocks.length; i+= { int block = inputStream.read(); //using a binary file but you can use a text file if you like that more if(block < 0) break; //we shouldn't reach this when everything is correct but we might as well code for it for(int j = 0; j < 8 && (i+j) < configBlocks.length; j++){ configBlocks[i+j] = (block & (1<<j)) != 0; } } }catch(IOException e){ throw new RuntimeException("ids failed to load",e);//won't really happen }finally{ if(inputstream!=null)try{inputStream.close();}catch(IOException e){throw new RuntimeException("id file failed to close",e);} } } } and the same for the configItems

so you are saying my scenario will never come to pass? a new mod with some default id loading before another mod which already uses that id in its config. There's no check on collision when the id is already set in the config (lines 110 to 114 from your link). This means that the new mod hijacks the id from another mod but that one won't detect it until it tries to create the item-> exception-> loading fails just adding a file to prepopulate the configItems and configBlocks arrays will fix that (after loading all the mods you can create the file with the blockList and itemList and checking vs null so that when a mod is removed it won't keep hogging the ids it took) if it won't come to pass (I'll need proof for that) then write a tutorial about how to be smart with conflicts as there are currently none.

lex that doesn't work when a new mod gets added that loads before an already established mod and then conflicts with it say there's mod A that has default id 1000 the user instals and uses mod A for a while and then finds mod B which also happens to have a default of 1000, he installs it as well now due to the mod loading not being fully defined (or at least not being based on newness of the mod) mod B happens to load before mod A and gets id 1000 assigned (because forge hasn't yet loaded the configs for mod A) then mod A loads and tries to use it's own ID and fails with an id conflict ->client crashes this is because while the mod B is loading forge doesn't yet know what other mods will also load which IDs leading to a conflict, centralizing it will fix that

essentially I want that forge handles all of the id configuration itself instead of have each mod do it themselves with all due concequences for example create a IDRepository class with the method int requestBlockIdFor(Object, String)/requestItemIdFor(Object, String) here's my timeline for how it should work: before any PreInit are called IDRepository will loads its "ids.cfg" and build an internal Map<String,Integer> for used ids (including vanilla ids) then in the PreInit mods will need to call "int modBlockId =getNextFreeBlockId(requestBlockIdFor(this, "modBlock"));" the code for requestBlockIdFor will be something like then the getNextFreeItemId()/getNextFreeBlockId() then should iterate itemsList and blocksList resp for a new free id and check if it hasn't been assigned to another mod first after the preInits are called it will save the config this can also be done for entity ids this will remove all id conflicts (except for rogue mods...) and removes the need for Unofficial Block/Item ID Range Listing, this also allows for the ids.cfg file to be included in maps (and perhaps make a tool to transfer maps from one ids.cfg to another)