Combat stack limit

[Spocks-cuddly-tribble]

Your big battle could answer few important questions. use max 711 ships to allow tactical combat -> save new slot for prepared OK combat tests

in current test it is less than 600 ships = fail
I was able to do combat if I lowered how many phasers each ship has.

So I take it the old saved game with the 711 ships battle was with weaker low tech ships with fewer weapons per ship and/or and outdated mod version?

Do you still have a saved game with a big battle (say 500+ ships) for my suggested tests?

Removing the sign for all word object ID codes (double limit) is a massive effort (albeit I collected most locations for patch).
The requested test results (battle below, but close to the limit) are mandatory to determine the required course of action for the code setup.

[Flocke]

Do you still have a saved game with a big battle (say 500+ ships) for my suggested tests?

If not, with UE you can easily add a few thousand ships if I didn't break it again.
Or does it fail with MP games?

[Spocks-cuddly-tribble]

Or does it fail with MP games?

MP should have nothing to do with it. But AI control of at least one fleet would be nice for AI code lag tests.

One factor is max number of total objects that 'could' be rendered in this combat (number and perhaps max index is word signed). But I expect further issues. So we need to kow the memory fix works with 500+ ships battles with no issues. If there is really a multiplicative memory matrix required (I hope this is a bug in the code) then we're out of luck. I don't intend to assign 4-16GB memory for this....

[thunderchero]

So I take it the old saved game with the 711 ships battle was with weaker low tech ships with fewer weapons per ship and/or and outdated mod version?

Do you still have a saved game with a big battle (say 500+ ships) for my suggested tests?

Removing the sign for all word object ID codes (double limit) is a massive effort (albeit I collected most locations for patch).
The requested test results (battle below, but close to the limit) are mandatory to determine the required course of action for the code setup.

the 711 ship was MUM but too many changes has bben made for save to still be compatible.

but I do have a FMPM save I got from discord
current beta 6a
fluid MP mod
1366 x 768
Cardassian fleets already moving to target combat 16.7 -> cordian 18.9

game3.sav

(192.02 KiB) Downloaded 54 times

just hit turn and game will crash as soon as "fight" button selected with stack error.
note; this saved game was switched from MP game so Ferengi AI should not move.

if you change top 5 fleets of cardassians from moving combat will start.

[Spocks-cuddly-tribble]

if you change top 5 fleets of cardassians from moving combat will start.

Combat renders initial ship display and move camera zoom-out (+1GB RAM used -> 1999 no PC did even have that kind of RAM, only HDD paging file).

But crashes when ending turn. Code for AI commands. It doesn't like the changed player empires bitmask from the MP saved game:

Code: Select all

File: ..\..\source\game\military\battle.c, Line: 841, 0

So i have to create hex patch to restore AI codes: viewtopic.php?p=57758#p57758

Good news so far:

- code for AI commands causes no lag in automatic battle -> my new 'AI solo commands' patches are fine for larger battles
- if combat lag is an object rendering issue MPR++ might be able to improve this (if memory fix works)

Tactical combat lag also happens in a player vs player battle, right -> So it must be a rendering and/or 3D movements issue (unlike the AI turn lag)

[thunderchero]

But crashes when ending turn. Code for AI commands. It doesn't like the changed player empires bitmask from the MP saved game:

Code: Select all

File: ..\..\source\game\military\battle.c, Line: 841, 0

So i have to create hex patch to restore AI codes: viewtopic.php?p=57758#p57758

when you have a moment could you upload the edit/functional saved game please.

and yes turn lag in combat is same for player vs player as it is for player vs AI

[Spocks-cuddly-tribble]

It won't help with combat tests since Ferengi AI disperses its fleets: (but you could set all ferengi ships to map speed 0 in shiplist.sst )

game1.sav

(192.02 KiB) Downloaded 54 times

If MPR++ replaces all BotF default rendering codes it should also bypass the 32767 objects limit and the GB memory leak

[thunderchero]

If MPR++ replaces all BotF default rendering codes it should also bypass the 32767 objects limit and the GB memory leak

MPR++ only replaces mpr97.dll so all code in trek.exe is still used and so is 32767 objects limit and the GB memory leak.

that saved game was originally played on MPR++

EDIT:
to prevent Ferengi from moving

but this sub calls "HashTable_Search" at 405F82, if this code is noop turn processing is instantaneous again

at 0x5382 change E8 09 45 11 00 -> 90 90 90 90 90

now this will disable AI ship movements/orders but rest of AI and game will continue and does not cause CTD
I am guessing this code repeats for each ship and each possible order to determine the best order to use.

but ferengi retreat on turn 2

[Spocks-cuddly-tribble]

Disabling all AI codes crashes tactical combat with no log for me, but I used the idea to remove the call for new AI ship & labor orders.

Removed 7 task forces from my fleet so the Ferengi didn't retreat:

