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

ThisIsHarsh · Post by **ThisIsHarsh** » Sat, 25. Oct 08, 01:25

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.

[ external image ]

[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.

[ external image ]

[ external image ]

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 · Post by **Litcube** » Sat, 25. Oct 08, 03:24

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 · Post by **ThisIsHarsh** » Sat, 25. Oct 08, 04:27

@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 · Post by **Litcube** » Sat, 25. Oct 08, 04:35

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 · Post by **ThisIsHarsh** » Sat, 25. Oct 08, 04:57

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 · Post by **Khaak_Slayer** » Sat, 25. Oct 08, 06:14

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

Dreamwind99 · Post by **Dreamwind99** » Sat, 25. Oct 08, 07:21

Nice thanks.

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

ThisIsHarsh · Post by **ThisIsHarsh** » Sat, 25. Oct 08, 07:45

Dreamwind99 wrote: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 · Post by **Litcube** » Sat, 25. Oct 08, 08:35

ThisIsHarsh wrote: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 · Post by **ThisIsHarsh** » Sat, 25. Oct 08, 08:55

Litcube wrote: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 · Post by **Litcube** » Sat, 25. Oct 08, 08:57

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

Post by **Cycrow** » Sat, 25. Oct 08, 13:47

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 · Post by **Dreamwind99** » Sat, 25. Oct 08, 19:59

It still drops masses of sats.

Everything else works like a charm.

Scoob · Post by **Scoob** » Sat, 25. Oct 08, 20:21

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 · Post by **lepidosteus** » Sun, 26. Oct 08, 01:31

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 ..).

ThisIsHarsh · Post by **ThisIsHarsh** » Sun, 26. Oct 08, 16:18

Thanks for the feedback. Hopefully have solved the asteroid scanning issue reported above.

Update: v1.1

- Fix for ships trying to get too close to asteroids before scanning.

lepidosteus · Post by **lepidosteus** » Mon, 27. Oct 08, 08:23

Thanks, will report if my ships tries some "internal scan" again

46852 · Post by **46852** » Mon, 27. Oct 08, 08:48

I'm getting only "ReadTextxxxxx" in the command menu instead of AutoExplore and ScanAsteroids, the commands work without problems though. Any idea what could cause that?

ThisIsHarsh · Post by **ThisIsHarsh** » Mon, 27. Oct 08, 11:12

46852 wrote:I'm getting only "ReadTextxxxxx" in the command menu instead of AutoExplore and ScanAsteroids, the commands work without problems though. Any idea what could cause that?

I would guess that you are not using english language version? In which case you probably need to rename the 7100.xml in your X3TC\t folder to 7100-L0xx, where xx is your country code (I think - that seems to be the new format now).

An easier way than this: it looks like you can change a setting in Cycrow's Script Installer to make it automatically rename t files for your language when you install scripts.

Let me know if this helps.

46852 · Post by **46852** » Mon, 27. Oct 08, 13:28

ThisIsHarsh wrote:
46852 wrote:I'm getting only "ReadTextxxxxx" in the command menu instead of AutoExplore and ScanAsteroids, the commands work without problems though. Any idea what could cause that?
I would guess that you are not using english language version? In which case you probably need to rename the 7100.xml in your X3TC\t folder to 7100-L0xx, where xx is your country code (I think - that seems to be the new format now).

An easier way than this: it looks like you can change a setting in Cycrow's Script Installer to make it automatically rename t files for your language when you install scripts.

Let me know if this helps.

I am using English version, downloaded from Steam. L044 was the english country code wasn't it? I actually didn't manage to get scripts working with the installer (didn't try that hard tbh), so I just unpacked the .spks and copied them to appropriate folders. I'll go poke around the files when I get home, thanks for the reply

egosoft.com

egosoft.com

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

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