[SCR] [X3:TC/AP] [v1.9.8.12] [03/23/14] Galaxy Explorer

DrBullwinkle · Post by **DrBullwinkle** » Mon, 26. Mar 12, 08:28

gnasirator wrote:For the range, why not scan all ships in a sector at once?

1) There is no advantage in scanning out-of-range ships.

2) There could be 300 enemy ships in the array produced by "find". MCSI is an interpreted language, so *everything* is slow... especially arrays of variant data type (which is all MCSI arrays). Multiply this by 40 or 50 UT's and Galaxy Explorers, and you have potential to slow the computer to a crawl.

Signals are very much superior to timer loops, performance-wise. But SIGNAL_TARGETED is not a native signal. It is a timer loop.

ANYTHING that runs on a timer loop should be kept as absolutely tight as possible.

If you want to scan every ship in the sector, then it would be better to attach the scan to SIGNAL_CHANGESECTOR rather than in a timer loop.

I can envision your wanting to use both types of scans, but do not try to combine them into a single routine. The two tasks are very different.

(You may not notice the time consumed in a loop during testing. But try running a heavyweight loop during heavy combat. For example, fight 100 enemies while you have 50 UT's and a several thousand NPCs running. Do it on a five-year-old computer. With 3 GB of memory -- or less.

)

gnasirator · Post by **gnasirator** » Mon, 26. Mar 12, 10:52

solved that already -> explorers only check the closest enemy anyway.
Hence the range limit is unneccessary.

Check the new version - you should enjoy it

Updates:
- implemented checks from signal_targeted (command target and command target 2)
- unfortunately, xenon ships don't set these, so explorers flee from any xenon or khaak within 15km range
- explorers who are slower than their aggressors, use their jump drive to escape
- explorers automatically fuel up for emergency jumps from fuel stations inside their current sector and keep a jump reserve of max 4 jumps, depending on how much fuel fits inside their cargo bay

DrBullwinkle · Post by **DrBullwinkle** » Mon, 26. Mar 12, 11:37

gnasirator wrote:explorers only check the closest enemy anyway.
Hence the range limit is unneccessary.

That is not at all what I just explained.

The check is not the only thing that is expensive, time-wise. The creation of the array itself can be a big hit. Also finding the "nearest" requires that the game engine sort the array, which can be an expensive operation if the array is large. Your shortcut may need to be fixed, eventually. (My guess is "almost certainly".

)

But no matter... we can test the features immediately. We can worry about performance later.

It will be nice to see an evade feature that actually works! Thanks.

gnasirator · Post by **gnasirator** » Mon, 26. Mar 12, 12:55

you are right, internally the array has to be sorted but that happens in hardcoded language and is therefore a lot faster because I'm using the find.nearest flag.

So I'm confident, that this solution is fast enough, especially when doing this only once every x seconds.
In the older versions I did this every 500ms and it still worked great.

btw: If I applay a range limit, the find ship routine still has to compare every ship in the sector to the range limit - so this is the same amount of work

btw 2: I'll change one other thing:
I won't let explorers enter xenon sectors anymore. Most of them get killed in there. And the avoidance doesn't help here as there are often xenons waiting at the gates killing the explorers immediately. So I'll just ban xenons completely for them.

And maybe I'll let explorers with a cargo bay size of > 500 units make regular use of jumprives like MK3 traders do, together with refuelling and everything.

So the small and fast ships can do the exploration and the big and slow ships can maintain the sat network.

DrBullwinkle · Post by **DrBullwinkle** » Mon, 26. Mar 12, 20:02

I'm using the find.nearest flag.

OK, I see what you are saying. Yes, that would be fast.

==============================================
EDIT:
But, wait... find.nearest will not give you the result set that you need. I made the same mistake in my pseudo-code a few messages back.

If the nearest enemy is, for example, an escort, then find.nearest may miss the enemy that is actually targeting the Explorer.

So find.nearest is not sufficient. You really need to check all of the enemies in range, which is why the range restriction is important.
==============================================

I won't let explorers enter xenon sectors anymore.

Nice idea!

And maybe I'll let explorers with a cargo bay size of > 500 units make regular use of jumprives like MK3 traders do, together with refuelling and everything.

Something like that should not be decided by the script. Just allow jumpdrive use. Then the player can decide whether or not to give the Explorer a jumpdrive.

the small and fast ships can do the exploration and the big and slow ships can maintain the sat network.

That is a good division of labor.

However, it brings us back to the 16-satellites-in-Uranus issue. I suspect that issue has to do with different settings for different explorers. I am sure that you can conquer the issue when you decide to do so.

PS: I placed the first of those satellites by hand. Explorers placed the other 15 -- 3 in each of 5 locations (center and 4 gates).

vvex · Post by **vvex** » Tue, 27. Mar 12, 02:16

Hi there,

Downloaded and tried the script today, and I have a question concerning friend/foe settings

Does the script work off of the exploring ships settings, or global settings?

