All in one 2.0.1 beta 5 available

[Spocks-cuddly-tribble]

in my opinion if BOP loads in UE and does not error on saving "UE is good on BOP".

Even this would require exception codes to keep UE from editing certain structure features, at least without confirmation requests and warning about the BoP issue (group type / building sequence)?

[thunderchero]

in my opinion if BOP loads in UE and does not error on saving "UE is good on BOP".

Even this would require exception codes to keep UE from editing certain structure features, at least without confirmation requests and warning about the BoP issue (group type / building sequence)?

yes and no, in the next version of UE all trek.exe code changes can be seen before they are changed. You are also able to copy those changes you want to keep and do them manually.

[Spocks-cuddly-tribble]

Flocke's question remains: Would you even consider editing the unused BoP upgrades back from special to main group in the AIO version (if there is no issue)? But your (13 years old!) note says the possible issues are very hard to test (AI behavior on conquered home systems).

[thunderchero]

Flocke's question remains: Would you even consider editing the unused BoP upgrades back from special to main group in the AIO version (if there is no issue)?

no that would be left to the user editing BOP or Gowron

I did a quick test today of BOPL 1366 as in AIO beta 5
played as feds T1 many impossible large irregular (large map version) no random or borg
did 300 turns saving at turn 1, 100, 200, 300 (I did nothing between turns)
on quick review of saved games did not see anything strange by AI, but saves need to be looked at much closer.

[Flocke]

For BOP I noticed another minor incompatibility for the galaxy generation that definitely should be fixed on BOP:
"Validation error at segment 0x000AE70A [ galaxyShape_ringCoreSize_ae70a ]: ♦ Read unknown modification 'B9' ♦ but expected 'BA'."
"Validation error at segment 0x000AE594 [ galaxyShape_ringCoreSize_ae594 ]: ♦ Read unknown modification 'B9' ♦ but expected 'BA'."

When you check the asm code at file offset 0xae70a, he likely experimented setting ecx to some other value than 6, while by the original code it was copied from eax which is set to 6 as well. Since there is no call in between, copying eax must be same.
By his code change edx, the ring core size, on the other hand is zeroed, so the original mov eax, 6 must be changed to mov eax, 0 to be same.
Same counts for file offset 0xae594.

The other changes can be kept, but I refuse to write an exceptional UE patch for this. It is super easy to fix on BOP but cause lots of headache when I attempt to handle it by UE.

Original is:

AUTO:004AF300 loc_4AF300:                             ; CODE XREF: sub_4AF020+2AFj
AUTO:004AF300                 cmp     ah, 2
AUTO:004AF303                 jnz     short loc_4AF336
AUTO:004AF305                 mov     eax, 6
AUTO:004AF30A                 mov     edx, 0Fh
AUTO:004AF30F                 mov     edi, 3DCCCCCDh
AUTO:004AF314                 mov     ds:dword_5CB338, eax
AUTO:004AF319                 mov     ds:dword_5CB324, edx
AUTO:004AF31F                 mov     ecx, eax
AUTO:004AF321                 mov     ds:dword_5CB304, edi
AUTO:004AF327                 mov     ds:dword_5CB314, 19h
AUTO:004AF331                 jmp     loc_4AF0B5

BOP is:

AUTO:004AF300 loc_4AF300:                             ; CODE XREF: sub_4AF020+2AFj
AUTO:004AF300                 cmp     ah, 2
AUTO:004AF303                 jnz     short loc_4AF336
AUTO:004AF305                 mov     eax, 6
AUTO:004AF30A                 mov     ecx, 6
AUTO:004AF30F                 mov     edi, 3DCCCCCDh
AUTO:004AF314                 xor     edx, edx
AUTO:004AF316                 mov     ds:dword_5CB338, eax
AUTO:004AF31B                 mov     ds:dword_5CB324, edx
AUTO:004AF321                 mov     ds:dword_5CB304, edi
AUTO:004AF327                 mov     ecx, 6
AUTO:004AF32C                 nop
AUTO:004AF32D                 nop
AUTO:004AF32E                 nop
AUTO:004AF32F                 nop
AUTO:004AF330                 nop
AUTO:004AF331                 jmp     loc_4AF2E0

