internal ID store

[ratchetfreak]

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

 

 

public int requestBlockIdFor(Object mod,String identifier) {

    Mod annotation=mod.getClass().getAnnotation(Mod.class);

    if(annotation==null)throw new IllegalArgumentException(...);

    Integer id = blockMap.get(annotation.modid()+"|"+identifier);

    if(id==null){

        int freeId = getNextFreeBlockId();

        blockMap.put(annotation.modid()+"|"+identifier, freeId);

        return  freeId;

    }

    return id.intValue();

}

 

public int requestItemIdFor(Object mod,String identifier) {

    Mod annotation=mod.getClass().getAnnotation(Mod.class);

    if(annotation==null)throw new IllegalArgumentException(...);

 

    Integer id = itemMap.get(annotation.modid()+"|+identifier);

    if(id==null){

        int freeId = getNextFreeBlockId();

        itemMap.put(annotation.modid()+"|"+identifier, freeId);

        return  freeId;

    }

    return id.intValue();

}

 

 

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)

[Ardenexal]

I really like thus idea. With forge becoming more popular there is a need for dynmanic id assignment  to avoid mod clashes

[LexManos]

cough

Its mainly a issue of modders being stupid when it comes to id conflicts.

[ratchetfreak]

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

[LexManos]

Centralizing things will not fix this, Modders not being stupid will fix this. The functionality is already in place.

[ratchetfreak]

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.

[LexManos]

There are many situations that may occure, and your example is a reason against having a centralized system like that and making it to 'smart'.

Lets say, you install RP2 it gets ID #150 for its machines, and you create a awesome nuclear reactor.

Then you install CrappyMLMod#15 which hardcodes it's block to ID #150

RP2 starts loading, gets the 'oh this is taken silently give me another id'

You load your world

Shit explodes, quite literally.

 

The system in place is perfectly fine for modders who understand and use it correctly.

Load your config, if it's ids are set, create your blocks in the init.

If you need a auto-assigned id, grab it in the post-init.

This way all mods that have a config already will load and have there ids, and any new mods will respect the old mod's configs.

[ratchetfreak]

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

[LexManos]

Im still not seeing anything of value from doing this. Specifically it'd reassign ids silently that could fuck up players worlds.

Unless you come to me with a system that assigns every block, including modloader blocks, a unique id and allows us to take full control over the id management system, this isn't gunna be included in forge.

There are to many things that this system fucks up if done half-assed.

And this is not something that I am willing to do half-assed, if it were, a system would of been in place months ago. It's not like this is a new or unique issue. I've discussed this with many smart people. And there is no elegent solution that doesn't have major, major downfalls.

 

The current system in place works perfectly fine if the modders arn't stupid. If you have ID conflict issues from a Forge mod, go bitch at them.