Scripting requests

[Killer Wolf]

"this.guiScreenChanged = function(to, from)
{
// Your code here
}"

how do i stick this in a HUD switcher script to display a new HUD inflight if the F5 etc is pressed?
TIA....

[Eric Walch]

Hunters do have a state were they are looking for cargo,

...though they're extremely unlikely to be in such a state in Oolilte v1.74.2

A ship entering this state will be slightly more likely in 1.75. But this state was missing a "ACCEPT_DISTRESS_CALL" message, with the potency that it goes for the wrong target. In this case a found offender could be overwritten by the aggressor in distress call. A harmless bug though as both are potential targets in the first place.

When an AI scans in the UPDATE state, there is no problem as it will execute the FOUND_TARGET message during the same update. But when doing a search in any other state, including ENTER, the FOUND_TARGET message is generated and a found_target is transfered. However, execution of the message will only start on the next AI-update.
When Oolite itself now sets a new found_target before the AI-update and the AI has no corresponding message to react on, it will assume the found_target was a result of its previous search.

Until yesterday I never realised that even an ATTACKED has the same potential problem. When that message is generated, also a new found_target is set. So when doing a search in ENTER and there is no ATTACK message defined, (like the current INBOUND_CHECK of route1patrolAI.plist) there is a change it goes for the attacker, thinking it is the offender it was looking for. Not a serious mistake for a police though.

Doing the scan in UPDATE or making sure the state has an ATTACKED reaction defined, prevents these kind of rare conflicts.

JS has no such problems as the script has the logic for making decisions. Yesterday I wrote an eventhandler:

distressMessageReceived(agressor, sender) in analogy to the just added handler commsMessageReceived(message, sender). It will go to all 16 nearby ships having a crew on board. When there are no problems, it might be added to trunk.

[Kaks]

"this.guiScreenChanged = function(to, from)
{
// Your code here
}"

how do i stick this in a HUD switcher script to display a new HUD inflight if the F5 etc is pressed?
TIA....

Err, is this what you were after?

Code: Select all

this.guiScreenChanged = function (thisScreen, prevScreen)
{
    if (thisScreen == 'GUI_SCREEN_STATUS') player.ship.hud = 'statushud';
    else player.ship.hud = 'normalhud';
}

[Commander McLane]

If you want this to only happen in-flight, I think this small addition is better suited:

Code: Select all

this.guiScreenChanged = function (thisScreen, prevScreen)
{
    if (thisScreen == 'GUI_SCREEN_STATUS' && prevScreen == 'GUI_SCREEN_MAIN') player.ship.hud = 'statushud';
    if (thisScreen == 'GUI_SCREEN_MAIN') player.ship.hud = 'normalhud';
}

[Killer Wolf]

cheers guys, give that a whirl when i have a sec.
to cater for all screens can i put

Code: Select all

this.guiScreenChanged = function (thisScreen, prevScreen)
{
    if (thisScreen != 'GUI_SCREEN_MAIN' && prevScreen == 'GUI_SCREEN_MAIN') player.ship.hud = 'statushud';
    if (thisScreen == 'GUI_SCREEN_MAIN') player.ship.hud = 'normalhud';
}

or is it better to do separate ORs or IF statements?

[Thargoid]

The problem you'll hit is guiScreenChanged doesn't currently trigger when you leave the F5 screen and go back to the views (F1-4) whilst in-flight. So you need a little fancy script-footwork to overcome that.

I believe this is under discussion/repair at the moment for 1.75 (from what I saw overnight) and it's something I've raised before as a glitch (I fell over it when coding the Vortex).

So currently you can change the HUD when you go into F5 whilst in-flight, but when you come out again your HUD may well not change back unless you make other arrangements.

[Killer Wolf]

oh well, i'll leave it as-is at the mo, and we can revisit this topic when the next release sorts things (hopefully).

cheers anyways everyone.

[Switeck]

The problem is that calculating the odds is quite difficult. Oolite does try to calculate the odds under some circumstances using

Code: Select all

checkGroupOddsVersusTarget

but I dont know how good it is.

I had to redo my pirate AI script to send messages so I'd know what "mode" they were in.

Code: Select all

		"TARGET_FOUND" = (setTargetToFoundTarget, checkGroupOddsVersusTarget);
		"ODDS_GOOD" = ("commsMessage: You DIE!");
		"ODDS_LEVEL" = ("commsMessage: Equal Odds");
		"ODDS_LOW" = ("commsMessage: Fleeing!");

