Armoury OXP

[JazHaz]

No it should fly off in the direction you're pointing.

What version of Oolite are you running, 1.74 or 1.75?

Also is it repeatable?

1.74 test. Repeatable, sure, every time I've fired one of these off, it goes in a random direction.

[Thargoid]

OK - I confirm it's got a glitch, and I also confirm I haven't a clue why. It's spawned and oriented correctly, but when it starts to fly the orientation seems to wander all over the place?

performFlyToRangeFromDestination seems to be re-orienting the missile for some reason? Question to the devs - has this command functionality changed (or broken) in 1.74?

[Thargoid]

OK I have a working version on my HD after using something else in the scripting rather than performFlyToRangeFromDestination.

I've had another idea for something to add to Armoury which I'll do tonight and will then issue 1.03 with both in.

[Commander McLane]

performFlyToRangeFromDestination seems to be re-orienting the missile for some reason? Question to the devs - has this command functionality changed (or broken) in 1.74?

It probably depends on the defined range. What performFlyToRangeFromDestination actually does (as far as I understand it) is to project a sphere with radius "range" around the point "destination", and then fly the entity to a randomly chosen point on that sphere. In other words: if your destination is 10 km away and the defined range is 10 km, the ship might as well not fly at all, or overshoot the destination by 10 km, or go 10 km sideways of your destination point, or anything in-between.

[Thargoid]

The target point is 50,000km (2x scanner radii) away. It worked perfectly under 1.73.4, but as reported goes off at random in 1.74 and also seems to continually change its orientation now as well, when there's nothing in the AI to make it do that (it's just set to do pFTRFD and left to get on with it until it achieves the range).

Anyway with the JS access to saved co-ordinates in 1.74 I can use that now instead which works fine. I'm just a little confused as to why the older method is now acting differently, when reports tell me nothing in that was changed. I just mention it in case other OXPs are relying on it.

[Thargoid]

OK version 1.02 uploaded, with the following changes:

• Probe missile fixed - it now flies straight rather than it's previous impression of a drunken trumble.
• Missile loading sound added to the missile machine (by request).
• New weapon added - the displacer missile.

Download from here, same URL as first post, or else from the links below.[/color]

[Eric Walch]

It probably depends on the defined range. What performFlyToRangeFromDestination actually does (as far as I understand it) is to project a sphere with radius "range" around the point "destination", and then fly the entity to a randomly chosen point on that sphere. In other words: if your destination is 10 km away and the defined range is 10 km, the ship might as well not fly at all, or overshoot the destination by 10 km, or go 10 km sideways of your destination point, or anything in-between

That is largely correct. But it is not actually aiming for a random location on that sphere, but gradually turning towards the centre of that sphere until its course starts to intersect with that sphere. Than it stops turning. Effectively that is about the same in result.

But the probe missile used to start within the desired-range circle and there the above is not valid.

The target point is 50,000km (2x scanner radii) away. It worked perfectly under 1.73.4, but as reported goes off at random in 1.74 and also seems to continually change its orientation now as well, when there's nothing in the AI to make it do that (it's just set to do pFTRFD and left to get on with it until it achieves the range).

I found why your probe was not working as before. It was because of a change I made already in 1.73 (The probe didn't work correctly in 1.73 either). But actually was it a bug that it worked before.

Before 1.73 the navigation code tried to take the square root from a negative number when starting inside the desired range. Result was a NaN value as reference to see how far it was allowed to be off course before starting to correct. This resulted in doing no course corrections at all as long as a ship was inside the desired range. Since 1.73 this square calculation from a negative number is skipped and it uses a default value in such occasions. This results that it always tries to turn away from the startingpoint.

However, the command "setDestinationToCurrentLocation" that you used to set the start, it not using your exact location but is randomising it within a meter. So your probe now was immediately starting with a turn, away from the randomised starting location. That is actually correct behaviour but not what you wanted.

I changed your code a bit to:

Code: Select all

	GLOBAL = { 
	ENTER = (setDestinationToCurrentLocation, performIdle, "setSpeedFactorTo: 1.0", "pauseAI: 10.00"); 
	UPDATE = ("setStateTo: GO_TO_FIRST"); 
	}; 

	"GO_TO_FIRST" = { 
	ENTER = ("setDesiredRangeTo: 50000.0", performFlyToRangeFromDestination); 
	"DESIRED_RANGE_ACHIEVED" = ("sendScriptMessage: doScan", "setStateTo: GO_TO_SECOND"); 
	UPDATE = ("pauseAI: 5.0"); 
	}; 

NB performIdle only sets roll and pitch to zero, not speed, so this results in flying straight ahead for ten seconds. When using performFlyToRangeFromDestination when already far away from the somewhat randomised start location, it will continue the straight line.

But this is academic as you now use an even better way to go to your destination.

[tonyhippy]

I was thinking of something that might be usefull, especially for Anacondas and other lumbering ships, using the same idea as Passenger Berths:
Small Craft Bays
Rather than Reprogrammed Thargoids and/or Combat Drones etc taking up precious missile pylons you could allocate a chunk of cargo space to house them.
Smaller ships would still obviously have to carry them the old way, but your Freight-Pig Anaconda could be better protected and still carry a few fuel tanks and missiles too. And it makes sense as the larger the ship the more could be carried, and it's never really been explained how a rescooped drone gets back on its pylon anyhow.

[Thargoid]

The question there is how to trigger them (that being the main reason for pylon use). If you want them auto-triggered in hostile situations, then they become the Guardian system you can find in one of my other OXPs (if you don't know which one, then I shan't spoil it).

[Poro]

Thargoid, how about an adapted version of the displacer missile. It would be a 'neutral' device (in that it could be helpful or damaging to you) and it's use would be heavily dependent on the context it is used in.

The device would shift the player's ship randomly, within a certain distance in order to help escape powerful ships whose lasers may be hard to avoid. It wouldn't need quirium (since the player would just use that to boost away, if they have injectors) and so would cost a bit more. But then, it might be a 3-in-1 pack, like many other weapons you have developed.

As I say, the neutrality of the device would limit it's over-use... maybe you will escape an enemy before your aft shield collapses: or maybe you will appear inside your enemy, or an asteroid, or a station.

[Thargoid]

I did ponder that idea as a seperate OXP (that shifts the player ship randomly when energy levels are getting critical). But as we now have auto-escape pod launch capability etc that would also trigger around the same point it seemed a bit redundant so I didn't bother.

[Poro]

I wasn't so much thinking as an escape device - more like a desperate way to get away from an enemy's lasers, so you can try and gain an aft position on them.

[Commander McLane]

We could make the Amiga and Atari version Retro Rockets into an OXP. What they did was basically shifting the player to another position (one or two scanner ranges backwards).

[Thargoid]

And up to v1.03:

• Fixed the bug with the unibomb that killed the player when it was dropped.
• Added script fixes to ensure that the drones and the captured thargons do not break the Constrictor mission (if they kill it, then it counts as a player kill for mission purposes).
• Added a couple of new weapons into the thing, just for fun.

[/color]

[Thargoid]

OXP now updated to v1.08, adding some new weaponry (some suggested by people on this very board!).

In addition to the already existing goodies (and baddies), these include:

• Void bomb - mini black hole bomb.
• Kicker missile - non-lethal missile which gives the target a shove away.
• Cutpurse missile - non-lethal missile which causes cargo dumping.
• Decoy mine - Ganelon's famous WTF balloons!
• Stun missile rack - a triplet of mini stun missiles.

Download from the links below, or via the wiki.[/color]