I am asking because I lost both my explorers to pirates, (and pretty quickly, too). Meanwhile I saw one of them correctly retreat from the Xenons at least once.

I had pirates set to 'foe' in the ships settings, but to 'friend' in global.

Also, I saw one of the ships mapping out a pirate sector (despite the 'foe' status) so I am also thinking maybe having the mapping option "On" messes with the unfriendly sector/retreat logic?

cheers

DrBullwinkle · Post by **DrBullwinkle** » Tue, 27. Mar 12, 02:36

vvex wrote:Downloaded and tried the script today

What time today? Check the version number. Gnasirator posted a version today that should improve the retreat logic. Before today, yeah, it did not work.

Does the script work off of the exploring ships settings, or global settings?

The global friend/foe settings provide default values for your new ships. Any changes that you make in an individual ship's Command Console override the global settings. That is always true for all scripts, including the built-in, vanilla scripts.

Please let us know if you experienced this behavior in version 1.8.3.

Also, it always helps debugging if you can provide a series of steps that will demonstrate the effect that you report. Sometimes it is easiest to do that with a new game.

gnasirator · Post by **gnasirator** » Tue, 27. Mar 12, 10:00

as far as I remember, the ship's friend/foe settings are the important ones.

But as Bullwinkle already pointed out, if you can provide a way to reproduce the error, I'm sure, I can quickly fix it!

vvex · Post by **vvex** » Tue, 27. Mar 12, 13:40

I've just checked, and yes, I have the latest 1.8.3 version.

I'll give you more info, including the exact settings I used, in a couple of hours when I can get in game.

One problem may be my game is fairly heavily modded, I am playing TC 3.2 with latest XRM with Advanced Universe Pack. The ships were XRM custom 'explorer' M5 versions (in theory that really should't affect the retreat logic, but...).

gnasirator · Post by **gnasirator** » Tue, 27. Mar 12, 13:42

jepp, in theory it should work .... we'll see!

vvex · Post by **vvex** » Tue, 27. Mar 12, 16:11

Ok here it goes.

Those were the settings used for the second time:

[ external image ]

First one was identical except it had no mineral scanner so "scan asteriods" was off.

Global f/f set to 'Foe' for Khaak and Xenon, all other 'Friend'
Ship f/f set to 'Foe' for Khaak, Xenon, Pirates and Yaki, all other 'Friend' (I double checked this the second time, so I am 100% sure of this)

The ship was XRM Discoverer Explorer with full enigine tunings (~650 m/s). No upgrades except for the built-in military scanner (~50km range), explorer software and mineral scanner on second ship. NO jump drive on either ship.

The killing ships in both cases were Pirate M4s (Buzzard Raider, Sabre) which are a lot slower even with full engine tunings.

I didn't see the kills, both explorers wre obv. OOS all the time and the losses most likely happened with SETA engaged.

*** Now this may be the important bit: ***

I did notice both of the ships were mapping hostile sectors despite the settings being as shown/described. In fact I am pretty sure the 1st ship was lost whilst mapping out a Pirate sector (hence my question about friend/foe settings).

And this also may - or may not - contribute to the problem:

I am running the XRM Advanced Unverse Pack which makes the following changes to the universe map (to my best knowledge):

- about 50 new sectors are added, including hostile sectors

- all standard jump gates are replaced by Terran 'accelerator' gates so it changes the way JD works - it can no longer lock on the gates, so a few 'jump beacons' are provided in certain sectors instead.

As far as I can see these 'jump beacons' are in fact regular jump gates but with their 3d models hidden. In effect the player cannot use them, but one of the explorers actually 'flew' through one of the beacons, which put him in an empty Khaak sector (otherwise not visible on universe map). He proceeded to map the sector out (again, despite friend/foe settings) and then flew back through the gate/beacon and assumed normal operations (was lost a few hours later in a friendly sector to a pirate ship).

HTH, I'll give it another try maybe with a less expensive ship (it's early game so losing 2+ mil hurts a bit).

gnasirator · Post by **gnasirator** » Tue, 27. Mar 12, 21:50

Hmm alright.

Would you mind testing the freshly reseased version 1.9.0 ?

I did in fact change some code regarding friend/foe settings there.
Maybe your problem could already be solved.

During my tests right now, I couldn't find any problems with those settings. But to be honest, I only tested in xenon sectors and focussed more on getting my newly programmed code working properly.

If the error still occurs, I'll fix it tomorrow.

So for today: Have fun with the all new version

New Features:
- Explorers can use jump drives for buying sats and refuelling
- Explorers auto-refuel
- Explorers use jump drives to flee from enemies if they are slower then the enemy
- Explorers drop sats in a more intelligent order
- improved the config menu
- removed option to spawn satellites, because now a TS or TP with jumpdrive can quickly buy huge loads of sats from within up to 20 jumps

Still todo:
- Check ALL enemies in a sector for hostile actions (currently, only the closest is checked)
- fix vvex bug if still there