- memory fix seems to work with no issues (will be added to ECM + other unneeded calculations removed)
- combat lag is not only number of ships/objects -> turn 2 after some ships destroyed was worse in a test (memory fix doesn't matter)
- I'll not look into removing the objects limit (lag is too bad - doing my dishes was faster) -> MPR++ update would be better for both issues


One a side note, disabling the ship scrapping exploit, and therewith enforcing the economics BotF was programmed for, will not allow fleets like this.
So the programmers did never even consider limits and lags like this given the max possible empire pop-support in default maps.
Even in ECM large with extra AI cheats the Ferengi AI sometimes scraps a few warships to 'stay in the game'.

[Flocke]

If MPR++ replaces all BotF default rendering codes it should also bypass the 32767 objects limit and the GB memory leak

MPR++ actually makes things worse, cause like TC said it keeps old code in tact to keep MP battles working plus the new rendering code uses same memory and with MPR++ there were large new textures introduced that are not properly cleared from the memory. In addition it does not use any ship replication technics but the vertices for each single ship are loaded by single. Therefore it is easy with MPR++ to reach the 4GB limit.

That was one of the main issues I faced and required to refactor lots of the code, which didn't make sense to me when same time the whole Ogre 3D engine was split to two projects with the newer one doing everything different and it being completly unclear how it's going to proceed with all the main developers having left.

In other words, already then it was pretty clear I had to redo it all and move to another engine. Other engines I found applicable however work diffferent in that they enforce to run their own 64-bit executable and only plugin any other code. Given 64-bit applications more and more become a requirement for newer graphics anyhow and with MPR++ I already reached memory limit by the large ship textures I then started to look into interfacing BotF as a library and looked into inter-process communication, which made things even more complicate.

With my troubled life at that time I was pretty overchallenged. And before it makes sense to have another look into porting the engine, I'd first need a better code base to interface the trek.exe application. That is the BotF extension framework I want to look into next when I find time.

[Spocks-cuddly-tribble]

By default 'Software' is slowest rendering mode -> any chance to improve this? viewtopic.php?p=43287#p43287

Trek.exe code switches do nothing:

Code: Select all

5B1870 SOFTWARE_3D_ini_setting

5CD660 DIRECT3D_1_3DFX_2
5CD664 DIRECT3D1_1_special

5CAEC0 for_DIRECT3D_3DFX_1

The next question: Lag impact of rendering vs 3D movement calculations?

Changing trek.exe movement codes (not weapons/targets) for all ship commands to 'hold' could test this (so only torpedoes move):

Code: Select all

55440A           jmp   off_5543C0[eax*4] -> jmp 554507
 
0x15380A

0055440A     E9 F8000000    JMP 554507
0055440F     9090           NOP

[thunderchero]

By default 'Software' is slowest rendering mode -> any chance to improve this? viewtopic.php?p=43287#p43287

I don't remember ever testing rendering modes/files in combat.
just add one more thing to my list....

The next question: Lag impact of rendering vs 3D movement calculations?

Changing trek.exe movement codes (not weapons/targets) for all ship commands to 'hold' could test this (so only torpedoes move):

Code: Select all

55440A           jmp   off_5543C0[eax*4] -> jmp 554507
 
0x15380A

0055440A     E9 F8000000    JMP 554507
0055440F     9090           NOP

ok 2 things to my list.....

[thunderchero]

By default 'Software' is slowest rendering mode -> any chance to improve this? viewtopic.php?p=43287#p43287

I don't remember ever testing rendering modes/files in combat.
just add one more thing to my list....

All rendering modes/dll files took the exact same time from selecting "turn" to first combat render

tested hades 1.1 and hades 2.2 files and modes

The next question: Lag impact of rendering vs 3D movement calculations?

Changing trek.exe movement codes (not weapons/targets) for all ship commands to 'hold' could test this (so only torpedoes move):

Code: Select all

55440A           jmp   off_5543C0[eax*4] -> jmp 554507
 
0x15380A

0055440A     E9 F8000000    JMP 554507
0055440F     9090           NOP

ok 2 things to my list.....

hold did not work for test combat, since Ferengi is hailing if Cardassians Hailed rendering was instantaneous.
if I ordered fast attack to hail and charged with command time was 50% quicker than if all ships charged.

when they did hold (canceled hail) it took much longer between "turn" to first combat render. (expected since now twice as many ships are firing.

So I would say lag is mostly rendering or calculations of phaser/torpedo vectors and effects of combat.

[Spocks-cuddly-tribble]

All rendering modes/dll files took the exact same time from selecting "turn" to first combat render

tested hades 1.1 and hades 2.2 files and modes

Dang it. I hoped involving/using GPU rendering could help (even rewinding in playback mode has a lag).

Ferengi is hailing if Cardassians Hailed

AI files were re-created from scratch, this resets: AI treaty agendas, sympathy, counter for good/bad experiences with other empires...
So you have to declare war two turns before the combat (war declaration takes effect after combats). Prepared saved game for the downloading lurkers:

game2.sav

(192.02 KiB) Downloaded 28 times

But you must disable/nop (to prevent AI from moving ships):

Code: Select all

0040731F           call  AISysUnts_LABOR__AIShpUnts_ORDERS

When switching AI to cardassians also remove (to prevent them scrapping ships):

Code: Select all

0040DDF7           call  AI_Ship_Scrap_if_Range_Loss_Credit_Deficit

I would say lag is mostly rendering or calculations of phaser/torpedo vectors and effects of combat.

I disabled rendering and effect of movements (using my above forced hold code), then weapons, then both -> still a bad lag.
So main lag is not rendering but the actual 3D combat calculations.


Btw, FMPM needs this fix (just cosmetics): viewtopic.php?p=54579#p54579

From researching the fix I remember BotF calculates 3D combat at least 3 times with different codes (so stuff can go out of sync) for movements, weapons and event log (bottom lisplay).


For ECM I plan on removing this and using memory fix (version 1 is OK):

Code: Select all

00530EF3           imul  edx, [esp+4], 98h                 ; R
00530EFF           imul  edx, [esp+4], 98h                 ; R
00530F0B           imul  edx, [esp+4], 98h                 ; R
00530F1A           imul  edx, [esp+4], 98h                 ; R

But it won't really help with combat lag.