Probe 1.10 OXP

[Thargoid]

From the discussion in this thread, the suggestion for a scanning probe missile was introduced. So after a little work, the equipment is now completed and ready for use.

It flies 100km in the direction pointed, reporting back at half-way and on arrival on ships within its scanner range, before turning back and returning to the player for scooping and re-use.

Cost of 450 credits, available from tech level 3 planets.

--- Download Armoury OXP here - now including the probe missile ---

[Baza]

How long does it take to do the journey. launched disappeared waited 5 mins for something to happen..Then couldn't find it?

[Thargoid]

A few minutes overall. It reports back when it does the first and second scans, and after the latter it'll tell you it's coming back (it says to slow for rendezvous).

It's flying at speed 1000 over a distance of 100km (presuming you haven't moved in the meantime), so flight time is just under 2 minutes on the return. But as I said in the readme, the missile is not intelligent, so something may have attacked it or it may have collided with something?

You'll see it coming back as a missile, then when it gets close to you it will switch over to become cargo (the scanner blip goes from blue to white) and then you can scoop it again.

I just re-downloaded it and gave it a test run, seems to be working fine for me. Although with hindsight an improvement may be to add a maximum flight range back into the AI for the return flight. It used to have one, but it got removed during coding and somehow never got put back in again

Editted to add - just had a great suggestion for an improvement for the code from Eric, so an update will follow in the next day or two with this plus the above max-flight improvement and probably a notice if the thing does die in-flight.

[Thargoid]

As promised, new improved version v1.01 v1.02. The scanning is now optimised (thanks Eric!) and the missile now has a finite range. And the console will also tell you if it loses contact with the missile, normally due to its destruction.

--- Download Probe 1.02 OXP here ---

[Micha]

The probe mine/missile seems to always run into the back of my ship unless I fly at full speed and pull up immediately after firing it. This is in a regular Cobra Mk3.

Also, is it possible to use without the multi-targetting expansion?

[Thargoid]

The current version spawns 50m below the launcher, designed to get over that. Is that the version you're using? If so I can put a delay back in from the launcher being triggered by the player to it sending off the missile. All my tests (with a MkIII) never had it hit me though Try launching it when stationary.

My tests were under Windows, but I know Eric told me he'd had some collision problems in the first version. I wonder if we've got a difference in performance between the different OS versions here?

As for the multi-targetting system, it's sent off just like any other mine/missile, so yes, although you'll need to have your missile rack arranged in a suitable order...

[Eric Walch]

The probe mine/missile seems to always run into the back of my ship unless I fly at full speed and pull up immediately after firing it. This is in a regular Cobra Mk3.

Main reason for the problem is that the missile is launched as "mine". This has as great advantage that you don't have to aim it at anything to be able to initiate launch. Drawback is that mines launch backwards. After launch, the missile is ordered to fly in the direction of the players heading. This will always mean that it has to pass the player at close range.

In version 1.01 Thargoid changed the launch a little by letting it launch 50 lower than the predefined launch position. For my Boa MK2 this works well.

[Micha]

The current version spawns 50m below the launcher, designed to get over that. Is that the version you're using?Try launching it when stationary.

Yes I installed the latest version last night (and reloaded Oolite holding down Shift). And I tried launching while stationary, at half speed, and at full speed.

As for the multi-targetting system, it's sent off just like any other mine/missile, so yes, although you'll need to have your missile rack arranged in a suitable order...

Well, if I have the probe in the first missile slot then I can't fire regular missiles unless I fire the probe first - not really an option in a battle

Perhaps the multi-targetting system implementation needs a tweak - you can -always- change missile pylons with 'y' (whether or not you have the multi-targetting system installed), but all missiles stay locked on the same target unless you have the multi-targetting system. I haven't bought it but I assume it keeps track of a different target per missile?

[Thargoid]

Last point first, personally I would agree with that sentiment. At the moment the multi-target does allow different targets per missile (and you can cycle through a history of the last few ships you've targetted iirc, although I don't often use it), but your solution about selectable missile but single target would work. How much extra coding it would be is another question though...

With regard to the Probe, can you confirm which version (OS) of Oolite you're running? As I said I've tried it on Windows and it works for me fine with a MkIII, and Eric's experiences would tend to agree with that (on Mac iirc) as before I added the position shift he had similar problems of collision. Just so we can see if there's anything that's specific to one port.

