Page 2 of 3

Posted: Sat Jul 18, 2009 5:56 pm
by DCER
I'm playing with it now. :lol:

I think your idea to split the function is the right one. Have one handle pop, ships and orbitals while the other handles upgrades (and have it also call the first one).

If we move nop's down so they end right before 45207F asm we could make a new function there and cut off the jump at 4520FD to end the function instead. Do you think this would break the upgrade process?

Hidden in the pop block is the move of eax to ebp, this and a few others would have to be copied to the start of the new function.

Then the original gets modified to suit our ship building needs :)

Posted: Sat Jul 18, 2009 6:29 pm
by Flocke
DCER wrote:If we move nop's down so they end right before 45207F asm we could make a new function there and cut off the jump at 4520FD to end the function instead. Do you think this would break the upgrade process?
at 452157 there is a jump back to 452090, from there on all seems to be related to upgrading, although I can't say what it's about in the beginning, it's within the loop for upgrading... (in the beta2 of OllyDbg 2 the jumps are marked by arrows, more clear than in IDA free in my opinion ;))

at 452084 seems to be the last call related to population. It is adjusting the planet terraforming to the new population.

can't tell much about overlappings and I still hang at population calculation. Think I need some debugging to figure more, but unfortunately debugging on vista currently seems to be an impossible task. :lol:

I've used a save within that I just need to hit turn two times:
1. turn the talarians upgrade
2. turn they member me

but this doesn't tell me anything about what's in the registers or variables and how it's stored. :(

when I manually try to set the new population in the code, the talarian stops upgrading and I dunno why. :roll:

I lost my mind, need some sleep and hope you'll solve this or I get a new idea tomorrow, else I'll instead continue programming again and leave it for some days.

Posted: Sun Jul 19, 2009 4:46 am
by DCER
I don't know why but OllyDbg breaks on 451F20 for me. I've moved the bytes as described above. IDA handles it fine.

In OllyDbg I get "movsx ecx, di" followed by a data entry (?!) where it should say "imul ebx, ecx, 328h". It's right at the start of the function in the part I haven't even touched.

The only way to see the assembly code is by the use of "Remove Analysis", but then it doesn't show jump connections, so it's useless :(

Posted: Sun Jul 19, 2009 8:29 am
by Flocke
DCER wrote:The only way to see the assembly code is by the use of "Remove Analysis", but then it doesn't show jump connections, so it's useless :(
And I thought you could tell me why! :(
It's happening in OllyDbg 1.1 as well, so I'm just not reanalysing the code and I'm not closing the program. That saves me the assembly as well as the original jump connections. The new ones I've either in mind or I'm using the hexoffsets being shown.
I've searched the web on this issue, but it seems to be a common problem with OllyDbg.

Posted: Sun Jul 19, 2009 9:02 am
by DCER
Doesn't matter, I'm done separating the functions :) Yaay!!! :lol:

I've moved a lot of code so now the functions don't overlap and are each in their own "block".

They behave as the original except that I've removed building orbitals based on research upgrade, because I needed space for the exit code. Also this would have gotten removed later on anyway.

Paste contents of this file at 0x51320:

http://www.4shared.com/file/119125987/4 ... 51320.html

Then at 0x51DD9 change the call to read E8 62 F8 FF FF

Posted: Sun Jul 19, 2009 9:54 am
by Flocke
DCER wrote:Doesn't matter, I'm done separating the functions :) Yaay!!! :lol:
cool, will check it :)
I've tested with changing population in original function again.
replaced loading the IPN @45201C by current population number as you've suggested earlier. Cause it's the first upgrade within my save, IPN and current pop are equal so it doesn't matter. But I then used the three nops to add or sub some values.
It seems to be dependent on race or population number, system planets, whatever when it will happen, but for my talarians (of my modificated game with lessening speed and IPN in race.rst) I got the following results:

turn 23 = loaded savegame
turn 24 = talarians upgrade
turn 25 = talarians join

