Old AI bugs

[Svengali]

Those ship are extra noticeable when launching. A launch takes 10 minutes game time.
...
Am I the only one with this problem?

No, you're not alone. While writing a special mission for the new Localhero I've seen that it sometimes needs more than 20 minutes to launch a ship and the hangs with performFaceDestination were there too. Muchas gracias for the new AIs!

[Lestradae]

<thread-derailing>

... the new Localhero ...

Any news on when it's going to come along?

Impatiently waiting

L

</thread-derailing>

[Svengali]

Any news on when it's going to come along?

Difficult question.

Currently I'm having some trouble with crashes and - until I've found the reason(s) - it wouldn't make sense to continue. So it's a bit Sisyphos-work and every progress is hard work, because it is the most complex thing I've ever scripted - it has nearly nothing to do with the released version anymore and it is a lot bigger and deeply nested. So I have to think about optimization too, to avoid timeout errors and keeping it compatible with other oxps is another task (tss, I'm crazy - consulting Dr Sigmund Schmigmund). The todo-list is still ...err... long, but the already-done-list is even longer. So I really can't say next Thursday .-)

[Eric Walch]

Yesterday I found a rare bug in the minerAI.plist that resulted in the miner kept going on mining despite its hold was already filled.

I think it happened while I collided with the miner at the moment he scooped the splinter. Result of his scooping is that he generated two messages: "HOLD_FULL" and "CARGO_SCOOPED". Within the same update I must have touched him, generating a "COLLISION" message. Without pauseAI the interval between updates is 0.125 seconds, so all three messages bust have been generated within that period.

UPDATE happened than in the "COLLECT_STUFF" state. The 3 pending messages are now executed in a random order. When "HOLD_FULL" was the first, nothing happens as the current state has no reaction to it. Without the collision "CARGO_SCOOPED" will be the next and this again will generate the "HOLD_FULL" message. However when "COLLISION" is the second, it will switch to the "LOOK_FOR_SPLINTERS" state. That state than receives the third message: "CARGO_SCOOPED" but has no reaction to it programmed. And for some reason "scanForRandomLoot" generates no "HOLD_FULL" message while "scanForLoot" does.

Code: Select all

	"LOOK_FOR_SPLINTERS" =
	{
		ENTER = (performIdle);
		"TARGET_FOUND" = (setTargetToFoundTarget, "setStateTo: COLLECT_STUFF");
		"NOTHING_FOUND" = ("setStateTo: LOOK_FOR_ROCKS");
		"HOLD_FULL" = ("setStateTo: DOCK_WITH_STATION");
		ATTACKED = (setTargetToPrimaryAggressor, broadcastDistressMessage, "setStateTo: FLEE");
		"INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: FLEE");
		UPDATE = (scanForRandomLoot, "pauseAI: 10.0");
	};
	"COLLECT_STUFF" =
	{
		ENTER = (performCollect);
		FRUSTRATED = ("setStateTo: LOOK_FOR_SPLINTERS");
		"CARGO_SCOOPED" = (checkForFullHold, "setStateTo: LOOK_FOR_SPLINTERS");
		"TARGET_LOST" = ("setStateTo: LOOK_FOR_SPLINTERS");
		"COLLISION" = ("setStateTo: LOOK_FOR_SPLINTERS");
		ATTACKED = (setTargetToPrimaryAggressor, broadcastDistressMessage, "setStateTo: FLEE");
		"INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: FLEE");
	};

So far what think what happened. Now the result of the bug. The miner had scooped its last splinter and had a full hold. (I checked it with JS commands over the console). It now kept mining rocks and scooping splinters. But because of its full hold it only collided with the splinters and they disintegrated. He stayed in a loop of braking rocks and colliding with all splinters he could find.

Easy solvable by adding also a "HOLD_FULL" in the second state. To be foolproof I also added a checkForFullHold in the ENTER part of "LOOK_FOR_SPLINTERS". As said at the start, this must be a very rare event and I only can explain it by the two events almost happening simultaneously (within 0.125 seconds) And I can remember having collided with the miner while both of us were trying to scoop the same splinter.

I uploaded a new version 1.4 of the New 1.72 AI's. I think a lot of these changes should be put in 1.73. Can't do it myself.

NB Included a 1.73 version that is the same but uses a new 1.73 command that allows delayed reaction on incoming missiles. I think it should work but can't test as I have no 1.73 testversion.

[Eric Walch]

I just wanted to tell that I start putting my AI changes from the new1.72AI into 1.73 itself. I finally can build 1.73 myself, so I can test them. Specially those that make use of the new AI commands and messages added to 1.73

If I missed something, please let me know. The new1.72AI contains a readme with an extensive description why some changes had to me made. It is no new stuff but all very rare bugs that often are only visible when examining a ship with the target inspector.

I started yesterday by updating the trunk with the pirateAI and the thargoidAI. This last one was not yet in my newAI bundle but it fixes a behaviour bug in witchspace:

Thargoids fly towards the planet when they find no target. This also happened in witchspace, only there it just looked like the thargoids were fleeing the battle. After finishing a big witchspace battle there were always a large number thargoids in the system heading for a planet location that was not visible for the player.
I now added a witchspace test and when true, the thargoids head for the witchspace entry point were the battle takes place. It still contains a small bug as a small minority is still heading for the planet, but I leave it this way.