| Re: Massive enemy counterattacks... in all major cities[message #316384]
|
Wed, 20 March 2013 01:05  
|
|
| Flugente |
 |
Messages:3499
Registered:April 2009
Location: Germany |
|
|
The way the code currently handles enemy groups, groupsize is stored as an UINT8. Curiously, The maximum groupsize value from the ini is INT32. But this is off the point - an UINT8 can only have a max size of 255.
For this reason, battles of up to 255 soldiers might be possible - though I think you'll get overflows much earlier. For example, the total number of hostiles is also stored as an UINT8, and it includes the army and creatures. More will not be feasible, as you'll get overflows on various locations.
I have no idea if ancient exes had other limits (I doubt it, as then at some point someone would have to have reworked that) or if they hacked it (by, say, spawning more enemies once there was room). I personally won't delve into code more than 3000 revisions old.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Massive enemy counterattacks... in all major cities[message #316393]
|
Wed, 20 March 2013 01:46
|
|
| Flugente |
|
Messages:3499
Registered:April 2009
Location: Germany |
|
|
In short: you cannot change this without editing the code.
The variable in which the group size is stored is an UINT8. Long story short, and UINT8 can have values from 0 - 255. So:
UINT8 group_a_size = 240;
UINT8 group_b_size = 40;
UINT8 sum = group_a_size + group_b_size; // AARGH, sum becomes 24 ! We just lost 256 loyal soldiers!
the warp memory. In the best of cases, the game will realise that and mercifully crash, giving you a chance to analyze and correct it. In bad cases, an overflow remains undetected - until the effects can be observed much much later, and you'll have a hard time figuring out what was wrong.
Overflows are bad.
This specific code bit is relatively painful to alter. If we want to, say, increase the groupsize to UINT16 (which would give us up to 65535 enemies to play with), we'd have to alter (or at least inspect) every instance where that bit of code is used - or that could influence it. As a UINT16 is bigger than an UINT8, we will inevitably alter the size of the GROUP-structure - which will alter savegames unusable, unless we repair that, and can cause other headaches. This would only be the immediately noticable effects - there might even be other longterm effects we do not yet know (like the strategic AI decision running bogus, as it cannot handle such sizes properly).
@Uriens: Yes, we can prevent overflows by being careful and reasonable - but the game can still crash. It could happen that it notices that after we battled the 24 soldiers (and won the battle), one group taking part in the battle had 240 soldiers. Thus the battle msut still be ongoing. Thus we cannot end this battle and have to retreat in tactical - upon which the game crashes. It will try do delete the soldiers in the group (216 must still be present) - but cannot find any. Crash.
[Updated on: Wed, 20 March 2013 01:50] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Massive enemy counterattacks... in all major cities[message #325695]
|
Wed, 25 September 2013 22:33
|
|
 Uriens |
 |
Messages:344
Registered:July 2006 |
|
|
Just had Alma counterattack. Something wasn't right there. 4 groups showed up next to Alma, 2 went to H13 sector where Military Base is and attacked it, but the remaining 2 stood outside of Alma somewhere around J12 and just waited. Then, after a while one just wondered of in the direction Meduna and the other moved around a bit (seemingly randomly) and then attacked mine sector alone.
It's as if those 2 groups lost orders and then were given some random or generic ones I notice when enemy group tries to catch my mercs and don't manage to get to them - they just wonder around randomly.
Also, I have noticed some randomness in enemy group behavior which makes them sometimes attack other enemies or positions like SAM sites or city sectors while they are on their way to their destination. If they actually succeed in the attack, then they keep moving to their original destination.
For example, in the counterattack in Chitzena, if you take SAM site south of it before you trigger counterattack, some of the enemy groups that are going for Chitzena sometimes (not always, and it may change if you load/save game) will attack that SAM site on their way. Other times, when 3 enemy groups are waiting 4th one to start the attack, one enemy group may wonder off one sector away before counter attack starts. Happened in Chitzena quite often, also loading/saving seems to produce different results. One time all 4 groups (in Chitzena) would attack me, one time 3 would and 1 would wonder off and on some rare occasion 2 of them would wonder off.
Didn't see enemy FUBAR counterattack so badly as the one in Alma though but I suspect that this randomness may be the reason why some counterattacks just have part forces in them or even fail to trigger (for example, group that is supposed to initiate attack wonders off to attack something on the way and gets killed).
I'm not against randomness at all but it messes up counterattacks, so (if possible of course) disabling random behavior for those enemy groups that are going to counterattack location could be a good idea.
Report message to a moderator
|
Master Sergeant
|
|
|
|
| Re: Massive enemy counterattacks... in all major cities[message #325697]
|
Wed, 25 September 2013 22:52
|
|
| Flugente |
|
Messages:3499
Registered:April 2009
Location: Germany |
|
|
Setting up counterattacks is tricky. Not because of the stuff one can do, but because its so limited. We create up 4 groups of enemies and tell them to move near our target sector while evading the player on the way. 3 are told to wait at location, one is told to move into target sector, hopefully calling the others as reinforcements.
But we cannot control them after that. If the player takes out the 'initiator force' or the strategic AI decides to give out new orders, than that happens, I see no way around that.
The strategic AI is also hideously dumb in the way it searches for paths - that's the reason there is no attack at Alma mine: When ordered to stage west of the mine, the AI moves through the mine itself.
Report message to a moderator
|
|
|
|
|
Blog
Search
Help
Members
Register
Login
Home
