Fixing SMACX Bugs

[scient]

I'm sorry, I should have been more specific. It's if a unit is actually in the same tile you're trying to move your unit to. Also, it's not specific to any faction. The check obtains the raw unit id and if it's not set to -1 (no units) then it skips over (base->land) check. So check doesn't discriminate whether unit is yours, friendly, or enemy. It doesn't take into account surrounding tiles (ie not ZOC) just the one you're moving to.

Before it even gets to this check, if you try to move an unit either from transport or from sea base into square with another factions unit (treaty/war) it checks if your unit has amphibious pods ("Only units with amphibious pods may attack from sea"). So that's not an issue. You can move on top of your own units / pact units fine as long as you meet the checks.

I identified the other checks so the only way you can skip over "base -> land" check is if unit has amphib pods, unit is AI (CPU not automated), unit is coming off a transport (in or out of a base), or there is a transport (air/land/sea) in the base. I think this set of checks pertain specifically to sea->land movement.

If anyone can think of something this might potentially be used for, I'd be more than happy to test it out.

I think I've come across a minor bug. You can't move units even with amphibious pods into pact factions sea bases. I thought this might be a bug because there is no restriction in being able to move into land bases so why should there be one for sea?

[vyeh]

I confirm the bug. Movement to and from pact bases should be identical to your own bases. Since a non-amphibious unit can move from a transport into your own sea base, it should be able to move from a transport into a pact mate's base.

It's even worse for an amphibious unit. An amphibious unit can move into an empty enemy base, but it can't move into a pact mate's base!

I don't understand the meaning of, "If anyone can think of something this might potentially be used for, I'd be more than happy to test it out."

[scient]

I confirm the bug. Movement to and from pact bases should be identical to your own bases. Since a non-amphibious unit can move from a transport into your own sea base, it should be able to move from a transport into a pact mate's base.

It's even worse for an amphibious unit. An amphibious unit can move into an empty enemy base, but it can't move into a pact mate's base!

I'll have to look at it but I bet there is a check missing whether or not you have pact with faction. Will have to look at land->land base code to see how it does it there.

I don't understand the meaning of, "If anyone can think of something this might potentially be used for, I'd be more than happy to test it out."

If you can think of any thing that the check I'm removing, skipping over amphibious base->land checks if there is another unit (pact/own) in tile you're moving to, might be used for something. I can't think of any instance where an unit going from base->land should be able to bypass all restrictions just because there is an arbitrary unit in the tile it's moving to.

[vyeh]

Remember the issue with the repair bay where it checked for transport when it should have been checking for non-transport?

When a transport is a sea unit, a non-amphibious unit can move from a land square to the transport even though the transport is in the sea.

It is possible that the code was meant to allow a land unit that was in a sea base to move to a land transport even if it does not have amphibious ability.

I did some testing. Normally a non-amphibious unit can not move from land to an adjacent sea base unless there is a transport in the sea base. (Error message: "The channel between a sea base and dry land can only be crossed by units with the "Amphibious Pods" ability--unless a transport unit is available in the base.")

However,

(1) if there is a land transport in the same square as the non-amphibious land unit, the land unit can move into the sea base.

(2) more surprising, the land transport can move into the sea base!

