Free Allegiance Forums

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.

not sure this should be part of ICE actually.

There is a library to read/write cores. Using this as a starting point to build a tool that generates a 'diff'able' format should be easier.

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

Awesome KG, I'll play with it.

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

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

yeah definitly an issue with printing out bitmask values. I'll look into it.

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 ?

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.

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.

Unless I messed in IGCLib somewhere I think it is internally consistent. i'll recheck the part that deals with bitarray just in case.

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 ?

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 ?

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.

If not, no biggie, I can revise them manually.