Version 2.1 of my patch is up

[Yitzi]

One feature in particular is going to interest you, Earthmichael: The last line of the RULES section in alphax.txt says "If non-zero, recalculate base statistics after each change".  Set it to 0, and you'll get the "what you see is what you get" rules you requested.
Also, you mentioned that you like to play as University, so if you're looking for a challenge try changing the drone control code to 30 or 31; it makes Zak's drone problems a lot more significant.

[LastConformist]

I'm sorry, but where is it posted?

[Yitzi]

Whoops, I accidentally put it in the folder for the Nomads GotM (under scenarios).  I'll ask sisko to move it; until then, you can get it from there.

[DrazharLn]

The patch can now be found here: http://alphacentauri2.info/index.php?action=downloads;sa=view;down=134

Yitzi, congratulations and thanks for releasing another patch. Did you fix the issues with incompatible save files in this version?

[Yitzi]

Actually, I fixed that in 2.0; it was the major project of 2.0 and why it took so long.

[DrazharLn]

Ah, I didn't see a thread for that and I missed it in the downloads section. I'm finding the site a bit counter-intuitive to navigate at the moment.

Could I ask you some technical questions about how you produce the patch? I'm interested in helping out in the project. I'm particularly interested in hearing about what tools and workflows you're using and in any notes about what parts of the code do what. I'm a pretty good programmer and I know my theory (Computer Science BSc (First class honours)), but I haven't done any decompiling before, and, besides, I don't want to replicate effort needlessly.

E: Just saw your message here. I'll look up ollydbg and the machine code reference. Have you managed to decompile it to anything higher level? I seem to remember getting it to C with scient.

[Buster's Uncle]

You're used to vBulletin forum software - I had a lot of initial trouble adjusting to the way SMF does things, too.  You'll get used to it.

Yitzi, Draz is A#1 cool, gifted, and a great guy, just so you know; please do what you can to get him started.

[Yitzi]

I think scient managed to decompile small portions to C, but decompiling the whole thing to C is not workable.  Personally, I don't bother, as I don't have any experience in C, and this way I can manipulate things more directly (which helps avoid the problem of there not being enough room for the code.)

Basically, I find what part does what I want (ollydbg's breakpoints are extremely helpful here), figure out how it does it (which sometimes results in discovering bugs), and then figure out how to change it to get the result I want, and write the new code and put it in.

Computer science really isn't that necessary, as a lot of it is about runtime efficiency and SMAX is so old that's not a concern anyway.

My tools are really just ollydbg, the program itself, and a modified version of Kyrub's patch (which I made myself) that uses alphaxb.txt instead of alphax.txt.  I don't really bother with any fancy workflows, just go step by step.

BUncle said to help you get started, so first I need a sense of what you know in terms of how assembly language works.

[DrazharLn]

Re: Assembly: I've written some fairly small stuff in ARM. No experience in x86.

From what you've written, I assume you
1) load the exe up with a bad save
2) put a breakpoint somewhere likely
3) Step through after the breakpoint and work out how it works
4) Fix the bug

I'm cool with 1, 3 and 4, but how have you worked out where to place your breakpoints?

E: BUncle thanks for the compliments

[Yitzi]

Re: Assembly: I've written some fairly small stuff in ARM. No experience in x86.

From what you've written, I assume you
1) load the exe up with a bad save
2) put a breakpoint somewhere likely
3) Step through after the breakpoint and work out how it works
4) Fix the bug

I'm cool with 1, 3 and 4, but how have you worked out where to place your breakpoints?