In the meantime, if you look in the Script folder of the OXP at probeLauncher.js, on line 16 spawnOffset is set up. The "50" figure in there is the downward offset from the ship (or more specifically from the launcher mine) that the missile spawns at (there's a comment in the code so indicating). You could try adjusting that figure to a larger one, although I would expect 50m to be more than enough for a MkIII.

Alternatively you can add a "pauseAI: 2.0" entry to the ENTER state in probe_launcherDestructAI.plist in the AI folder, which will delay the spawning by 2s and give you more time to get out of the way.

As another quick test, could you try it using a different ship and see if you get the same result?

The implementation has to be via mine-launching, as of course missiles normally need targets before they'll fire, which would rather defeat the object of the probe

[Jason Whitelock]

well done once again - looking forward to testing this item once wife and child have went to bed.

I actually feel you have provided 'part' of the solution that I had listed on the board as part of another discussion with yourself from last week (part of welcome mat dialogue)

I asked was there any way to script a feature where you could 'auto scan' all ships within range that could then be toggled through / cycled through using the +/- keys as part of your multi target scanner.

Last night i popped out of jump to find 22 ships PLUS 8 galcop (yes i stopped and counted them) having a right good shootout.
Being able to launch the 'probe' to not only do whatever you have programmed it to do BUT ALSO carry out an immediate scan of what in the area and add to multi target scanner would be immense.
This in effect could be a local and long range probe.
Or simply split the 2 functions with 2 different options to choose from.

Well - once again - some great features .

Feedback on RepairBot - its way too pricey - 5k to fix a bust up fuel scoops which in dry dock only cost 300cr to fix.

cheers

[Micha]

Last point first, personally I would agree with that sentiment. At the moment the multi-target does allow different targets per missile (and you can cycle through a history of the last few ships you've targetted iirc, although I don't often use it), but your solution about selectable missile but single target would work. How much extra coding it would be is another question though...

Probably not much - unfortunately RL is preventing me from putting as much time as I'd like into Oolite. I'll have a quick poke around the multi-target code tomorrow night and see if I can adjust it. I've already looked at it briefly and it's just a case of always allowing the missile-change but only keeping a history of and adjusting the target-lock if you have the multi-target expansion.

With regard to the Probe, can you confirm which version (OS) of Oolite you're running? As I said I've tried it on Windows and it works for me fine with a MkIII, and Eric's experiences would tend to agree with that (on Mac iirc) as before I added the position shift he had similar problems of collision. Just so we can see if there's anything that's specific to one port.

I'm running my own compiled-from-svn version so it's 1.72, under Ubuntu Linux. I'll see what effects tweaking of the OXP variables have (again, tomorrow) and get back to you.

[Thargoid]

In that case you may be hitting the player vs player.ship separation "due" in 1.72? It may be that the new code to move the missile isn't working correctly under the new set-up, hence you're getting it spawning behind you and colliding. I've only got one installation of 1.72 at home, and given that's a timezone and a couple of thousand kilometers away from me at the moment it's not much help

I'd be interested on feedback as to whether it works on a 1.71.2 installation under Linux to eliminate an OS port issue, and then we can see if the code needs some work to be 1.72 compatible. As yet I've not gotten around to looking at 1.72 compatability for any of my OXPs, as time hasn't allowed...

[Thargoid]

well done once again - looking forward to testing this item once wife and child have went to bed.

I actually feel you have provided 'part' of the solution that I had listed on the board as part of another discussion with yourself from last week (part of welcome mat dialogue)

I asked was there any way to script a feature where you could 'auto scan' all ships within range that could then be toggled through / cycled through using the +/- keys as part of your multi target scanner.

Last night i popped out of jump to find 22 ships PLUS 8 galcop (yes i stopped and counted them) having a right good shootout.
Being able to launch the 'probe' to not only do whatever you have programmed it to do BUT ALSO carry out an immediate scan of what in the area and add to multi target scanner would be immense.
This in effect could be a local and long range probe.
Or simply split the 2 functions with 2 different options to choose from.

Well - once again - some great features .

Feedback on RepairBot - its way too pricey - 5k to fix a bust up fuel scoops which in dry dock only cost 300cr to fix.

cheers

The idea is lodged in the back of my mind. If no-one else runs with it (hint hint - it's open to anyone ) I'll have a look at it soon, but at the moment I've got 3 other OXPs running already and I need to get those to a suitable state first I'm not 100% sure if the multi target scanner selections are available to script, although I presume they should be. But it will be a separate OXP from Probe, that one is complete (give or take Micha's issue).

As to the 'Bots, they're designed to be expensive for two reasons. Firstly you get the convenience of repairs away from dock, and secondly they can fix (almost) anything. Yes if they fix fuel scoops you're spending 5000cr on a 300cr fix, but if they fix a broken cloaking device or bit of Military kit... The price may not stay at 5000cr, but it won't drop below 4 figures I think.

[Micha]

I'd be interested on feedback as to whether it works on a 1.71.2 installation under Linux to eliminate an OS port issue, and then we can see if the code needs some work to be 1.72 compatible. As yet I've not gotten around to looking at 1.72 compatability for any of my OXPs, as time hasn't allowed...

I'll try it out (tomorrow, *sigh*) against 1.71.2.

As for OXP compatibility, I've been patching all the OXPs I run - mostly a case of player.* becoming player.ship.* - but either will work with the former just spitting out debug messages (which annoy me).

Unsure if there's actual logic bugs in any of the OXPs due to 1.72 - so far most things seem to work.

[Thargoid]

Thanks. I was thinking specifically if the switch has changed anything in relation to the maths used to calculate the new spawning position of the missile. It should all be compatible, but the operative word there begins with "s"...

But if you can run it against a vanilla 1.71.2 installation that will be great, it should give us definitive answers.