Progress

[Wildeblood]

New event
A new AI event "ATTACKER_MISSED". This fires whenever a ship fires at another ship and misses. What I often saw on the spacelanes was a trader wandering along with a couple of escorts, and a lone pirate coming in towards it firing wildly and missing every shot. The trader would then completely ignore it until a stray shot finally hit it.

This event has been added to a lot of the core AIs so that in that situation, the trader will start returning fire after the first missed shot. It works for the player too, so the text in [wiki]Laser tactics[/wiki]

If you are making a pre-emptive strike on another ship, make absolutely sure the ship is properly in the target reticule before firing. Nothing gives away the element of surprise like a shot across the bows when you really meant to hit.

is now accurate for at least some ships.

It's only been added to "non-fighting" AI states (and not all of those, either), so a ship already in combat isn't going to be distracted by some near misses.

That sounds right at first, BUT if someone is attacking you with a laser, and missing, how would you know? That could be happening to you right now IRL. Until you get hit, how do you know? In Oolite coloured lines appear on screen when lasers are fired, but that is purely for game-play aesthetics. In space there is no atmospheric scattering, so a laser beam - no matter how powerful - is completely invisible unless you are directly in the beam.

[Star Gazer]

Since deep space is not a perfect vacuum, there is a finite possibility of the laser causing scintillation of the particles in its path, and this would be possible to detect, so a warning could be triggered by the nearby presence of laser scintillation? (is this what we 'see' on our screens?)
Laser Beam Scintillation

[Disembodied]

That sounds right at first, BUT if someone is attacking you with a laser, and missing, how would you know? That could be happening to you right now IRL. Until you get hit, how do you know? In Oolite coloured lines appear on screen when lasers are fired, but that is purely for game-play aesthetics. In space there is no atmospheric scattering, so a laser beam - no matter how powerful - is completely invisible unless you are directly in the beam.

Obviously, the cockpit HUD of any Oolite starship can detect and display beams of coherent light - hence the appearance of the beams on screen. This is because the viewscreens use the output of a witchdrive engine to detect frame-dragging variations in the local space-time flux. Any light-speed discharge will, of course, provoke quantum-level frame-tearing: when such discharges are coming from very high-energy lasers, these infinitesimal effects are large enough to be sensed and rendered on-screen as stuttered lines of light. You can't see lasers, but - with the right technology - you can detect them.

[cim]

That sounds right at first, BUT if someone is attacking you with a laser, and missing, how would you know? That could be happening to you right now IRL. Until you get hit, how do you know? In Oolite coloured lines appear on screen when lasers are fired, but that is purely for game-play aesthetics. In space there is no atmospheric scattering, so a laser beam - no matter how powerful - is completely invisible unless you are directly in the beam.

Well, when an NPC attacks the player - quite apart from being able to see the laser beam missing, and potentially a few seconds before they actually fire - their scanner blip goes red, and so does the alert status. I assume the NPCs have something similar on their own scanners.

There are considerably easier methods than Disembodied's, well within the reach of even 21st century technology, to detect that a laser has been fired and extrapolate the beam path, too. Watch the laser mount for an increase in emitted infra-red radiation, and plot a straight line forward from it, for instance.
(If you turn TAF down to 1/16, and use Griff's models, it's almost possible to do this by eye)

[Commander McLane]

That sounds right at first, BUT if someone is attacking you with a laser, and missing, how would you know? That could be happening to you right now IRL. Until you get hit, how do you know? In Oolite coloured lines appear on screen when lasers are fired, but that is purely for game-play aesthetics.

You've got your answer right there. The player can see laser beams fired at them even when they miss. This must mean that NPCs can see laser beams likewise.

The visibility or non-visibility of laser beams in a vacuum in RealLife™ is (like anything else from RealLife™) completely irrelevant to the point.

So I'm all for it!