Well, firstly, a lot of what I do is modding (or rather, adding new alphax.txt variables to allow modding) rather than bugfixing.  But for bugfixing, what I do is first run the save through ollydbg with no breakpoint.  It will automatically break at the illegal action.  (If there's an endless loop causing a freeze rather than an illegal action causing a crash, I can't really do anything.)  Then I see what value is not what it should be (or simply doesn't make sense), track where it came from, and figure out where it's coming from that it shouldn't.  Place a breakpoint there and repeat until the actual bug is found.  Usually it's not very far.

[DrazharLn]

And for the adding new variables, you presumably find the variable you want to affect then put in some new I/O and a little logic stuff to handle it.

This sounds (and looks) quite tricky. I think I'll have a trawl for a bad save and give it a go tomorrow. Some practice might make it easier to understand. If you could suggest a save/bug to investigate as a learning exercise, that could be quite helpful, otherwise I'll just pick something that seems easy.

Have you made notes anywhere about what part of the code does what? Any hints on navigating the code or using ollydbg?

[Yitzi]

And for the adding new variables, you presumably find the variable you want to affect then put in some new I/O and a little logic stuff to handle it.

I/O is fairly difficult; I'm just starting on it now.  Mainly what the new variables do is just the logic and math...which actually is what most modding deals with anyway.

If you could suggest a save/bug to investigate as a learning exercise

This bug might be a good learning exercise...just make sure to test it with Kyrub's patch and not mine.

Have you made notes anywhere about what part of the code does what? Any hints on navigating the code or using ollydbg?

I do have notes, but it's not that organized.  Several useful tricks that I've found are:
1. Keep an eye out for anything that references plaintext.  If you see a function called with one argument the text SCRIPT and another argument the text DRONERIOTS, it's a pretty safe bet that it's going to do something involving the DRONERIOTS entry in script.txt.  That tells you pretty clearly what the piece of code the function is being called in does.
The converse method is even more useful; if you can associate what you're looking for with plaintext, you can search for it in the data section (ctrl-B is to search for bits in ollydbg; the lower part is hex data, but you can also enter it as ASCII on the top), then search for that address (remember, an address is called with the last byte first) in both data and the program, and use that to find where the plaintext is used.  Without that method, I doubt I'd have been able to even get started.
2. Data comes in blocks, so by looking at the blocksize (generally what you multiply some number by to then add something to get the address) you can get a good sense of what a variable might be.  For instance, if something is multiplied by 20CC, it's a SMAC faction variable.  59C, and it's a SMAX-only faction variable.  134, and it's a base variable.  (2C has a number of possibilities.)  Note that often multiplication is done via shifts and LEA (load effective address, which essentially allows you to set one register as a weighted some of one or two others plus maybe a constant, without affecting flags), rather than a straight multiplication.  It does the same thing if flags don't matter, so replacing it with multiplication is a good way to free up room.
3. Calls to other parts of the compiled code will generally end with 0.  Calls to modder-made code and to functions built in to C generally won't.
4. Learn how the program is supposed to work.  Often, a function will be too difficult to track, but you can figure out what it does by what it has to be doing for the code to work like it's supposed to.  Likewise for variables.  Of course, if it is simple enough to read directly, that's probably better, just in case it isn't working like it should.  (I'm pretty sure I've caught at least half a dozen bugs that I wasn't looking for that way.)
5. If you identify a really important variable (such as difficulty) or function, consider making a note of it so you don't have to look it up when you come across it again.  (Difficulty in particular is at 9A64C4 for global difficulty, and at 96C9E8+20CC*fac# for each faction's difficulty.)
6. Modder-written code will generally show up in Ollydbg as data rather than instructions.  Just highlight it and ctrl-insert then shift-insert to copy it onto itself; this will force Ollydbg to parse it as instructions.  Be careful, though, as sometimes switch-control data shows up in the instructions section after the procedure with the switch, and the same method will force Ollydbg to parse that as data, which can make it confusing.

[DrazharLn]

Sorry for disappearing (and for seeming like an arse if I did).

Clearly, I never got round to doing the debugging and probably won't for a long time, if ever. Unfortunately, I have a lot to do at the moment and don't have the time to learn disassembly and the AC codebase.

Hope you are well and that you found someone else to help you.

[Yitzi]

Sorry for disappearing (and for seeming like an arse if I did).

Clearly, I never got round to doing the debugging and probably won't for a long time, if ever. Unfortunately, I have a lot to do at the moment and don't have the time to learn disassembly and the AC codebase.

Hope you are well and that you found someone else to help you.

I actually figured it out myself...but thanks anyway.