[SCRIPT] Auto explore v1.2 + Deploy Satellite Network replacement v1.1 [2009-07-19]

[ThisIsHarsh]

Explorer Command Extension

This plugin is split into two parts:

[Auto explore] command automatically maps unexplored sectors, optionally scanning asteroids as it goes (requires Mineral Scanner).

Sectors who's owner is marked as enemy in this ship's friend-foe settings will be entered, but not mapped. The explorer will automatically retreat upon entering such a sector.



[Deploy Satellite Network] replacement command for the stock version.

This uses somewhat more intelligence in deploying Advanced Satellites around the galaxy than the stock version. Crucially, the jumpdrive will be used, and refueled as necessary, using the ship's autojump and refuel settings.

Sectors will not be visited if the ship's friend-foe settings indicate it is an enemy. You can also blacklist sectors in the preload menu, as shown in the screenshot below.






Changelog (Auto explore)
v1.2.2:
- Removed: [Scan asteroids] command - there is now a stock command that is more advanced.
v1.2.1:
- Modified: changed command slots to avoid conflict
v1.2:
- Fixed: multiple explorers will now work together better
- Modified: performance enhancement when searching sectors
v1.1:
- Fixed: ships trying to get too close to asteroids before scanning.
v1.0:
- Initial release.

Changelog (Deploy Satellite Network replacement)
v1.2.2:
- Fixed: forgot the language file .
v1.1.1:
- Fixed: text file not loading on startup
v1.1:
- Added: preload menu to allow blacklisting of sectors.
v1.0:
- Initial release.

[Litcube]

I haven't looked too far into it, but if TC's Explore Sector command is anything like the old Reunion Xai corp release (and glances preliminarily indicate this is so), then the reason some objects aren't being scanned is due to the following implementation:

The main task is run on the ship, which is esentially just flying the ship around in circles. That's all it's doing.

While this is going on, a second script has been launched on *another* task on the same ship, so we have two scripts running now. The second script's function is to check if any objects are within the scanner range and if so marking them as "known", while, of course, the ship is flying around in circles with the first script.

Herein lies the problem: the *waits* of the second script within the WHILE loop. The wait is around 9 seconds. If you're using a fast ship, especially in OOS flight, an object can easily be missed and never happend on again, thus never being marked as "known".

I would assume this implementation was issued to keep the script from cheating.

[ThisIsHarsh]

@Litcube: Yeah, you described the implementation pretty much exactly. Problem is that the OOS timestep is, I think, 10 000 ms, so a wait of any shorter than that has no effect. Correct me if I'm wrong there.

The additional task script is to supplement the normal scanner operation, since this seems to get updated even less often than the normal galaxy timestep.

The main problem however, which I hastily decided points to a bug somewhere, is that stations and asteroids are detected much more often than jumpgates, even though they all suffer the same galaxy timestep issue.

All I did in my 'fix' was modify the jumpgate portion of the script, so that instead of only finding gates within range, it would find all gates in the system *then* check if they are in scanner range, before marking as known.

As I mention in the OP, I'm not certain this makes a difference. I didn't use the default implementation many times (maybe 3 or 4), so don't have a decent set of results to compare. But it *seems* to work better...


I would welcome reports one way or the other - at least until an official fix is posted as part of a patch

[Litcube]

It'd be any wait *longer* than that. Xai corp had it right the first time. Still, though:

In my own implementation, I completely ditched the second script. It's sloppy and inaccurate. There are many instances where a brush of an object at the edge of a spherical scanner radius can be undetected within *fractions* of a second, nevermind 9 seconds.

The solution, of course, is to ditch the "search" radius function completely. It's not practical.

As a ship in a sector can detect a visual of an object vast distances away, I justified the implementation as follows:

Get Array of all sector objects

First object.

Ship flies toward seen object at a distance of SCANNER RANGE from the object.

Object marked as Known now.

Second object.

Ship flies toward seen object at a distance of SCANNER RANGE from the object. [chances are good that it's already within range, thus encouraging the illusion that it's not cheating].

And so on.

[ThisIsHarsh]

Ahh, I think I see what you mean. But doesn't that mean that in all but the most dense sectors there will likely be several objects 'cheated' into being known? What about pandora crates and hidden ships/stations waaay off the normal sector radius?

In any case, I really want to avoid having to hack a script so it cheats in order to get proper operation. Saying that, a couple of aspects of my 'Auto explore' script are borderline...