Fixed should be:

AUTO:004AF300 loc_4AF300:                             ; CODE XREF: sub_4AF020+2AFj
AUTO:004AF300                 cmp     ah, 2
AUTO:004AF303                 jnz     short loc_4AF336
AUTO:004AF305                 mov     eax, 6
AUTO:004AF30A                 mov     edx, 0
AUTO:004AF30F                 mov     edi, 3DCCCCCDh
AUTO:004AF314                 mov     ecx, eax
AUTO:004AF316                 mov     ds:dword_5CB338, eax
AUTO:004AF31B                 mov     ds:dword_5CB324, edx
AUTO:004AF321                 mov     ds:dword_5CB304, edi
AUTO:004AF327                 mov     ecx, 6
AUTO:004AF32C                 nop
AUTO:004AF32D                 nop
AUTO:004AF32E                 nop
AUTO:004AF32F                 nop
AUTO:004AF330                 nop
AUTO:004AF331                 jmp     loc_4AF2E0

highlighted is the conflicting instruction change

Other than BOP btw MUM seems to have completely changed all of the galaxy shape code. That changes are so massive on MUM I wonder is there any documentation? I very much doubt that'll be supported by UE.

[thunderchero]

I very much doubt that'll be supported by UE.

BOP; this is special code for no core on ring type (intended)
MUM; this is special code for 4 irregular types each with different densities.

I would not expect any special code for either.

[Flocke]

BOP; this is special code for no core on ring type (intended)

No, that is special code for not being UE compatible.
Above green fix changes nothing but to make it compatible again.

MUM; this is special code for 4 irregular types each with different densities.

Found the documentation I need:
viewtopic.php?f=4&t=3593

But I think I rather keep it for another time. Galaxy generation I wanted to hook into some time anyhow to allow for better control.
I will however check that UE auto-correction doesn't conflict with it.

[thunderchero]

BOP; this is special code for no core on ring type (intended)

No, that is special code for not being UE compatible.
Above green fix changes nothing but to make it compatible again.

no problem will adjust
AUTO:004AF30A mov edx, 0
AUTO:004AF314 mov ecx, eax

Found the documentation I need:
viewtopic.php?f=4&t=3593

I am guessing you are looking at patch file for info

here is a more detailed patch

irregular.patch

(5.49 KiB) Downloaded 51 times

hope this helps, but if it causes you too much issues I could always do option 2 again

[Flocke]

no problem will adjust
AUTO:004AF30A mov edx, 0
AUTO:004AF314 mov ecx, eax

thanks

same applies to loc_4AF18A:
AUTO:004AF194 mov edx, 0
AUTO:004AF19E mov ecx, eax

I am guessing you are looking at patch file for info

here is a more detailed patch
irregular.patch

hope this helps, but if it causes you too much issues I could always do option 2 again

Thanks, looks much more detailed! I will not implement this for now, but might refer back to it some other day when I continue to investigate the galaxy generation. Remember, galaxy generation is one of the sub routines that already got hooked by QuasarDonkey before and even made it to the mpr++ sample extensions. So there is great potential to do some alternate implementation.

[thunderchero]

thanks

before I start making changes to BOP here would be changes for beta 6

Code: Select all

4AF30A 0xae70a B9 06 -> BA 00
4AF314 0xae714 31 D2 -> 89 C1 
4AF194 0xae594 B9 04 -> BA 00
4AF19E 0xae59e 31 D2 -> 89 C1

[Spocks-cuddly-tribble]

galaxy generation is one of the sub routines that already got hooked by QuasarDonkey before and even made it to the mpr++ sample extensions. So there is great potential to do some alternate implementation.

Hook for 'better control' = easier editing options for default features or patches with new features?

before I start making changes to BOP here would be changes for beta 6

