some buggy behaviours in 1.73

[Commander McLane]

It seems the interesting stuff like new releases always happens when I'm away (weekends).

Therefore the following observations I made during some playtesting come too late for 1.73.1 (and even for 1.73.2). However, I still want to report them:

1. AI-related: I met a sunskimming Boa with escorts and attacked it without any reaction from his side. The target inspector finally revealed that it was in enteringTraderAI, in state GO_TO_SKIM, which is strange, because this state doesn't exist in that AI. It seems it had only half switched to the correct route2sunskimAI, which does contain a state GO_TO_SKIM. Something strange must have been happening. Stack handling?
2. also AI-related: It seems that AI reaction to the player using his cloaking device somehow got buggy in 1.73. I usually cloak and uncloak if a non-standard missile is fired at me. In 1.73 this not only (correctly) causes the NPC to lose me as target, but if I continue with the attack, my opponent doesn't pick me up as his target again, his blip stays yellow. Doesn't happen consistently, but quite often.
3. in conjunction with that: it usually takes two or three cloak/uncloak attempts to disable a Nuclear Torpedo. Not sure why.
4. also AI-related: some traders with escorts don't react on attacks. Usually the target inspector shows them as being in traderInterceptAI, which doesn't exist. (seems solved in 1.73.2, according to the release notes)
5. something that I thought was squashed: when close to the sun, the space compass shows the station square (again)
6. likely OXP-related: I encountered two hostile cargo containers

[Eric Walch]

It seems the interesting stuff like new releases always happens when I'm away (weekends).

Therefore the following observations I made during some playtesting come too late for 1.73.1 (and even for 1.73.2). However, I still want to report them:

1. AI-related: I met a sunskimming Boa with escorts and attacked it without any reaction from his side. The target inspector finally revealed that it was in enteringTraderAI, in state GO_TO_SKIM, which is strange, because this state doesn't exist in that AI. It seems it had only half switched to the correct route2sunskimAI, which does contain a state GO_TO_SKIM. Something strange must have been happening. Stack handling?

I think this is in the js property is not being updated right. The target inspector just shows you an old AI. Same seams to happen when AI tracing after a setAI:. But the AI is flying the right one. The route2sunskimAI in your case. Not reaction on attack was a bug in the mac version 1.73.0 because of a missing file.

[*]also AI-related: some traders with escorts don't react on attacks. Usually the target inspector shows them as being in traderInterceptAI, which doesn't exist. (seems solved in 1.73.2, according to the release notes)

Same as above. I added a traderInterceptAI to Oolite. This for better handling attacks on traders (route 1 as well as route 2). But for some season this file was only added to the windows branch of the project. Corrected in the 1.73.1 release that was only up for a few hours.

[*]also AI-related: It seems that AI reaction to the player using his cloaking device somehow got buggy in 1.73. I usually cloak and uncloak if a non-standard missile is fired at me. In 1.73 this not only (correctly) causes the NPC to lose me as target, but if I continue with the attack, my opponent doesn't pick me up as his target again, his blip stays yellow. Doesn't happen consistently, but quite often.

I never noticed it yet but will keep an eye on it.

[*]in conjunction with that: it usually takes two or three cloak/uncloak attempts to disable a Nuclear Torpedo. Not sure why.

Sounds strange as the nuclear torpedo is identical to the plain missiles with only a few changed values in its AI.
However it sounds as if being cloaked is not checked as often as with 1.72[/quote] It is not the number of times you cloak that counts but only the duration.

[*]something that I thought was squashed: when close to the sun, the space compass shows the station square (again)

1.71 has an aegis message for the sun. This one was removed in 1.72. But to be able for a ship to recognise sun proximity I added back the aegis around the sun.

But looking into the code, it reads:

Code: Select all

- (void) setNextCompassMode
{
	switch (compassMode)
	{
		case COMPASS_MODE_BASIC:
		case COMPASS_MODE_PLANET:
			if ([self checkForAegis] == AEGIS_NONE)
				[self setCompassMode:COMPASS_MODE_SUN];
			else
				[self setCompassMode:COMPASS_MODE_STATION];
			break;

This means that in basic compass mode it switches from planet to station when not AEGIS_NONE. It means it handles sun now the same as planet. (Both not AEGIS_NONE) That also means it must have been wrong in 1.72 with any other planet than the main planet. Removing the aegis around he sun only fixed this bug for thesun, not for any non-main planet or moon.
Instead of checking AEGIS_NONE it should check (AEGIS_CLOSE_TO_MAIN_PLANET || AEGIS_IN_DOCKING_RANGE)
(I'll fix this)

[Eric Walch]

Instead of checking AEGIS_NONE it should check (AEGIS_CLOSE_TO_MAIN_PLANET || AEGIS_IN_DOCKING_RANGE)
(I'll fix this)

Fixed now for both basic compass mode as well as advanced compass mode. This must have been wrong since 1.71 were also other planets than the main planet became an aegis of their own.

[Eric Walch]

in conjunction with that: it usually takes two or three cloak/uncloak attempts to disable a Nuclear Torpedo. Not sure why.

I noticed something similar with the hardened missiles and just found the reason. The "CHECK_EXPLOSION" state needs a check for "TARGET_LOST":

Code: Select all

	"CHECK_EXPLOSION" =
	{
		ENTER = ("rollD: 20");
		"ROLL_1" = ("setStateTo: DETONATE");
		"ROLL_2" = ("setStateTo: EXPLODE");
		"TARGET_LOST" = ("setStateTo: EXPLODE");
		UPDATE = ("setStateTo: ATTACK_SHIP");
	};

When you fire ECM and notice the missile does not explode and than you cloak, the TARGET_LOST message is send to the CHECK_EXPLOSION state and is ignored there. It will stay in that state for 5 seconds and than return to a state that checks for the target_lost. When you stay cloaked, the performIntercept will eventually send a new target_lost that is noticed and the missile will still explode but now with a delay.

But this is an very old bug that was already present in 1.65. I don't know why it starts showing now? Or was it always there? I never did notice this delay until 1.73.
I'll correct this hardMissileAI.plist for 1.74 after some more testing.

[Kaks]

It could be that this bug was masked by other buggy stuff that we managed to fix in 1.73.3

Maybe if we don't touch the big bugs, everybody will be too busy to notice the smaller ones!

[Greyman]

It could be that this bug was masked by other buggy stuff that we managed to fix in 1.73.3

Maybe if we don't touch the big bugs, everybody will be too busy to notice the smaller ones!

I'll try my very best anyway!