(And actually, even reacting on missing laser fire still gives NPCs a disadvantage. The player can already react as soon as a blip on the scanner turns red. There isn't even a need to wait until the first shot is fired.)

@ cim: What I am wondering about is the legal repercussions in an encounter between NPC and pirating clean player within range of the police. With 1.76 the NPC will only defend itself when hit for the first time. At that point the hit will also have given a bounty to the player. But what about the new system? After a miss the player is still clean. If the NPC starts defending itself and happens to land the first hit, the police would see that as an attack, and put a bounty on the defending NPC's head, not on the attacking player's head.

(This may be a rare exploit, and you may decide that it stays that way, because sometimes life's a bitch. Actually, an analogous situation has already existed forever, and I have exploited it sometimes, albeit unplanned. The situation is that I attack a trader whilst not knowing that there is some police just outside scanner range. Thus my attack isn't registered by the police. But by the time the trader begins to strike back the police have arrived inside scanner range. At that point everything depends on who lands the first hit after the police are in scanner range. If it's me, I get marked as an offender. If my victim is the first to hit me, he gets marked. This can be exploited by briefly holding your fire as soon as you see police on your scanner. The NPC doesn't hold its fire and therefore is likely to score the first hit in front of the police. It's a small exploit, because in most cases you're already marked as the offender before you notice the police presence. But it nevertheless exists, and has existed forever.)

[Disembodied]

One small thing worth considering: how will the NPCs tell the difference between a shot fired across their bows at them, and a shot fired across their bows at the pirate who's attacking them, by a player who's coming to their rescue? Between (Player; NPC trader; NPC pirate)

>-------------

• • • ^ —He's shooting at me!

and

• • • • v

>-------------

• • • ^ —He's shooting at me!

[cim]

@ cim: What I am wondering about is the legal repercussions in an encounter between NPC and pirating clean player within range of the police.

I did consider skipping the event if both target and attacker were clean, but it turns out not to be necessary. What actually happens in that scenario is this:

• Player attacks NPC trader, misses.
• Trader detects attempt, enters traderInterceptAI
• Trader prepares for combat and sends a distress message saying the player is attacking them
• Nearby police note that the distress message is accurate, stick a bounty on the player, and move to assist.

If the police show up later then the usual "who shot first" confusion still happens.

One small thing worth considering: how will the NPCs tell the difference between a shot fired across their bows at them, and a shot fired across their bows at the pirate who's attacking them, by a player who's coming to their rescue?

Depends who the player is targeting at the time. (Same as how they tell with NPCs, in other words)

In that precise scenario, both the trader and pirate would already be in combat and not checking for the ATTACKER_MISSED message anyway, of course.

[Switeck]

A small adjustment to witchspace exit: the radius of the witch buoy is now taken into account when determining minimum safe distance. YAH buoys should now be safe to use.

In the past (circa v1.76), I was sometimes unable to hyperspace jump due to appearing too close to the YAH Billboard (masslocked) after a previous jump...is that fixed also?

[cim]

A small adjustment to witchspace exit: the radius of the witch buoy is now taken into account when determining minimum safe distance. YAH buoys should now be safe to use.

In the past (circa v1.76), I was sometimes unable to hyperspace jump due to appearing too close to the YAH Billboard (masslocked) after a previous jump...is that fixed also?

It probably won't happen any more, because the minimum arrival distance for a YAH board will be around 1.3km, and I don't think they're heavy enough to lock at that range, but there are no specific measures in place to stop that happening.

Since having a special ultra-heavy nav buoy precisely to block immediately jumping out has some potential for OXP writing, I'm not sure it's actually a bug though.

[Switeck]

In the past, my ship appeared much closer than 1 km of the buoy. So if the new spacing places ships 1.3 km or further from the buoy, that's plenty far enough away to prevent accidental mass-locking yet close enough to probably allow for a special massive buoy to cause mass-locking.

[Tricky]

In the past, my ship appeared much closer than 1 km of the buoy.

I've been made fugitive in the past simply because I've destroyed a buoy on witchspace exit, had the misfortune of a couple of police hanging about who saw it. I think it ended up of going from clean to about 120₢ worth of bounty on my head. Took quite a bit of jumping around to clean myself up.

[Switeck]

A few modifications to the AI:
Full pirates
Eric had already made some changes way back in r4770 to make offenders and fugitives less likely to dock at the main station compared with 1.76. I've slightly tweaked this to make the chance of going for the main station depend on how big the price on their head is.

To make this work properly, there needs to be a non-main station for pirates without a witchspace engine to go to. The pirates without witchspace engines tend also to be the ones with small holds, so they fill up most often and then look for a station. Experimentally, I've changed the system populator so that all systems have at least one rock hermit. If there wasn't one generated on the normal spacelanes, there will be one added to a semi-random point in space quite some distance from the spacelanes.

It almost seems like "Full Pirates" is incorporating ideas from various OXPs (Deep Space Pirates, Pirate Coves, and even Switeck's Shipping) directly into Oolite itself.

While this is a sign of progress, some of these changes aren't exposed to OXPs as .js script or AI.plist files that can be changed...so overriding their behavior may be more difficult.

Please change the method used to add the extra Rock Hermit to a .js script file.

[cim]

Please change the method used to add the extra Rock Hermit to a .js script file.

Well, you can always remove it or move it elsewhere from shipWillExitWitchspace.

Moving just one tiny part of the system populator to JS doesn't seem to gain a lot. Making the entire system populator manageable by JS does seem worth doing, and is already on my list of things to look at, but probably won't be done for a while.

[Switeck]

I would just remove unwanted ships (in this case a Rock Hermit and associated nearby asteroids) myself...but I get occasional crashes-to-desktop when .js scripts move (or remove) ships while my ship is cloaked.

There are also graphical glitches associated with moving and/or removing "unwanted" ships on arriving at a new system. Normally, this is unseen...but it can be particularly jarring in the case of Thargoids in interstellar space, as these are both semi-large and often immediately in front of the player's ship when this happens.

The problem with making OXPs to change initial settings for a system is the OXP first has to determine what the system populator has done and then work around that. This can also incur a delay if the OXP also has to adapt to what other OXPs do on exiting hyperspace. The delay also makes graphical glitches more likely to be seen.

[cim]

I would just remove unwanted ships (in this case a Rock Hermit and associated nearby asteroids) myself...but I get occasional crashes-to-desktop when .js scripts move (or remove) ships while my ship is cloaked.

But only while cloaked, and not when ships are (re)moved by non-JS means?

There are also graphical glitches associated with moving and/or removing "unwanted" ships on arriving at a new system. Normally, this is unseen...but it can be particularly jarring in the case of Thargoids in interstellar space, as these are both semi-large and often immediately in front of the player's ship when this happens

shipWillExitWitchspace occurs before anything is actually drawn for the new system, though, so any changes made there shouldn't be visible to the player. And then the next several frames are the break pattern.