Based on above BoP asm this looks good. Gowron made many unneeded code changes (to make the code better readable?)


@ UE Read/Write Error Validation error/unknown modification

Wouldn't it be an easy workaround (e.g. MUM morale buildings) to just add the option to modifiy value at position X regardless of unexpected opcode?


Also I doublechecked the pending ECM patches for possible UE issues.

'If' (I doubt it) UE supports editing randoms events, this patch changes the locations of the difficulty level time delays: viewtopic.php?p=18755#p18755
But some other old patches (e.g. for AI) do this as well.

[Flocke]

before I start making changes to BOP here would be changes for beta 6

Code: Select all

4AF30A 0xae70a B9 06 -> BA 00
4AF314 0xae714 31 D2 -> 89 C1 
4AF194 0xae594 B9 04 -> BA 00
4AF19E 0xae59e 31 D2 -> 89 C1

interesting, there seem to be alot of op code duplicates
encoding it with x32dbg I get the following hex code:

Code: Select all

4AF30A 0xae70a B9 06 -> BA 00
4AF314 0xae714 31 D2 -> 8B C8 
4AF194 0xae594 B9 04 -> BA 00
4AF19E 0xae59e 31 D2 -> 8B C8

I already found other op code duplicates. e.g. xor edx, edx can also be encoded as 33 D2
from what I read on the web it however makes no difference
and important to UE is just the first instruction where it expects 'BA' for the op code
so yeah, both are fine

[Flocke]

Hook for 'better control' = easier editing options for default features or patches with new features?

New features ofc! It actually makes more sense when we have a new UI, where like with mpr++ you can add additional menus. Till then some text file based options could be implemented for detailed configuration of the already selectabe galaxy shapes.

I am not set where I begin, there is so many one could address, but for the start the next year I'd love to continue effots on extending the game and focus to create a basic library to interface many of the basic sub routines.

One thing I'm tempted to look into e.g. is to hook into the stbof.res loading routine and add an option to lookup missing files in a shared secondary folder. Should reduce install size and simplify installer.

@ UE Read/Write Error Validation error/unknown modification

Wouldn't it be an easy workaround (e.g. MUM morale buildings) to just add the option to modifiy value at position X regardless of unexpected opcode?

No, this basic validation really is great to detect and avoid coding mess. Further UE has no mod detection, but you'd need different configurations for different mods plus your modifications of mods. Adding all those options leads to alot of mess where you easily forget on some changes, not to speak of all the needed code refactoring to make all those locations configurable.

Furthermore many patch locations have duplicates, some are overridden by mods, some become completely unavailable.
MUM morale buildings here are a good example where even the data type is changed. It wouldn't be enough to tell the new location, UE needs to be aware of what values it can write - which is validated by the op code.

'If' (I doubt it) UE supports editing randoms events, this patch changes the locations of the difficulty level time delays:

No worries, that's not on my list.

[Spocks-cuddly-tribble]

from what I read on the web it however makes no difference

Most annoying OllyDbg issue is sometimes different copcode length and in very rare cases slightly changed behavior (cycles/special flags) depending on processor, firmware or the stuff the asked nerds are on... (shouldn't matter for BotF).

this basic validation really is great to detect and avoid coding mess.

Yes, it would be a 'mess up at your own risk' option. I don't argue against your point, but funny thing is that UE doesn't understand the requested opcode frame. In this example it allowed input values of invalid range (IDs >127) but rejects the same values with a working, but unkown frame.

[thunderchero]

before I start making changes to BOP here would be changes for beta 6

Code: Select all

4AF30A 0xae70a B9 06 -> BA 00
4AF314 0xae714 31 D2 -> 89 C1 
4AF194 0xae594 B9 04 -> BA 00
4AF19E 0xae59e 31 D2 -> 89 C1

I start getting ready to patch installer trek.exe's but noticed the "large map" version had different values

4AF30A 0xae70a B9 0B -> BA 00
4AF194 0xae594 B9 0F -> BA 00

any potential issues?