DrBullwinkle · Post by **DrBullwinkle** » Tue, 27. Mar 12, 21:58

gnasirator wrote:Still todo:
- Check ALL enemies in a sector for hostile actions (currently, only the closest is checked)

You definitely do not want to test all enemies. If there are 300 of them (which happens often enough in my game), then the performance hit will be huge. Checking only the closest will not work, as we discussed yesterday (and the day before).

Just check the enemies in range, like SIGNAL_TARGETED. What's so hard about that?

gnasirator · Post by **gnasirator** » Tue, 27. Mar 12, 22:03

yes, actually that's what I meant, you are right ...

DrBullwinkle · Post by **DrBullwinkle** » Tue, 27. Mar 12, 22:05

gnasirator wrote:yes, actually that's what I meant, you are right ...

OK, sorry!

@vvex: Awesome report, dude!

vvex · Post by **vvex** » Wed, 28. Mar 12, 00:12

K, have done a little bit if purposeful testing this time, with the new (1.9.0) version.

Nothing too conclusive but a few observations:

Used a Truelight Seeker M6 this time. Was playing with the settings a bit too.

Observation 1.

start near an unexplored xenon sector

- sector scan off, retreats immediately after crossing the gate, doesn't go back.
- sector scan on, same result. good.

Observation 2.

start 2 jumps from an unexplored sector near Ianomous Zura (fair number of pirates around). Ship starts flying towards the unexplored sector, displaying "dock at...' command (I assume this is correct/intentional). Some pirates start chasing after it while in IZ, ship correctly retreats through nearest gate. Then immediately goes back ("dock at..." reissued) and seemingly ignores the same pirates until attacked. When attacked starts retreating to a different gate (not sure which was the closest at that point) but doesn't make it. Scratch one explorer.

Comment: These kinds of situations are bound to happen (where retreating won't help). But maybe it would be smart egg. to dock at the nearest station and wait for a bit after retreating then reassess after undocking (UTs seem to have something like that implemented).

Don't know why the ship ignored the pirates the second time though, but it just flew right into them for some reason.

Observation 3.

While mapping a sector ("scan sector" option active) the ship also seemed to ignore a group of pirates passing very close by; they did not turn hostile and just flew by. Still, if they did the explorer was likely toast.

So it seems things are still not as good as they could be

. It may be that the "scan sectors" option is the root of most of the evil here. I'll just keep on playing with the option turned off and see if it helps survivalability.

DrBullwinkle · Post by **DrBullwinkle** » Wed, 28. Mar 12, 03:02

gnasirator wrote: - removed option to spawn satellites, because now a TS or TP with jumpdrive can quickly buy huge loads of sats from within up to 20 jumps

What do transports have to do with explorers?

gnasirator · Post by **gnasirator** » Wed, 28. Mar 12, 08:34

they can do the job of placing satellites best.
M3s or M4s work, too.

But I wouldn't recommend M5s for building and maintaining a sat network. Just because of their limited cargo bay size.

Try it: Get a fast small TS or TP with a jump drive, set it to buy within 20 jumps and only to drop satellites.

In my tests it worked perfectly and the internal stock of satellites even grew constantly

@vvex:

@observation 1: Glad, that this is solved

@observation 2: The dock at is coming from the official scan asteroids script which I am using. I'm sorry about that but I can't change it.
Still I will try to reproduce that situation - maybe I can improve this.
@observation 3: This is intentional. Explorers only flee from ships which are actively trying to kill them (except for xenons. they'll always flee from them). But especially pirates only attack in about 50% of the cases so I didn't want to be overreacting there!

So to sum it up:
observation 2 is the only flaw left?

DrBullwinkle · Post by **DrBullwinkle** » Wed, 28. Mar 12, 09:02

gnasirator wrote:I wouldn't recommend M5s for building and maintaining a sat network. Just because of their limited cargo bay size.

That is one of the reasons for spawning satellites in the first place.

Remember, satellites are not rare. Whether you spawn or buy makes zero difference to the way the game develops. It has nothing to do with "cheating"... those who complain about that have not thought the problem through. The complaint is a knee-jerk reaction rather than a well-considered decision.

So it would seem that you made Galaxy Explorers less useful by trying to force your opinion (and your game) on the player. This is a recurring topic... those decisions should not be made by the script. Let the player make the choice.

But I love the progress you are making on evasions!

gnasirator · Post by **gnasirator** » Wed, 28. Mar 12, 10:04

I am sorry. But to be honest, every one else I have spoken to, didn't care about spawning or was even bothered by having the option alone.

And I have heavy doubts about the script getting signed if there is any heavy use of sat spawning involved.

But fortunately, I only removed the option to choose the spawning. Explorers are still capable of doing so.
So I will upload the relevant file with spawning still enabled. just for you

egosoft.com

egosoft.com

[SCR] [X3:TC/AP] [v1.9.8.12] [03/23/14] Galaxy Explorer