Switeck's Shipping v0.5 OXP - Ai, Economy, and Ship changes

[Eric Walch]

Hm. I've tried to follow pirateAI (which has become rather complex), and it seems my initial assumption was wrong. There is a checkForFullHold performed before actually scooping, at least in some cases, and there is a HOLD_FULL-message in the COLLECT_LOOT state, however it seems the check must have been performed in the previous state.

The AI really is rather complex.

For correcting that AI I really had to use the AI logging feature. Giles already coded that pirates with a full hold should jump out of the system. But that just never happened. It is not that the "HOLD_FULL-message" appears in a following state, but in the state that follows the following state. Yes, you read it well, there are two state switches executed before some of the messages are evaluated. And because there is also some randomness in which message is handled first, this AI needs an AI logging for proper testing.

[Switeck]

"If a tree falls in the forest and nobody is around to hear it, does it make a noise?"

The NPC traders often send out a distress call if attacked by pirates. But do they do this if you're not within ~25 km? (Hoping of course that bounty hunters and police ships are there to save them I guess...)

[Commander McLane]

"If a tree falls in the forest and nobody is around to hear it, does it make a noise?"

The NPC traders often send out a distress call if attacked by pirates. But do they do this if you're not within ~25 km? (Hoping of course that bounty hunters and police ships are there to save them I guess...)

I guess that depends on what you mean by "distress call".

First of all consult the Wiki.

If you are referring to the commsMessage (e.g. "I am attacked by pirates, help!"), this is sent to the first 16 entities within scanner range. Due to Oolite's non-player-centredness the player doesn't need to be within range for this to happen, and he isn't necessarily among the 16 entities chosen, if there are more entities in the vicinity. (This is the reason why you never heard most of the chatter in the Tionisla Orbital Graveyard, as Eric recently found out and posted in the respective thread.) By the way, this commsMessage cannot be understood by anybody but the player. It's completely wasted on NPCs, because Oolite's AI code doesn't have a method to receive it and deal with it.

You could also be referring to the AI method broadcastDistressMessage, which is an AI-internal (NPC to NPC only) way of communication. What it does is to trigger the ACCEPT_DISTRESS_CALL message in the AIs of all ships with role "station", "police", or "hunter" within scanner range, thereby triggering whatever instructions they have if receiving this message. It is completely independent of the verbal message visible to the player. It is sent and received regardless of the player's location at the time. If that weren't so, you would never come across debris in Oolite. However, non-player-centredness means that NPCs do interact with each other even if the player doesn't look or isn't present. The player also won't be able to detect this AI-message, except in watching the response of the receiving entities.

So, there are basically two completely independent "distress calls" in Oolite. One is only visible to the player and purely cosmetic to the game. The other one is completely invisible to the player and an important part of NPC-to-NPC-interaction in the game.

[Switeck]

I shall find out if traders can respond to ACCEPT_DISTRESS_CALL message in their AIs...that way traders might defend each other if near each other.

[Commander McLane]

I shall find out if traders can respond to ACCEPT_DISTRESS_CALL message in their AIs...that way traders might defend each other if near each other.

No, they can't. It's explicitly limited to the above mentioned roles.

[Kaks]

By the way, this commsMessage cannot be understood by anybody but the player. It's completely wasted on NPCs, because Oolite's AI code doesn't have a method to receive it and deal with it.

True! However, in 1.75 we will have a new javascript event that will react to any comms messages received. You can then program the js side to try and figure out what kind of (non-distress) message it's received, and set the AI state accordingly!

For example, you could then get an NPCs to broadcast 'I need fuel!' and another NPC could come to give them 1 or 2 ly's worth, depending on how much fuel they had...

And about traders and ACCEPT_DISTRESS_CALL, as McLane said, no standard trader AI is actually listening for that AI message. However, there's nothing to stop you from creating a special vigilanteTraderAI with the extra ACCEPT_DISTRESS_CALL stuff added to it: you could then add it to a few selected iron assed traders...

There's also nothing to stop you modifying the shuttles AI to go on suicide missions whenever they hear a DISTRESS_CALL...

[Eric Walch]

If you are referring to the commsMessage (e.g. "I am attacked by pirates, help!"), this is sent to the first 16 entities within scanner range. Due to Oolite's non-player-centredness the player doesn't need to be within range for this to happen, and he isn't necessarily among the 16 entities chosen, if there are more entities in the vicinity. (This is the reason why you never heard most of the chatter in the Tionisla Orbital Graveyard, as Eric recently found out and posted in the respective thread.)

Yep. Although non-player-centric it felt bad that the player misses such messages. So starting with 1.75, the player will always be included in the commsMessage when in range. In 1.74 and earlier, you had to use the "sendTargetCommsMessage" to the player, when you wanted to be sure that the message arrived at the player.

[Switeck]

I shall find out if traders can respond to ACCEPT_DISTRESS_CALL message in their AIs...that way traders might defend each other if near each other.

No, they can't. It's explicitly limited to the above mentioned roles.

I've already added ACCEPT_DISTRESS_CALL to an AI.plist other than route1patrolAI.plist (which police and bounty hunters all seem to use).

So you're saying just because a NPC ship has a primary role of trader...it won't actually DO anything even with ACCEPT_DISTRESS_CALL ?

[Eric Walch]

So you're saying just because a NPC ship has a primary role of trader...it won't actually DO anything even with ACCEPT_DISTRESS_CALL ?

