Diff cores
-
- Posts: 2013
- Joined: Fri Jun 27, 2003 7:00 am
- Location: Contact me regarding: CC, Slayer and AllegWiki.
What I would REALLY dig is an export function so I can take two cores and diff them, and write a proper changeset without having to refer back to ICE for every single entity - which is what I have to do with core2text since the format isn't easy to read, and more importantly it crashes.
Last edited by Spunkmeyer on Sat Mar 16, 2013 9:30 pm, edited 1 time in total.
Want bigger games? Log on to play at the official game time: 9pmET/8pmCT/7pmMT/6pmPT every day of the week. Also Saturdays 8pm UTC.
ok i've done a quick and dirty tool in .Net that uses IGCLib.dll to read cores and dump them as text, one line per field.
The result is very diff'able with WinMerge for instance.
here is a partial example with cc_10 and cc_14.
tell me if it's what you had in mind or not. if then, I can polish the tool a little bit more and release it in a few days.
edit: a preview is available here : http://code.google.com/p/allegice/downloads/list
it's a command line tool that displays to standard output so use it like this:
or with paths like this:
it's made in .Net with VS 1012 so you might need a few libs to run it (.Net 4.0 i think)
edit2: the source is now also available
The result is very diff'able with WinMerge for instance.
here is a partial example with cc_10 and cc_14.
tell me if it's what you had in mind or not. if then, I can polish the tool a little bit more and release it in a few days.
edit: a preview is available here : http://code.google.com/p/allegice/downloads/list
it's a command line tool that displays to standard output so use it like this:
Code: Select all
coredump cc_14.igc > cc_14.txt
Code: Select all
coredump d:\Allegiance\artwork\cc_13c.igc >e:\dev\cc13c.txt
edit2: the source is now also available
Last edited by KGJV on Wed Mar 20, 2013 2:55 pm, edited 1 time in total.
-
- Posts: 2013
- Joined: Fri Jun 27, 2003 7:00 am
- Location: Contact me regarding: CC, Slayer and AllegWiki.
-
- Posts: 2013
- Joined: Fri Jun 27, 2003 7:00 am
- Location: Contact me regarding: CC, Slayer and AllegWiki.
Am I seeing things or is it spitting out wrong bitmask values?
Lxy Fighter for example:
Ships-Lxy Fighter(258)-ttbmEffects: 166
Ships-Lxy Fighter(258)-ttbmRequired: 6 14 20 166
while it should be:
Pre = 1 9 19 161
Def = 161
Lxy Fighter for example:
Ships-Lxy Fighter(258)-ttbmEffects: 166
Ships-Lxy Fighter(258)-ttbmRequired: 6 14 20 166
while it should be:
Pre = 1 9 19 161
Def = 161
Want bigger games? Log on to play at the official game time: 9pmET/8pmCT/7pmMT/6pmPT every day of the week. Also Saturdays 8pm UTC.
yeah definitly an issue with printing out bitmask values. I'll look into it.Spunkmeyer wrote:QUOTE (Spunkmeyer @ Mar 25 2013, 12:30 AM) Am I seeing things or is it spitting out wrong bitmask values?
Lxy Fighter for example:
Ships-Lxy Fighter(258)-ttbmEffects: 166
Ships-Lxy Fighter(258)-ttbmRequired: 6 14 20 166
while it should be:
Pre = 1 9 19 161
Def = 161
Well looks like the way ICE is interpreting how a bitarray is stored in memory/file is wrong.
It's different than the game code is interpreting it. As well as IGCLib (which is based on the game code) which is used by CoreDump.
it's related to a Endiannessproblem.
Now, either I fix ICE but every pre/def numbers will change so people who are used to have memorized some values will have to adapt
or
I change IGCLib so it works like ICE but in that case it will mismatch with the game
or
I change CoreDump to print bitarray like ICE does.
Since the origin of the problem is an "incorrect guess" made when building ICE i'd rather fix ICE (remember we had to do reverse engineering back then)
Actually I should scrap the old ICE igc code and use IGCLib in ICE directly but then the numbers will change.
question is: is the small world of people using ICE ready for that change ?
It's different than the game code is interpreting it. As well as IGCLib (which is based on the game code) which is used by CoreDump.
it's related to a Endiannessproblem.
Now, either I fix ICE but every pre/def numbers will change so people who are used to have memorized some values will have to adapt
or
I change IGCLib so it works like ICE but in that case it will mismatch with the game
or
I change CoreDump to print bitarray like ICE does.
Since the origin of the problem is an "incorrect guess" made when building ICE i'd rather fix ICE (remember we had to do reverse engineering back then)
Actually I should scrap the old ICE igc code and use IGCLib in ICE directly but then the numbers will change.
question is: is the small world of people using ICE ready for that change ?
Last edited by KGJV on Mon Mar 25, 2013 9:25 pm, edited 1 time in total.
-
- Posts: 2013
- Joined: Fri Jun 27, 2003 7:00 am
- Location: Contact me regarding: CC, Slayer and AllegWiki.
The right thing to do is obviously fix ICE and the changed defs is not a big deal for me, especially if you can provide a conversion function.
My immediate concern was whether the data returned from IGCLib was internally consistent (since I'm going to try to hack it a bit to identify factions for ships, bases etc) and that's settled.
My immediate concern was whether the data returned from IGCLib was internally consistent (since I'm going to try to hack it a bit to identify factions for ships, bases etc) and that's settled.
Last edited by Spunkmeyer on Mon Mar 25, 2013 10:26 pm, edited 1 time in total.
Want bigger games? Log on to play at the official game time: 9pmET/8pmCT/7pmMT/6pmPT every day of the week. Also Saturdays 8pm UTC.
Unless I messed in IGCLib somewhere I think it is internally consistent. i'll recheck the part that deals with bitarray just in case.Spunkmeyer wrote:QUOTE (Spunkmeyer @ Mar 25 2013, 11:24 PM) The right thing to do is obviously fix ICE and the changed defs is not a big deal for me, especially if you can provide a conversion function.
My immediate concern was whether the data returned from IGCLib was internally consistent (since I'm going to try to hack it a bit to identify factions for ships, bases etc) and that's settled.
As for ICE, if I do the fix, it's still be consistent, it's just for us human that there will be a difference. Internally nothing really changes.
it's like if ICE was displaying numbers in hex and after the change it'll display them in decimal. People will have to adapt to that.
People new to ICE or dealing with a new core won't have a problem.
People dealing with the same core for years and who know that, for instance, "18" is the 'pre' for everything specific to Iron Colation (in most cores) will have to adapt because after the fix this '18' will show as "25" in the new ICE.
Acutally I don't even know if people do memorize some of these pre/def numbers but I assumed they could and that's why I was inquiring about this.
So there no convertion function needed (what would you do with it ?!) or I didn't understand what you meant there ?
-
- Posts: 2013
- Joined: Fri Jun 27, 2003 7:00 am
- Location: Contact me regarding: CC, Slayer and AllegWiki.
I do have some some pre & defs memorized or otherwise referenced... as it's not immediately apparent to me how the numbers change from looking at the underlying bits (doesn't look like a simple LSB & MSB swap) I was saying if you could provide the conversion formula, then I could quickly revise my lists to refer to the new, accurate numbers.KGJV wrote:QUOTE (KGJV @ Mar 25 2013, 06:45 PM) So there no convertion function needed (what would you do with it ?!) or I didn't understand what you meant there ?
If not, no biggie, I can revise them manually.
Want bigger games? Log on to play at the official game time: 9pmET/8pmCT/7pmMT/6pmPT every day of the week. Also Saturdays 8pm UTC.