I.e. I use the sector size to judge max Map Sector radius, and choose Map Sector centroid locations (I call them seed objects in the script) based on their distance from the 0,0,0 point. Both of these realistically wouldn't be known to the explorer, but would be obvious to the player if they just look at the sector map - which is (tentatively) justification enough for me.

[Khaak_Slayer]

You're a legend mate, thankyou very much, i was really missing this in TC

[Dreamwind99]

Nice thanks.

Any chance you can take a peek at the UT not checking standings prob when trying to buy wares.

[ThisIsHarsh]

Nice thanks.

Any chance you can take a peek at the UT not checking standings prob when trying to buy wares.

Well to be honest I wasn't even really sure about releasing these fixes, since I'm sure the problems will be sorted for a future patch. I only released because I had already written them to sort out my own game... and I never use UTs.

The UT problem has been reported soo many times now that egosoft will have to do something about it, surely. But if there isn't a fix in the next patch, or the patch doesn't come out in the near future, or someone else doesn't fix it... then yeah sure, I'll take a stab at it.

Long story short, not right now no, sorry - got too many other irons in the fire.

[Litcube]

Ahh, I think I see what you mean. But doesn't that mean that in all but the most dense sectors there will likely be several objects 'cheated' into being known? What about pandora crates and hidden ships/stations waaay off the normal sector radius?

I only flag stations and gates. The ships and crates stay hidden until the player finds them. Those sort of things couldn't be physically seen with the naked eye from the sector center, so the explorer pilot wouldn't be flying towards them. The "realisim justification" of my script would be that the pilot would only fly towards objects huge enough to be seen with the naked eye within a sector (gates/stations) using Video Enhancement Goggles. Perhaps I should also require Video Enhancement Goggles for my version to work.

[ThisIsHarsh]

I only flag stations and gates. The ships and crates stay hidden until the player finds them. Those sort of things couldn't be physically seen with the naked eye from the sector center, so the explorer pilot wouldn't be flying towards them. The "realisim justification" of my script would be that the pilot would only fly towards objects huge enough to be seen with the naked eye within a sector (gates/stations) using Video Enhancement Goggles. Perhaps I should also require Video Enhancement Goggles for my version to work.

Ahh, that does make sense I must admit.

Of course you wouldn't detect ships and crates, neither does the stock implementation or my own script - don't know what I was thinking there.

However, the same argument does apply for stations far from the sector radius, like hidden bonus (or whatever) stations (there were several in XTM, for example). Of course, it's a simple case to restrict the search radius to something sensible so things that are supposed to be hidden stay hidden unless you actively look for them.

Well, I look forward to trying out your version if/when you release it, then!

I agree if you're relying on visual identification as your justification, then video enhancement goggles are a must. Plus, don't forget asteroids (you didn't mention them above). Maybe have the explorer fly around 'scanning the horizon' with his video enhancement goggles for a bit before flying directly to the object. Oh and another thing, if you're relying on human sight, there's a plethora of 'pilot' and 'passenger' commands available now, so perhaps you could even 'hire' an Explorer to pilot your craft.

LOL, somehow doesn't seem right giving so many ideas for a script so similar to my own. But I think mine is about as simple as it can be and still work acceptably, so I got that niche at least, and I don't really intend to expand this except for minor tweaks.

[Litcube]

Hey, we're all working together to build a community here.

[Cycrow]

the bug is not to do with the script, and has already been fixed for the next patch, so i wouldn't worry about it too much

[Dreamwind99]

It still drops masses of sats.

Everything else works like a charm.

[Scoob]

Hi,

Been trying this one out purely for it's asteroid scanning ability.

I issue the 'Scan Asteroids' stand-alone command and it starts to do just that, however every now & again it just stops. I've waited on SETA for a while in case it's just paused but it doesn't start again until either i) I reissue the command, or if that fails ii) give the ship a move command then reissue the command.

Not a big deal by any stretch of the imagination but just wanted to report it.

Excellent & very useful addition to TC this - mapping out Ore Belts asteroids just wouldn't have been fun!

Cheers,

Scoob.

[lepidosteus]

Got a bug: while doing an asteroids scan command, my ship wen't "through" an asteroid then stopped there.

Any attempt to move afterward destroyed my ship as I was moving "in" the asteroid. I'm not sure but i believe it is because it tries to get very close to asteroids before scanning - too close for some of the larger ones.

Couldn't reproduce it since I don't know which one killed me (and hadn't saved in like an hour too ..).