Yes, it is hardcoded that only the main-station and ships with role "police" and "hunter" accept distress messages. That are the roles that are supposed to watch the system for criminals. Even escorts that turn into a hunting role will not react to this. All other ships using the route1patrolAI.plist, can only react on the scanning for offenders.

This info is in the wiki, but only since a few weeks.

[Switeck]

Yes, it is hardcoded that only the main-station and ships with role "police" and "hunter" accept distress messages.

Your link implies it works for all stations...so you're saying it's even more limited than that?

[EDIT!]
In an attempt to have more trader NPC ships to work with, I hacked up Deep Space Pirates OXP to spit out a new arriving trader around the witchpoint beacon at whatever its timer intervals are. (I think around 15 seconds.) This was the code I added to DSP:

Code: Select all

	if (!system.isInterstellarSpace && !player.ship.docked && System.countShipsWithPrimaryRole("pirate")<99 && System.countShipsWithPrimaryRole("trader")<999)
		System.legacy_addShipsAt("trader", 1, "wpu", [Math.random()*0.05-0.025, Math.random()*0.05-0.025, Math.random()*0.05-0.025]);

Much to my surprise, my modified route1traderAI.plist didn't work as expected. The new arrivals seemed to keep using route1traderAI.plist and never switched to the other possible ais, such as scavengerAI.plist. EXTREMELY rarely, I'd get one of the other AI types...especially route2sunskimAI.plist even though it was the least likely possibility in my list.

Best I can tell, this method of adding ships doesn't trigger this code:
"EXITED_WITCHSPACE" = ("setStateTo: CHOOSE_NEW_CAREER");
...Which is making testing of my AI mod rather hard. I managed to further hack up route1traderAI.plist to ALWAYS do "CHOOSE_NEW_CAREER" without the "EXITED_WITCHSPACE" check.
After that, these script-added traders started acting as expected. I discovered that at 16x gamespeed I got plenty of new traders to see how they reacted...but the game was lagging pretty badly because many were Anacondas and Boas which added lots of escort ships. I "fixed" that for testing purposes...by editing my escortAI.plist to blow themselves up on arrival.

Now I can try to work out some reasonable ratios so the old behavior is still the most common...with a couple of rare alternatives for variety. I would've added more AI types, but as this thread as proven...I've been stymied by unexpected behavior and game limitations.

And I'm still learning, stumbling, and blindly trying stuff...so hopefully things can only get better.

[Commander McLane]

I think you're doing something wrong.

If your modified route1traderAI is called "route1traderAI.plist", there doesn't exist another route1traderAI.plist next to it, so every ship with route1traderAI.plist must have your modified one.

[Switeck]

I retested my modified "route1traderAI.plist" and got the same result...the overwhelming majority of the newly added traders were "stuck" using "route1traderAI.plist" with maybe 10-15% using "route2sunskimAI.plist". Yet I could tell my modified "route1traderAI.plist" *WAS* being used because eventually I'd see 1 or 2 traders using the other AI's that I had them change to...out of 100 total traders.

Eric would probably know why...

[Eric Walch]

The

Code: Select all

"EXITED_WITCHSPACE" = ("setStateTo: CHOOSE_NEW_CAREER");

will only work for traders that are added at the witchpoint as result of traders entering wormholes elsewhere. That are the traders a player normally sees at the entry point. That is also why I advised to launch traders from the station to do your testing, and not to spawn them near the witchspace entrypoint directly.

When a script explicit adds additional traders at the entry point, the message "EXITED_WITCHSPACE" is never generated. Having a way to distinguish between direct and indirect generated ships is useful for the AI with its limited amount of tools to check stuff.

Now we have a return value for script added ships, the script can set it to any AI it likes on addition of a trader.

[Switeck]

I think you're doing something wrong.

The difficulty here is not that I am doing something wrong so much as a big misunderstanding by everyone of what will happen.

Why that only "barely" worked was I was seeing the replacement ships (after some docked) use
"EXITED_WITCHSPACE" = ("setStateTo: CHOOSE_NEW_CAREER");
...the way I expected. Which at first were very few, but as time went on...more and more docked with stations so their replacements did end up using a different AI than "route1traderAI.plist". Confusing, isn't it?

My later tests did not coincide with what Eric said. There is a way to add new ships that DO trigger:
"EXITED_WITCHSPACE" = ("setStateTo: CHOOSE_NEW_CAREER");
...And I found it on accident, like I find many things.

system.legacy_addShips("trader", 1);
triggers "EXITED_WITCHSPACE" AI behavior...possibly because it has no location value, so it MUST default to spawning at/around the witchpoint buoy.

I rather like it that way. Otherwise, it would be very hard to test 100's of traders going from witchpoint to station/s in semi-normal circumstances. Without the extras, it'd take DAYS to see that many! They may be more numerous, but they still follow the same paths. This lets me check probibility with a reasonable number set so something weighted at <10% still can happen more than once. They do cause the mother-of-all-space-traffic-jams at the main station, but I found a q-bomb cleans them all out nicely so I don't have to wait in line.

[Eric Walch]

...And I found it on accident, like I find many things.

system.legacy_addShips("trader", 1);
triggers "EXITED_WITCHSPACE" AI behavior...possibly because it has no location value, so it MUST default to spawning at/around the witchpoint buoy.

You are right, I just went through the code again. That message is part of the "witchspaceLeavingEffects". It is in the same routine that generates the rings. That means that also the new addShips() commands generate this message when adding ships close to the witchpoint.