turn 4 or something => original, but race.rst altered:
5 cardassian type 1 farm,
1 cardassian type 1 factory,
3 cardassian type 1 energy buildings
1 planet terraformed

turn 25 with sub edx, 1 to D as well as add edx, 1 to 6 or just using nops:
some ferengi type 2 farms,
some ferengi type 2 factories,
some ferengi type 2 energy buildings,
1 planet terraformed
('some' depends on population number)

with add edx, 6 the population max'ed out the already terraformed home planet.

turn 25 with add 7 to 8:
some cardassian type 2 farms,
some cardassian type 2 factories,
some cardassian type 2 energy buildings,
2 planets terraformed

turn 25 with sub >= E or add >= 9 no upgrade takes place for the talarian and not even the population gets adjusted!!!

This is weird. :?
Skipping the calculation causes no upgrades taking place as well, so there must be something important hiding within. Keep care and hopefully debugging clears it a bit, I absolutely have no clue about.

Posted: Sun Jul 19, 2009 10:31 am
by Flocke
DCER wrote:They behave as the original except that I've removed building orbitals based on research upgrade, because I needed space for the exit code.
I've tested it now and it broke the upgrading part. I still had cardassian type 1 buildings, but 10 farms where it originally has been 5. Funnily botf states it's 4 farms but I can activate more than 4. At least the population growed normally and one orb got build as expected.
This looks like the troubles I had earlier when trying to seperate the population growth from buildings upgrade and might be related to the same problem I've just described above. :(

Edit: btw, I just realized that OllyDbg has a command edit->"Copy to executable" when right clicking on code. It will open another menu, showing the exe with hex offsets, replaces corresponding values with selected ones and enables a new command "Save file..." to save the whole exe to whatever filename entered. Quite helpful but doesn't solve the analysing issues. ;)

Posted: Sun Jul 19, 2009 12:12 pm
by DCER
Flocke wrote:I still had cardassian type 1 buildings, but 10 farms where it originally has been 5. Funnily botf states it's 4 farms but I can activate more than 4.
Check the structures tab, it looks like two versions of farms might be built. If they are - it's a known occasional botf bug.

EDIT: if it's caused by this maybe we could find a fix for the old bug as well :)

Posted: Sun Jul 19, 2009 12:35 pm
by Flocke
DCER wrote:Check the structures tab, it looks like two versions of farms might be built. If they are - it's a known occasional botf bug.
Hm, you're right, 4 automatic (federation) and 5 hydroponic (cardassian) farms, nine in total btw, not 10 (my fault).
But still not upgraded. Somehow there seems to be some settings being set by the pop calculation that get applied lateron.

Good luck with fixing it! :D

Edit: Forgot to mention, the new farms are of fed type 1 and they keep building them endless on every EL jump but build nothing else in system. :roll:

Posted: Sun Jul 19, 2009 1:44 pm
by Flocke
just a quick note:

loading the TurnNumer (orig. code) @asm:452031 / hex:51431 can be replaced by six nops cause it already got loaded @452006 and kept untouched.

Posted: Sun Jul 19, 2009 7:58 pm
by Flocke
I kept testing a little and I think now that the problem is to be found somewhere below the pop calculation cause it kept same with moving it up and adjusting result below by adding or substracting again before storing to ebx+40.

It might be related to the function that I've previously named "_adjustMinorTerraforming", which is called at 452084 and located at 4518F0.
At least it's accessing the population number again, but overwriting it might be just due to limiting population size when terraforming isn't applied or no planets are left.
Overwriting it by nops this time caused no upgrade to take place and population not being changed, but one page back, I've experienced the population having increased above currently terraformed maximum. :roll:

Isn't it annoying when you really want something, something simple, and just don't get it? *grrrr*

The call to 507FF0 at 45209A seems to decide about which race's buildings to use. At least disabling it by nops caused them to become romulan ones. It still upgraded to type 2, but additionally, eventually dependent on population number, I got laboratories which never has been the case before. Oh, and I got some less orbitals, but I think that has been the case as well with not calling the terraformadjustment.