(There's more to it than that, but that's all I need to list for clarity.)

Turns out they never had ODDS_LOW against me, even 1-vs-1. Most of the time I saw "You DIE!" (ODDS_GOOD). At best I could force an even odds result. This was despite me being in either a Boa 2 with everything I could buy (5 Q-bombs in the missile slots) or a hacked Constrictor with 15 Q-bombs.

Earlier in my tests, I wasn't getting any messages at all because the pirates attack trigger never went through "TARGET_FOUND". My guess is me targeting qualifies as "ATTACKED"? Certainly me shooting them would.

[Commander McLane]

Earlier in my tests, I wasn't getting any messages at all because the pirates attack trigger never went through "TARGET_FOUND". My guess is me targeting qualifies as "ATTACKED"? Certainly me shooting them would.

I am not sure, but I would guess that only a hit triggers the "ATTACKED" message. Targeting shouldn't be enough.

The TARGET_FOUND message is sent as a result of the pirate ship actively scanning for targets, not if the ship is attacked by you.

[Switeck]

I was targeting the pirates but not shooting them at first till I saw their message or was attacked by them. I redesigned their script so they had to use the checkGroupOddsVersusTarget logic.
Turns out they conclude that a Cobra 1 pirate can beat my Boa 2 with "ODDS_GOOD" much of the time, even if I have full energy+shields.

[Commander McLane]

I have tested it now. Targeting a pirate ship (or any ship, for that matter) does not trigger the "ATTACKED" message. If you think about that for a moment it becomes clear that this is the only logical behaviour. For instance if you want to dock with a station, you will in most cases target it first. It would make no sense at all if the station would interpret this as an attack every time.

Oh, and by the way: A Gecko found its odds to be level against my Imperial Courier, after he scanned me. I was so amused that I refrained from blasting him to kingdom come.

[Switeck]

My other guess was other parts of their script was triggering their attack behavior, though I was at a loss as to what...
Anyway, the NPC ships certainly have a very optimistic view of the odds...

[Commander McLane]

The TARGET_FOUND message is sent as a result of the pirate ship actively scanning for targets, not if the ship is attacked by you.

Yes, they're pirates. The whole point of them is to attack you. That's why every five seconds they scan their vicinity for a possible victim through the scanForRandomMerchantman method. So you only need to spend more than five seconds less than 25600 meters away from a pirate ship and, tadah!, he will attack you receive a TARGET_FOUND message and calculate his odds, and then attack you.

[Eric Walch]

Turns out they never had ODDS_LOW against me, even 1-vs-1. Most of the time I saw "You DIE!" (ODDS_GOOD). At best I could force an even odds result. This was despite me being in either a Boa 2 with everything I could buy (5 Q-bombs in the missile slots) or a hacked Constrictor with 15 Q-bombs.

You think much to complex about what the command does. The whole code is:

Code: Select all

- (void) checkGroupOddsVersusTarget
{
	OOUInteger ownGroupCount = [[self group] count] + (ranrot_rand() & 3);			// add a random fudge factor
	OOUInteger targetGroupCount = [[[self primaryTarget] group] count] + (ranrot_rand() & 3);	// add a random fudge factor
	
	if (ownGroupCount == targetGroupCount)
	{
		[shipAI message:@"ODDS_LEVEL"];
	}
	else if (ownGroupCount > targetGroupCount)
	{
		[shipAI message:@"ODDS_GOOD"];
	}
	else
	{
		[shipAI message:@"ODDS_BAD"];
	}
}

That means it only compares group sizes, not strengths of individual ships. And because the player is always alone it will generate a size between 1 and 4. A single pirate will get the same random size. But the populator adds pirates in groups, so on average will pirates think their odds are good against a player.

When you would write realistic code, that would mean that pirates always would flee when seeing a player with a above average rating. Not much fun than in fighting.

[Switeck]

I had a typo in the AI script I was testing, so that contributed at least in part to me being confused about how checkGroupOddsVersusTarget worked.

I've tested enough to say I've NEVER seen *ANY* pirates flee from my arrival. That code suggests lone pirates using my modified script might do that maybe 5-25% of the time. (When I roll high and they roll low.)

...On another note, I'd really like it if there was a scanForEnemies AI function. This would differ from scanForHostiles by also including pirates in the vicinity (typically within 25 km) that were NOT attacking/targeting the NPC (trader?/bounty hunter?) ship that makes this call. Stands to reason someone besides the player has the means of telling if a nearby ship is Clean/Offender/Fugitive.