(3) the land transport can also move from the sea base to an empty adjacent land square (so it can be the available transport unit in the base -- unlike the repair bay where a unit couldn't heal itself, it can provide its own transport out of a sea base).

And a non-amphibious unit that is in a sea base is able to move onto an adjacent land transport unit, so there isn't a sign error.

I think we always want to make it possible for a land unit to move to an adjacent transport unit no matter where the transport unit is. So whatever your fix, see if a non-amphibious unit in a sea base can move onto an adjacent land transport.

[scient]

That does make sense. The transport check for base->land doesn't discriminate against chassis so you can use air/land/sea. I didn't know about ground transports could go from land->sea base, good catch. I agree that the check would make more sense not if there is another unit on other side but if that unit is a transport. I can just emulate the check it does further down to see if unit in base has transport in same tile. All that gets passed to it is unit id.

So, anyone else thing this sounds correct?

[Russia4Life]

I didn't know about the ground transport being able to do that either, though I have never built or tried moving a ground transport to or from a sea base. The combination of ground transport and sea base just never seemed like it would be a good decision.

@ Scient: Your proposed fix sounds good to me.

[vyeh]

Actually a ground transport in a sea base that is adjacent to land is a good combination.

A transport module on an infantry chassis with a fission reactor is only 2 rows of minerals (a transport foil is 3 rows). Inside a sea base that is adjacent to land, it permits non-amphibious units to move freely between the sea base and the adjacent land squares.

scient,

So for travel between land and a sea base, we allow it for these cases:

(1) the traveling land unit has amphibious ability or a transport module; or
(2) there is a transport unit in either the square the land unit starts from or the square it travels to.

[Illuminatus]

Thoughts: how about changing name of this thread to SMACX Bugs and Fixing Them?

[Russia4Life]

Thoughts: how about changing name of this thread to SMACX Bugs and Fixing Them?

I am surprised it hasn't been renamed already, or made a sticky.

[Petek]

Thoughts: how about changing name of this thread to SMACX Bugs and Fixing Them?

Agreed. Or a simpler title: Fixing SMACX Bugs.

Petek

[vyeh]

I am surprised it hasn't been renamed already, or made a sticky.

You don't need to sticky a thread that is being updated several times a day. There is a joke among long-time members that making a thread a sticky is a guarantee that no one will read it.

[Psyringe]

Agreed. Or a simpler title: Fixing SMACX Bugs.

Seconded. A different thread title would increase this project's visibility, and it definitely deserves that.

Would it be possible to let scient make a new "first post" of this thread, in which he could present his project? Currently, even if the title is changed, readers would be led on the wrong track by the first posts of the thread, which solely deal with the Data Angels bug.

[scient]

So for travel between land and a sea base, we allow it for these cases:

(1) the traveling land unit has amphibious ability or a transport module; or
(2) there is a transport unit in either the square the land unit starts from or the square it travels to.

Correct. Point 1 and part of point 2 with transport in same tile are already in vanilla game. So my only change would be to alter it so that only transports in the "move to" tile will let unit move rather than any unit. Pretty much like if you had a land unit going from land->sea with transport in "move to" tile except with bases. From all the evidence, I think this makes sense and was what was intended with that check. This is easy to sort and will be in next release.

Renaming it "Fixing SMACX Bugs" sounds good. I could start a new post with changelog of current readme (and that title) then Illuminatus could split this topic and merge everything from my first post onward into new thread. Or you could create a sub-forum.

[Ell_man]

Renaming the topic would be a good idea, and a sub-forum would be even better. I personally didn't read the topic until today because of the title.

One bug/oversight is about the AI's placement of condensers. I find that on the rare occasion that the computer builds them, they put them on rocky tiles, preventing the condenser from making any nuts in its own square! The condensers are somewhat helpful because they increase rainfall in adjacent squares. I don't think any player would ever put a condenser on a rocky square though. I think preventing the computer from placing condensers on rocky squares would be a worthwhile improvement.

Also, would you be able to look into how the computer makes its terraforming and tile working choices? The computer appears to weigh nuts/mins/energy differently throughout the game when selecting tiles to work or terraform. Early on it appears the computer values nuts and minerals highly and energy marginally and later they value energy more.

What determines when an AI will construct a Thermal Borehole?

This is suggestion is probably better suited for a mod than a bug fixing patch. The computer will build far too many units and choke itself on unit supply. Telling the computer to "stop" building units when it is spending 3/4s(or some other limit) of its minerals on support would make the AI better.

Darsnan's quote from post 319

OK, I don't think the following items are bugs, but rather that the original programmers intended for the AIs:

1) with Raise Land and Lower Land disabled in the alpha(x).txt, the AIs are still able to raise land (and note the WP is not available to the AIs, either).

2) Before the AIs have researched the appropriate technology they are able to build roads in fungus.

I think these options were programmed in as cheats to make the AIs more competitive, and should not be considered bugs. Anybody have any thoughts on this?

I agree these should not be considered bugs. If an AI is stuck on a small island, it will raise terrain in order to have more space to expand to. This compensates for the AI's poor use of transports. In addition to raise terrain, the computer can also build roads and sensor arrays if these are disabled or require tech in alphax.txt.

[scient]

I plan on improving the AI at some point but that's going to be a huge task. For the next update, I'm focusing on resolving a number of combat related bugs. The largest will be overhauling combat morale which I've already partially started. Then there is psi combat issue and some other minor things reported in last few pages.

From my understanding, any improvement to the AI will also result in better automated formers since autoed formers are basically acting the like AI. Two for one special I hope.

A subform would be nice to break up the reported bugs into different threads. Like crashes in one, combat in another, exploits, misc, etc. Also, contacting someone at EA to try and get the go ahead to post sans safedisc exe has been put into motion. Hopefully that will work out and then I can start posting fixed exe publicly on here. If it ends up I can't post it on here, someone has already kindly offered me forum area and hosting. While it will be a pain to pack up and move, doing this via PM really sucks. :/

So soon there will be public release one way or another.