Edit: Correction, the call to 597FF0 at 45209A also applies the population number!! Jumping to return here causes no upgrade and no population growth taking place!! Replacing it by nops will confuse the upgrading and let it upgrade to romulan ones in my case, but population will still get updated cause of later calls to same function. It is also called on every single upgrade and might be a general call to apply changes. Jumping to return just after the call at 45209A causes population to grow, but not being updated in screen before minor joins! So there must be another call to update stats in screen in the end or something (maybe somewhere after having build the single orb).

Posted: Mon Jul 20, 2009 7:01 am
by Flocke
Some good news, adjusting population [ebx+40] right after the call to _adjustMinorTerraforming (moved some nops to get space) skips the upgrading issues I encountered earlier, population gets updated correctly as well as the amount of buildings. The only issue this is causing is no additional planets being terraformed, resulting in population exceeding terraform max. But population will get readjusted on join to match the terraform maximum. ;)

This means that the troubles I encountered definitely come from the _adjustMinorTerraforming :?

Edit: @DCER, I tried to follow your changes, but it's quite hard to look through. Anyway, I think the issues concerning upgradings could be due to the missing call to 507FF0, that you've moved to the building upgrading part. It might store more than new population. Remember my strange issues with _adjustMinorTerraforming! In some cases I got cardssian type2 buildings and sometimes ferg ones. And removing the update also caused upgrading buildings not taking place. Cause now there's much code in between, this might cause troubles. Maybe call it once after adjusting terraform and jump to a position below of it in the build-upgrading loop so it can still be used for the jump back dependence but doesn't get called twice.
Cause I dunno much about the changes you've made, I think it'll be easier for you to test it out. :)

Posted: Mon Jul 20, 2009 11:48 am
by DCER
Interesting.

I'll be gone from tomorrow till saturday, so I won't be able to look into it then.

I'm a bit confused here... sub_507FF0 get's called after every error message loaded for every building type and doesn't really seem to be loading the system at all.

If you look at the graph in IDA of the modified version you can see it's basically the same as the original, except that the upgrade portion is cut out and put into it's own function. So the first one - after population gets adjusted continues with ships and orbitals.

Maybe calling the terraform function twice is the right solution.

Also just checked and sub_507FF0 get called all over the place after the message gets moved to eax which this function then takes as an argument. If you look at it, it doesn't seem to be doing much at all and at the end it calls sub_5079E0 which seems to be used for dumping debugging text into random%c.txt. I think this function might just be debug code - a turned off left over. Lots of those left in botf :)

Posted: Mon Jul 20, 2009 11:59 am
by DCER
My guess is some parameter is not being passed via the stack that should have been. This is of course because each function reserves it's own space on the stack.

This is needed since each function does the push and pop dance anyway to preserve register values from the calling code.

I've checked all the writes to the stack in the original, but not in the called functions.

The other option are the registers, but I've checked those as well (although I could have missed something).

Posted: Mon Jul 20, 2009 1:11 pm
by Flocke
DCER wrote:I'll be gone from tomorrow till saturday, so I won't be able to look into it then.
No problem, want to get back programming anyway, hehe.
DCER wrote:I'm a bit confused here... sub_507FF0 get's called after every error message loaded for every building type and doesn't really seem to be loading the system at all.
I'm confused as well, but having checked it again, all races seem to be affected in population growth. Not only that they don't jump when they should, they jump some turns later when they shouldn't! :roll:
However, I think it's more a side effect of EL conditions like upgrading settings being set, cause with returning after the call to 507FF0, some races kept updating growth in screen while the talarians didn't.
It's just strange. But I currently only have the explanation, that the place causing the issues regarding population growth is to be found somewhere later and just get's affected by this call.
Think I'll try disabling code to the essencial part for population growth. Regerding the upgrades, we might have to try it the other way around.