Fixing SMACX Bugs

[Darsnan]

if you finish a game and start a new one without exiting AC, the first item in each slot in the build queue from the previous game is available, no matter the prerequisites.

Didn't BlackCat already post this exploit?
Anyways, another really minor bug: in the #RULES section of the alpha(x).txt is a line governing "Max artillery range". If this line is changed from its default of 2 the AI gets to take advantage of an increase in artillery range, whereas the human player does not. Example: if the value is increased from 2 to 3, then AI arty units can bombard from a range of 3, whereas the human player is still restricted to a range of 2.

D

[scient]

A bug I've never, ever, seen mentioned, even in very comprehensive lists, is a build queue exploit.

Say you're an awful cheater against the AI- if you finish a game and start a new one without exiting AC, the first item in each slot in the build queue from the previous game is available, no matter the prerequisites. I've used this and pod popping to build satellites or Super Fusion Hovertank Formers in year one before. Loading a savegame and [control-shift Q] to start a new game works for this, too.

[It occurs to me that this might be very useful in scenario building if it's possible to apply there...]

Units produced this way are very susceptible to the transformation bug, to the extent the (hypothetical) cheater has to be VERY careful about upgrading anything or even designing anything new. I've seen as many as fifty formers transform, free of charge and all at once, to a completely different chassis, or even infantry w/ weapons. I've even seen it happen automatically when Fusion Power is discovered and the game adds the fusion powered upgrades to the design workshop.

Do with that what you will.

It sounds like a clean up issue and similar to the one BlackCat posted about in #147? I have no idea where to even begin with this level of large scale clean up and like Petek said this can make some "interesting" games.

[Petek]

A bug I've never, ever, seen mentioned, even in very comprehensive lists, is a build queue exploit.

Say you're an awful cheater against the AI- if you finish a game and start a new one without exiting AC, the first item in each slot in the build queue from the previous game is available, no matter the prerequisites. I've used this and pod popping to build satellites or Super Fusion Hovertank Formers in year one before. Loading a savegame and [control-shift Q] to start a new game works for this, too.

I couldn't reproduce this bug. I loaded a game in which the UoP had run the tech tree. I added a quantum rover supply crawler to University Base's queue. Started a new game with Ctrl-Shift-Q with the UoP. In the new game University Base the only available units/improvements were the basic ones. Is something else needed?

This bug seems to be similar to the one discussed in post #147 of the current thread, which i could reproduce.

Petek

[Buster Crabbe's Uncle]

It sounds like a clean up issue and similar to the one BlackCat posted about in #147?

Ahhh. So that's what (s)he was talking about. I didn't follow.

like Petek said this can make some "interesting" games.

Like I said, humongous potential as a modding tool if there's some way to implement it...

I couldn't reproduce this bug. [...] Is something else needed?

Was the crawler the first thing in the queue? Gimme a few minutes and I'll create a year-one savegame in unmodded SMACX- it works in SMAC, too.

[Okay here ye goes. I did nothing but load the hovertank former and then saved. -Wait. I'm gonna add my Alpha.ini to the zip. If that doesn't do it, I'm stumped.]

[BlackCat]

I'm a he

Anyway, since this bug dosen't interfere with a running game but only new, I don't think it should be fixed.

If done right, you can have Svensgaard placing a colony next to you producing a planet buster

[scient]

Didn't BlackCat already post this exploit?
Anyways, another really minor bug: in the #RULES section of the alpha(x).txt is a line governing "Max artillery range". If this line is changed from its default of 2 the AI gets to take advantage of an increase in artillery range, whereas the human player does not. Example: if the value is increased from 2 to 3, then AI arty units can bombard from a range of 3, whereas the human player is still restricted to a range of 2.

D

Easy to fix, done. There is a table of "global" variables it stores in memory with fixed offsets for all the values in alpha(x).txt. I located the value used for "Max artillery range" and will replace the currently fixed value of 3 in check if artillery shot is out of range.

[Darsnan]

Easy to fix, done. There is a table of "global" variables it stores in memory with fixed offsets for all the values in alpha(x).txt. I located the value used for "Max artillery range" and will replace the currently fixed value of 3 in check if artillery shot is out of range.

Cool!

The reason I brought this up is that in the past I have tried to generate scenarios mimicking lower gravity worlds, however this parameter has always been a sticking point in that I couldn't simulate a lower gravity effect on artillery (which in lower gravity situations should really come to the forefront!). Many thanx!


D

[Petek]

[Okay here ye goes. I did nothing but load the hovertank former and then saved. -Wait. I'm gonna add my Alpha.ini to the zip. If that doesn't do it, I'm stumped.]

I loaded the game, both with my Alpha Centauri.ini and yours. I see Gaia's Landing, but the line below the base name simply displays (), instead of the name of what's being built. When I open the base, I see that some sort of Former is being built; it could be a Hovertank Former. However, this unit doesn't appear in the Unit Workshop (nor anywhere else that I could find). Presumably these anomalies would disappear if I had the game file previous to this one.

Anyway, like the bug that BlackCat brought up, this one doesn't, IMHO, need to be fixed.

Petek

[scient]

@Darsnan: If you can think of any similar bugs where game ignores values set in alpha(x).txt let me know. They're really simple to fix.

Anyway, like the bug that BlackCat brought up, this one doesn't, IMHO, need to be fixed.

I agree.

[Darsnan]

[QUOTE=scient;5555927]@Darsnan: If you can think of any similar bugs where game ignores values set in alpha(x).txt let me know. They're really simple to fix.QUOTE]


Will do. Please note though that I will be OOT from Saturday morning till Monday evening.

D

[scient]

The way mind control works on a city is similar to that of unit. First is Nethack modification of nWorth then SE morale ladder. However, there are two checks that can modify the base SE morale value used to place it in ladder: city has Genejack Factory (-1) or Covert Ops Center (+2).

<=-2 : nWorth / 2
-1 : nWorth - (nWorth / 4)
0 : nWorth
1 : nWorth + (nWorth / 2)
2 : nWorth * 2
>= 3 : immune message

However unlike with units, in the vanilla game cities only handle range of -2 to 3. Anything above or below these would result in using 0 on ladder. This is already sorted so the only thing I would add would be a check if probe is enhanced and if so move one step down ladder.

Now I'm going to look at how success/survival probabilities are calculated to make sure that high/low morale SE doesn't bork anything (all probe actions use the same function to calculate them). I'd like peoples thoughts on the way I'm handling enhanced probe so I can finalize fixes to it.

Are there any other probe related bugs beyond enhanced probe mind control issue? I thought there was something mentioned about incorrect costs but I'm not seeing it.

edit:

Probe teams cannot attack other units directly, but they can battle one another to the death. Probe Team combat is based on the morale of the combatants. Probe Teams can attack other teams even in squares containing other units. Since Probe Teams have no “official” existence, destroying another faction’s Probe Teams does not violate a treaty or pact.

Does this mean destroying other factions probes through probe combat or with any type of unit? Because probe vs probe follows this but if you try to use any other military unit it prompts you to declare war first.

[Buster Crabbe's Uncle]

Anyway, like the bug that BlackCat brought up, this one doesn't, IMHO, need to be fixed.

I agree. Is it not the same bug, then?

Try right-clicking and loading other queue slots- if there's nothing there, or only a colony pod, we've had a fail.

the line below the base name simply displays (), instead of the name of what's being built.

Yes, it does that.

this unit doesn't appear in the Unit Workshop (nor anywhere else that I could find).

That sounds right.

Presumably these anomalies would disappear if I had the game file previous to this one.

Say what? It's year one.

[Psyringe]

Yesterday I played a quick game on a standard map, using the latest fixed exe. I didn't test anything specific, just paced through the game (which was a lost cause anyway due to underestimating the danger of starting right next to H'minee). I didn't encounter anything unusual, no crashes, etc.

Also, I tested the fix for the scrambling bug, with the save that BlackCat posted here. With regular terranx.exe, the game (as expected) crashed every time when I used my copter to attack the transport to the south. With the fixed exe, the crash never happened.

However, I thought it's a bit odd that the scrambling unit ("Tachyon Tactical" of the Drones) starts its flight from the north pole when it's displayed. Also, the message displayed reads "... near Iota Sector", but Iota Sector is on the other side of the planet. The Tachyon Tactical actually sits in "Echo Bay", a Caretaker base a few tiles to the SE.

It seems that the position of the scrambling unit isn't set properly. I don't know whether you regard it as a problem - the crash *is* fixed, so I'll rather be grateful for the fix than nitpicking about details. However, if you *do* want to fix the location of the scrambling unit too, then I'll gladly run some further tests.

Also, is there anything specific which you're currently working on that I can help with? Creating a test save for a specific problem, analyzing a specific bug, that sort of thing?

[vyeh]

Do you mean opponents SE probe value?

Since everything is multiplied, it doesn't matter whether the 25% reduction from the Nethack Terminus is taken at the beginning or the end.

It seems the manual should have said or if their Probe rating was +2 rather than +4 since the manual also says that at +3 probe bases and units cannot be subverted (p. 161).

I assume some other piece of code determines chance of success.

I never realized that there was a bonus for former or colony pod. This seems rather strange. Wouldn't it make more sense that civilians would be easier to subvert? Maybe it should be if unit is former or colony pod, divide nWorth by 2.

[scient]

Do you mean opponents SE probe value?

Sorry, yes. If faction X is probing a unit/city of faction Y, all the SE values would be from faction Y. From what I understand, faction X SE morale would only give boosts to probe unit's morale (not calculated in this area of code).

Since everything is multiplied, it doesn't matter whether the 25% reduction from the Nethack Terminus is taken at the beginning or the end.

Oh my, I fail at math. I need more tea.

It seems the manual should have said or if their Probe rating was +2 rather than +4 since the manual also says that at +3 probe bases and units cannot be subverted (p. 161).

Correct but say probe rating is +1? Or 0? The original sentence "... or if their Probe rating was +3 rather than +4" is awkward but I take it to mean that if faction Y probe rating was +4 to count it as +3. Not taking into account that this was probably a misprint and should have been "+2 rather than +3", I understand it to mean subtracting one off from probe rating rather than setting it to a fixed amount. If probe values above 3 were counted as 3 this would work out, right? Is there anything else that might shed some more light?

I assume some other piece of code determines chance of success.

Yes, like I said I'll be doing that next. It's nice because all probe related activities use one function. I've already got it mostly documented there is just one parameter I need to look into some more.

I never realized that there was a bonus for former or colony pod. This seems rather strange. Wouldn't it make more sense that civilians would be easier to subvert? Maybe it should be if unit is former or colony pod, divide nWorth by 2.

That sounds like it would make more sense but unless you can find any reference or dig up some more info I'm going to leave it alone. I agree with you that it would make more sense for civilians rather than military units to be more susceptible to mind control.

However, it checks individually this internal unit id whether or not unit is a former/pod. I guess it is possible that both conditional checks were incorrectly set to "equal to" rather than "not equal". But without more to go on, I'd like to stay away from meddling. I'm going to start a list of "questionable" changes to ask Brian Reynolds about if I ever get the chance to speak to him.

005A17E7 |. 8A81 92B89A00 MOV AL,BYTE PTR DS:[ECX+9AB892] // internal unit type value
005A17ED |. 3C 08 CMP AL,8 // check if pod
005A17EF |. 74 0E JE SHORT terranx.005A17FF // "jump if equal to value" ie. if equal, skip modification
005A17F1 |. 3C 09 CMP AL,9 // check if former
005A17F3 |. 74 0A JE SHORT terranx.005A17FF "jump if equal to value" ie. if equal, skip modification
005A17F5 |. 8BC6 MOV EAX,ESI // moving current nWorth value into EAX
005A17F7 |. 99 CDQ // ignore (handling if nWorth is negative, which won't happen)
005A17F8 |. 2BC2 SUB EAX,EDX // ignore
005A17FA |. D1F8 SAR EAX,1 // dividing nWorth by 2
005A17FC |. 8945 F0 MOV [LOCAL.4],EAX // updating nWorth's local variable
005A17FF |> 6A FF PUSH -1 // fin