Hi again, i found a program called "compareit" well im not sure if its called "compare it" or "compareit" but it says you can check two files and compare them with this, im not sure if its illegal to talk about other non minecraft software here (not piracy related) but if it is tell me. And no, i dont know about programming, so that wouldnt help me.
About the mod updates, ¿do i need to change the ids everytime they update them (even if its the same minecraft version, just the updated mods)?
Anyway, i think ill skip id resolver and downgrading, as i have some 1.5.2 mod in the mods i downloaded, and it seems faster and more efficient doing this manually.
Unless theres a good mod manager out there, like mcpatcher, but im not interested in that one because thats for modloader mods i think, and theres some mods that doesnt work with that thing, and no, i dont want to run different minecraft instances/profiles/whatever they are called for each mod, i want to run all the mods together.
Thanks again.
The only time you would have to edit the config files is when a new one is generated. This MAY happen when new releases are made. My suggestion would be to always keep a backup somewhere and see if a new file is generated. If you have software that will compare two files (line by line would be best rather than byte by byte-as you can read lines) then you can use that to check if your changes are present in the 'new' file. If they are then you have absolutely nothing to worry about (unless the file is lost for some reason).
I firmly disagree with this. Static, but configurable IDs work just fine. It is when the config file states "Block/Item Y must be +1 of Block/Item X" or when they designate ranges of IDs for ranges of their blocks/IDs.
Having statically allocated IDs isn't a bad thing, but not allowing users to configure them is... this is the problem that RedPower has, IC2 has, BuildCraft has, etc. etc. etc. Even those mods that allow configuring still have some components that require them to be set a specific way. Basically, if you are going to have a butt-load of IDs, then you need to use the damage/color modifier (number : number) so that you take up as few as possible... of course, if that modifier is needed (for damage) then it needs its own ID, but, w/e...
What we meant by "Static IDs" is "hard codded IDs", "dynamic IDs" is config file IDs, dynamic in the term that in code, they are referenced by a name, not the ingame used ID
Maybe a good thing for the range of IDs would be to include, in the config file, an IDResolver specific string, that contain every IDs use by the mod with their meta if there is. A string that is automatically changed according to the config in the file, after reloading.
That could also help manual debugging of IDs, since one should only have to look this one entry to see what the mod is made of(in term of IDs). One would then have to make the rest by hand, or with the help of IDResolver or their favorite third party program.
Rollback Post to RevisionRollBack
I am from Québec, so be gentle with my english
If you can make use of [ spoiler ] when you post crashLog, use fileHosting.
If you can't, don't post the damn km-long thing.
It is REALLY annoying for everybody.
What we meant by "Static IDs" is "hard codded IDs", "dynamic IDs" is config file IDs, dynamic in the term that in code, they are referenced by a name, not the ingame used ID
My mistake, I assumed you meant that feature that some mods have which allow the mods themselves to automatically assign new IDs to 'resolve' conflicts...
Maybe a good thing for the range of IDs would be to include, in the config file, an IDResolver specific string, that contain every IDs use by the mod with their meta if there is. A string that is automatically changed according to the config in the file, after reloading.
Heck, even just having a string of numbers (the IDs) at the top of the file in general listing what IDs are used would be a good-even necessary-convention... problem is, getting mod developers to adopt and abide by the convention.
Having it specific to ID Resolver would be excessive as, if devs cared about ID Resolver they would already be working with ShaRose to integrate their mods with his...
That could also help manual debugging of IDs, since one should only have to look this one entry to see what the mod is made of(in term of IDs). One would then have to make the rest by hand, or with the help of IDResolver or their favorite third party program.
This would certainly help with manual debugging of IDs. It would even be possible to have the program/method that configures the config file (i.e. writes to and reads from) read the ordered set of IDs and automatically change the values within the file. This would theoretically be simple as printing a set of numbers: String ids = "["; and addID(int id){ ids += " " + id }, and finializeIDs(){ //parses the string removing the initial space and adding ',' after each number }. Then simply parsing through the rest of the file should an ID be changed (checking the modified date on the file would help with this) and reasserting the IDs from the list into their locations in the file...
Sadly, this doesn't seem likely. I often make suggestions but devs either don't trust me (and, really, why should they. I may be right, but they have virtually no way of knowing if I am 'good' or not...), or they believe they know more about programming than I do (which, while certainly possible, doesn't mean that I don't know better 'methods of doing stuff' than they do... or at least have a better grasp on what is possible-which has occurred enough to be proven...)
Checked ShaRose profile, and was active..today?
But..he didn't even post anything here..is he ignoring the thread..?
It's possible, and he has every right to do so, but I doubt he's ignoring the thread. Being active doesn't really mean anything, as you could be "active" simply from signing in to the website.
He did write in his last commit of IDR: "Don't know why I hadn't committed earlier changes, but oh well. You'll still get to see the gigantic fix to the patcher, right? Also, 1.5.1.0. I hope to god this is the last commit I have to do here and by the time 1.6 comes out IDR2 is working and released. Here's hoping." https://github.com/ShaRose/ID-Resolver/commit/49d95a9e23024dd1411e2b449923db3a2409f0d8
ShaRose, I beg of you, if you are still reading these, please do at least one thing. Please change the title to say "Not for 1.5.2". It'll make our job so much easier...
(And then, obviously, continue with what ever you are doing. I don't want to be a bother)
Hi again, i found a program called "compareit" well im not sure if its called "compare it" or "compareit" but it says you can check two files and compare them with this, im not sure if its illegal to talk about other non minecraft software here (not piracy related) but if it is tell me. And no, i dont know about programming, so that wouldnt help me.
About the mod updates, ¿do i need to change the ids everytime they update them (even if its the same minecraft version, just the updated mods)?
Anyway, i think ill skip id resolver and downgrading, as i have some 1.5.2 mod in the mods i downloaded, and it seems faster and more efficient doing this manually.
Unless theres a good mod manager out there, like mcpatcher, but im not interested in that one because thats for modloader mods i think, and theres some mods that doesnt work with that thing, and no, i dont want to run different minecraft instances/profiles/whatever they are called for each mod, i want to run all the mods together.
Thanks again.
At the end there, I may like to come in.
MultiMC allows you to edit all of them together.
You run different instances when you want to have different .minecraft folders.
Like you may want to play a modded Minecraft and a vanilla Minecraft.
You also can delete the mods for your instance... but may not work if it was in the jar.
So I would recommend this.... but they don't resolve ID's.
Please update this mod to 1.5.2 version!! PLEASE! i'm already have GuiAPI 1.5.2. This version ID Resolver is not working
As has been explained already, ShaRose is more than likely not updating to 1.5.2 and is instead working on getting ID Resolver 2 ready for 1.6 when it launches.
You'll either have to go back to 1.5.1 to use ID Resolver, or stay on 1.5.2 and learn how to fix ID conflicts manually by changing config files.
Sorry for bugging you guys with a question that has probably been asked many times before, but will this mod change the ids in the config files or do you have to keep this mod installed to use the block ids that it assigns to blocks and items?
ID Resolver doesn't actually change anything, so you do need to keep it installed in order to keep any reassigned IDs.
Dang I was hoping I could use this to change the ID's in 1.5.1 and then update to 1.5.2 I guess I am doing the IDs myself then!
You could use ID Resolver on 1.5.1 to assign things so they don't conflict, and then use the ID Map it creates as a reference point and go into each mod's config file and edit the IDs yourself to what ID Resolver reassigned them to. Then you could update to 1.5.2, and with any luck there won't be too much trouble in the process.
It's a bit of work and definitely time-consuming, but it's pretty easy.
The only time you would have to edit the config files is when a new one is generated. This MAY happen when new releases are made. My suggestion would be to always keep a backup somewhere and see if a new file is generated. If you have software that will compare two files (line by line would be best rather than byte by byte-as you can read lines) then you can use that to check if your changes are present in the 'new' file. If they are then you have absolutely nothing to worry about (unless the file is lost for some reason).
What we meant by "Static IDs" is "hard codded IDs", "dynamic IDs" is config file IDs, dynamic in the term that in code, they are referenced by a name, not the ingame used ID
Maybe a good thing for the range of IDs would be to include, in the config file, an IDResolver specific string, that contain every IDs use by the mod with their meta if there is. A string that is automatically changed according to the config in the file, after reloading.
That could also help manual debugging of IDs, since one should only have to look this one entry to see what the mod is made of(in term of IDs). One would then have to make the rest by hand, or with the help of IDResolver or their favorite third party program.
I am from Québec, so be gentle with my english
If you can make use of [ spoiler ] when you post crashLog, use fileHosting.
If you can't, don't post the damn km-long thing.
It is REALLY annoying for everybody.
Thanks
My mistake, I assumed you meant that feature that some mods have which allow the mods themselves to automatically assign new IDs to 'resolve' conflicts...
Heck, even just having a string of numbers (the IDs) at the top of the file in general listing what IDs are used would be a good-even necessary-convention... problem is, getting mod developers to adopt and abide by the convention.
Having it specific to ID Resolver would be excessive as, if devs cared about ID Resolver they would already be working with ShaRose to integrate their mods with his...
This would certainly help with manual debugging of IDs. It would even be possible to have the program/method that configures the config file (i.e. writes to and reads from) read the ordered set of IDs and automatically change the values within the file. This would theoretically be simple as printing a set of numbers: String ids = "["; and addID(int id){ ids += " " + id }, and finializeIDs(){ //parses the string removing the initial space and adding ',' after each number }. Then simply parsing through the rest of the file should an ID be changed (checking the modified date on the file would help with this) and reasserting the IDs from the list into their locations in the file...
Sadly, this doesn't seem likely. I often make suggestions but devs either don't trust me (and, really, why should they. I may be right, but they have virtually no way of knowing if I am 'good' or not...), or they believe they know more about programming than I do (which, while certainly possible, doesn't mean that I don't know better 'methods of doing stuff' than they do... or at least have a better grasp on what is possible-which has occurred enough to be proven...)
But..he didn't even post anything here..is he ignoring the thread..?
It's possible, and he has every right to do so, but I doubt he's ignoring the thread. Being active doesn't really mean anything, as you could be "active" simply from signing in to the website.
Maybe, though there are rumors floating around that he's skipping updating to 1.5.2 and working on updating to 1.6 instead..
But here's hoping we'll see an update for 1.5.2 at some point.
He's busy making ID Resolver 2
However he's not posting it all to GitHub though.... : https://github.com/ShaRose/IDR2
He did write in his last commit of IDR: "Don't know why I hadn't committed earlier changes, but oh well. You'll still get to see the gigantic fix to the patcher, right? Also, 1.5.1.0. I hope to god this is the last commit I have to do here and by the time 1.6 comes out IDR2 is working and released. Here's hoping." https://github.com/ShaRose/ID-Resolver/commit/49d95a9e23024dd1411e2b449923db3a2409f0d8
-Batman123579
(And then, obviously, continue with what ever you are doing. I don't want to be a bother)
At the end there, I may like to come in.
MultiMC allows you to edit all of them together.
You run different instances when you want to have different .minecraft folders.
Like you may want to play a modded Minecraft and a vanilla Minecraft.
You also can delete the mods for your instance... but may not work if it was in the jar.
So I would recommend this.... but they don't resolve ID's.
Huh?
He visits the forums almost every day!
Sometimes he takes breaks for a few days, but other than that he comes here quite often!
I would be really happy if he at least posted something like.....oh, I don't know...
Maybe, "STFU, YOU IMPATIENT IDIOTS!!!!THE NEXT VERSION OF ID RESOLVER WILL COME OUT WHENEVER I WANT!!!NOW KISS MY @$$ REPEATEDLY!!!!!"
Just kidding!
Seriously though, a message would be welcomed!
As has been explained already, ShaRose is more than likely not updating to 1.5.2 and is instead working on getting ID Resolver 2 ready for 1.6 when it launches.
You'll either have to go back to 1.5.1 to use ID Resolver, or stay on 1.5.2 and learn how to fix ID conflicts manually by changing config files.
ID Resolver doesn't actually change anything, so you do need to keep it installed in order to keep any reassigned IDs.
You could use ID Resolver on 1.5.1 to assign things so they don't conflict, and then use the ID Map it creates as a reference point and go into each mod's config file and edit the IDs yourself to what ID Resolver reassigned them to. Then you could update to 1.5.2, and with any luck there won't be too much trouble in the process.
It's a bit of work and definitely time-consuming, but it's pretty easy.