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

The place to discuss scripting and game modifications for X³: Terran Conflict and X³: Albion Prelude.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

Post Reply
Gyrehawk
Posts: 108
Joined: Sat, 27. Oct 12, 16:38
x3tc

Post by Gyrehawk » Mon, 5. Aug 13, 00:12

hmm...there is a bonuspack thread? i thought egosoft did it.

I think I found it. ty will see if I am right if i get an answer

Barleyman
Posts: 127
Joined: Sun, 16. Apr 06, 00:52
x3

Post by Barleyman » Tue, 3. Dec 13, 01:11

I just lost 2 M5 explorers back to back with XRM. It seems the threat avoidance is not quite foolproof. What happens is that when the scout arrives into restricted and/or hostile sector, they plot course out of the sector but then the "retreat" behavior kicks in that gets them killed. Apparently instead of doing a 360 and getting right back out of the gate they start trying to evade the warships converging into gate..

gnasirator
Posts: 1114
Joined: Mon, 13. Dec 04, 16:15
x3tc

Post by gnasirator » Wed, 4. Dec 13, 22:40

Jeah, it is really difficult to foresee ALL possible situations/locations and cases. And as scripting basically just describes a finite state machine, there are some limitations to the outcome.

Because, how do you decide in a general way, when to send the explorers straight back into the gate they came from, even if the gate is guarded by heavily armed hostiles? And when to listen to the other thread's "advice" that there are hostiles in your way and that fleeing might be a good idea.
If you really wanted to calculate the optimal outcome of that situation, you'd have to do some serious number crunching.

And by the way: The fact, that you came here to complain that you just had lost two M5's shows me, that the script actually works really well 8)
I'm glad, this is the only thing to complain about :)

Barleyman
Posts: 127
Joined: Sun, 16. Apr 06, 00:52
x3

Post by Barleyman » Thu, 5. Dec 13, 10:38

It was meant as more of an observation than a complaint as such. XRM makes the universe much more hostile so losing more robot ships is inevitable. Especially as xenos/pirates like to camp right next to the jump gate.

You wouldn't have a lot of time yourself to make a decision to get out of dodge in that situation. Autopiloting back out of the gate would get you killed for sure. As for decision-making, that'd have to be a hard-coded routine executed immediately after gating into a sector. Is there actually a way for the script to test range to hostiles?

One of those M5s got killed by heading for a gate through some bad guys in the middle. I suppose "go around" behavior would be kinda complicated to script. I could see plotting intermediate waypoints with an offset causing oscillation..

..

I had an explorer with a mineral scanner freeze until I gave it a manual move order and restarted explorer script. Just cancelling and restarting the script didn't work. Other than that I've not seen any bugs.

gnasirator
Posts: 1114
Joined: Mon, 13. Dec 04, 16:15
x3tc

Post by gnasirator » Thu, 5. Dec 13, 22:08

Sorry, I didn't mean to offend you :)
I alway appreciate new input!

So back to the script: actually, yes it is possible to measure the distance to a hostile ship. That's exactly, how the fleeing script works. Simple reason why the explorer didn't dodge the hostile ship while he was on his was to the gate is, that I didn't bother to implement a recursive dodging routine. This is kind of a one-shot thing. As soon as an explorer gets too close to an enemy, he picks the gate which is closest to an extrapolation of the opposite route to the enemy. And there he goes, hoping not to encounter even more trouble on his way.

Example:
. . . . . N

. . . . . . . . . o
E . . . . x . . . . . W


. . . . . S

In this case, x is the explorer, o the enemy. If the enemy comes too close to the explorer and (is a xenon/khaak, OR has him targeted) the explorer gets the direction to the enemy, inverts it and extrapolates it. Here, this would draw a line to the south-eastern corner, being slightly closer to the east gate. Hence, the explorer flies to the east gate.

Maybe some parallel task is possible with a more advanced dodging script checking the distance and direction to the closest thread and if getting too close, calculates the nearest position outside of the enemies' reach while still aiming roughly into the previous direction. If the explorer is faster than the enemy, this would make sense and gradually bring him around the enemy. As soon as he made it to the other side, the old task has to be reactivated.
It is even possible to do this with only one waypoint, as the other ship's speed is known. So basically draw two circles, one around the explorer and one around the enemy with the explorer's radiuses being:

Code: Select all

explorer's_speed * K
and the enemy's:

Code: Select all

enemy's_speed * K + safety distance
. Now increase K for both circles until the circle of the enemy is completely inside of the circle of the enemy. The waypoint now is the intersection of the tangent from the explorer to the enemies circle.
Feel free to program this :)

About the asteroid freeze: no idea where that comes from. Hope it was a single event and didn't happen anymore.

User avatar
DrBullwinkle
Posts: 5715
Joined: Sat, 17. Dec 11, 01:44
x3tc

Post by DrBullwinkle » Thu, 5. Dec 13, 23:28

Another problem with evasion near a gate is the combination of collision detection and vanilla enemy avoidance. It is not possible to make a script that will reliably enter a gate while enemies are nearby.

The main problem that Barleyman is having is that M5's do not have jumpdrives in XRM. A fast M6 might make a better explorer in XRM.
  • Or, you know, like a Boreas or something that can take a beating. ;)

Barleyman
Posts: 127
Joined: Sun, 16. Apr 06, 00:52
x3

Post by Barleyman » Fri, 6. Dec 13, 01:43

DrBullwinkle wrote:Another problem with evasion near a gate is the combination of collision detection and vanilla enemy avoidance. It is not possible to make a script that will reliably enter a gate while enemies are nearby.
OOS that might not be a proble, tho. And robot explorer exists out of sector most of the time.

Another scripting trick necessary beyond "how far" would be "is bad guy between me and the gate". That especially goes into territory of fuzzy logic.

Kadatherion
Posts: 1021
Joined: Fri, 25. Nov 05, 16:05
x4

Post by Kadatherion » Fri, 6. Dec 13, 03:30

DrBullwinkle wrote: A fast M6 might make a better explorer in XRM.
Indeed. Quite fittingly, in XRM the best explorer is the Truelight Seeker. Almost as fast as a Springblossom, shielded as an heavy combat M6, with all the cargo space for a buttload of satellites so it doesn't have to waste time buying them often.
In my previous XRM game my Truelight Seeker from the Goner Witness start mapped the whole universe (Lost Colony's ~50 additional sectors included) alone, without ever be in any danger.

adrianx
Posts: 106
Joined: Sun, 24. Apr 11, 18:45
x3tc

Post by adrianx » Fri, 6. Dec 13, 14:15

Kadatherion wrote:
DrBullwinkle wrote: Indeed. Quite fittingly, in XRM the best explorer is the Truelight Seeker. Almost as fast as a Springblossom, shielded as an heavy combat M6, with all the cargo space for a buttload of satellites so it doesn't have to waste time buying them often.
A (presuambly) cheaper alternative which IIRC is fast and reasonably shielded for an M3 is the Goner Ranger. I have several in my current game thanks to Bail Extension and some M5s running Galaxy Explorer; of course, as noted above, the M5s don't work as well without the jumpdrive.

Lakz
Posts: 127
Joined: Tue, 19. Feb 13, 04:20

Post by Lakz » Thu, 12. Dec 13, 05:54

Any difference between this script and 7ate9tin11s's Universe Explorers?

gnasirator
Posts: 1114
Joined: Mon, 13. Dec 04, 16:15
x3tc

Post by gnasirator » Thu, 12. Dec 13, 12:48

depends on what you're interested in.
Th script itself is 100% different because I coded it from scratch.

Functionally, I only know one difference which is that Galaxy Explorers don't use pilots and therefore don't depend on any experience levels.

(I never tested universe explorers.)

User avatar
DrBullwinkle
Posts: 5715
Joined: Sat, 17. Dec 11, 01:44
x3tc

Post by DrBullwinkle » Thu, 12. Dec 13, 12:51

I will add that gnasirator has done a lot of fine-tuning to Galaxy Explorers based on feedback from players. I don't know Universe Explorers, either, but Galaxy Explorers do the job extremely well and have a high degree of survivability, even in hostile universes.

Kadatherion
Posts: 1021
Joined: Fri, 25. Nov 05, 16:05
x4

Post by Kadatherion » Thu, 12. Dec 13, 15:04

I also do remember 7ate9tin11s' explorers were unfortunately a bit bugged: some strange behaviour from time to time, them getting stuck in silly loops and so on.

Gnasirator's explorers have been much more reliable in my experience, pretty much fire and forget as one would wish.

Lakz
Posts: 127
Joined: Tue, 19. Feb 13, 04:20

Post by Lakz » Thu, 12. Dec 13, 15:18

Thanks guys. No pilots, that's music to my ears. The True light Seeker will be perfect for the job!

User avatar
Joubarbe
Posts: 4796
Joined: Tue, 31. Oct 06, 12:11
xr

Post by Joubarbe » Thu, 12. Dec 13, 22:31

I also prefer this mod, more stable IMO. However, there is still sometimes where my explorer will be stuck trying to go through an hostile sector. "This is an hostile sector, then I can't go through because my master said so. I retreat, but I wanna see what's on the other side of this sector, so I go back." :)

Any solution to avoid this ?

gnasirator
Posts: 1114
Joined: Mon, 13. Dec 04, 16:15
x3tc

Post by gnasirator » Thu, 12. Dec 13, 23:44

yeah, there still might be some situations, where the code doesn't have the perfect reaction prepared.
But that is simply due to the pure amount of possibilities which I have to consider. I'm actually quite happy that I managed to get the explorer's intelligence to the current level, given that the whole code basically consists of lots and lots of "if -> then -> else" conditions :)

CaptainRAVE
Posts: 432
Joined: Thu, 23. Oct 03, 20:55
x4

Post by CaptainRAVE » Wed, 18. Dec 13, 12:56

This mod is fantastic, thank-you!

neuroliquidity
Posts: 9
Joined: Sun, 21. Jan 07, 13:42
x3

Post by neuroliquidity » Sat, 21. Dec 13, 08:11

First off, fantastic mod! Just finished reading all 3x pages of the thread (ouch!) and I can respectfully recognize the amount of work that went into fine-tuning everything. Well done, and thanks!

But (yeah, sorry...) there's a fundamental flaw in the flee logic that needs to be addressed (IMHO):

I've configured the Galaxy Explorers to NOT enter unexplored sectors. I fly into Blackhole Sun (as an example) from Treasure Chest (no other sectors in BHS are explored). Xenons show up, the darn explorer panics and flies into Nathan's Voyage (which I have not explored). I understand this is coded (fartherst gate from ship, exluding sector.old .... )

When a user configures the GEs to NOT enter unexplored sectors, that should override EVERYTHING. I don't care if their only choice is $sector.old (or if something is lurking in that sector, which they fled from - it's my fault if I restrict them in such a way that this results in their death). I explicitly configured them NOT to enter unexplored sectors and they disobeyed. If the logic is going to do that, don't bother giving me a configuration option for Enter Unexplored Sectors ON/OFF, since, given enough time and random enemies, the GEs are going to end up entering and exploring everything anyways....

I want to explore the unverse in a controlled fashion. If a GE flies into an unknown sector to avoid getting killed, I'll give him myself for disobeying! Again, configuration options should override EVERYTHING, or don't bother providing them.

I've taken a look at the scripts, but not certain where (in plugin.explore.flee.gate.multi.xml) to enter an additional 'if not $gate-> is known .... remove element from array'. Heck, I'm not sure that's even the right script and/or correct check to add.

Wondering what your thoughts were on this ....? If you disagree (understood ....) could you at least give me a tip on where I need to enter my own check?

Other than this,. great work. 36+ pages really shed light on how much you've tweaked the flee AI, so I'm really sorry to have to bring this up. 'course, I might be totally off base ... but judging from previous comments from Bullwinkle, re. user choice, I'm hoping you agree with what I'm saying ....

Cheers ....

neuroliquidity
Posts: 9
Joined: Sun, 21. Jan 07, 13:42
x3

Post by neuroliquidity » Sat, 21. Dec 13, 10:48

Okay. I've managed to (I think) accomplish this. I've edited plugin.explore.flee.gate.mult.xml.
1) allowed it to reference the b.explore variable (user configured).
2) When searching for sectors to 'flee to', it only adds unexplored sectors IIF the user has set it to explore unknown sectors, otherwise it only adds known sectors. Later in the code, where you remove $sector.old, this still fires IIF there are 2 or more choices of sectors (obeying rule #2). If not, then the only choice is flee back through $sector.old.

Code: Select all

* tests the route to every single warp gate in the sector
* for the one which is most safe to fly (with max dist to enemies)

* get all gates
$i = 6
$gates = array alloc: size=0
while $i
dec $i
* NLQ Added
$gate = [SECTOR]-> get warp gate: gate id=$i
* End
if $gate-> exists
  $dest = $gate-> get gate destination: return sector=1
  * Below is NLQ to only add known destinations if user configs it this way
  if not $dest-> is known
    if $b.explore.unknown
      $gate.dest = $gate-> get gate destination: return sector=[TRUE]
      append $gate to array $gates
    end

  end

  if $dest-> is known
    $gate.dest = $gate-> get gate destination: return sector=[TRUE]
    append $gate to array $gates
  end
  *end NLQ
  * Remove comments to below if remove NLQ code, above
  * $gate.dest = $gate-> get gate destination: return sector=[TRUE]
  * append $gate to array $gates
  end
end
Now, does this look like it'll break anything else?

Regards

gnasirator
Posts: 1114
Joined: Mon, 13. Dec 04, 16:15
x3tc

Post by gnasirator » Sat, 21. Dec 13, 15:05

I'm already working at a fix myself :)
The basic functionality to better avoid hostile sectors is in.
This is about it. Key fact: I now check if explore.hostile is forbidden. If so, gates leading to hostile sectors are removed from the array of possible gates to flee into.
But there are some more conditions to watch. As you can see in the code of flee.mult.

Code: Select all

if find $sector.old in array: $dead.end.sectors.whitelist
  $flying.out = get sector from universe index: x=1, y=3
  $flying.out = get next sector on route from sector $sector.old to sector $flying.out
  $flying.out = [SECTOR] == $flying.out
end

* tests the route to every single warp gate in the sector
* for the one which is most safe to fly (with max dist to enemies)

* get all gates
$i = 6
$gates = array alloc: size=0
while $i
  dec $i =
  $gate = [SECTOR]->get warp gate: gate id=$i
  if $gate->exists
    * only escape into known gates! No cheating!
    $gate.known = $gate->is known
    if $gate.known
      $gate.dest = $gate->get gate destination: return sector=[TRUE]
      append $gate to array $gates
    end
  end
end
$gates.size = size of array $gates

* If flying out of a dead end, remove gate to sector.old first! 
* Else remove hostile gates first
* So if flying out, it is more important to get out of the dead end
* than to avoid hostile sectors
if $flying.out
  gosub remove.old
  gosub remove.hostile
else
  gosub remove.hostile
  gosub remove.old
end
Remove.old:

Code: Select all

remove.old:
* remove sector.old
$i = size of array $gates
$gates.size = size of array $gates
while $i AND $gates.size > 1
  dec $i =
  $gate = $gates[$i]
  $gate.dest = $gate->get gate destination: return sector=[TRUE]
  if $gate.dest == $sector.old
    remove element from array $gates at index $i
    $gates.size = size of array $gates
  end
end
endsub
remove.hostile:

Code: Select all

remove.hostile:
* remove hostile sectors
if !$explore.enemy
  $i = size of array $gates
  
  * special case: if there are ONLY hostile sectors left, don't remove any
  * so that the safest is chosen
  $only.hostile.left = [TRUE]
  while $i
    dec $i =
    $gate = $gates[$i]
    $gate.dest = $gate->get gate destination: return sector=[TRUE]
    $gate.dest.owner = $gate.dest->get owner race
    $gate.dest.rel = [THIS]->get relation to race $gate.dest.owner
    skip if $gate.dest.rel == {Feind}
      $gate.dest.rel = $gate.dest.owner->get relation to race {Spieler}
    
    skip if $gate.dest.rel == {Feind}
      $only.hostile.left = [FALSE]
  end
  
  * There's at least one friendly sector to flee to
  * remove all hostile sectors
  if not $only.hostile.left
    $i = size of array $gates
    $gates.size = size of array $gates
    while $i AND $gates.size > 1
      dec $i =
      $gate = $gates[$i]
      $gate.dest = $gate->get gate destination: return sector=[TRUE]
      $gate.dest.owner = $gate.dest->get owner race
      $gate.dest.rel = [THIS]->get relation to race $gate.dest.owner
      skip if $gate.dest.rel == {Feind}
        $gate.dest.rel = $gate.dest.owner->get relation to race {Spieler}
      if $gate.dest.rel == {Feind}
        remove element from array $gates at index $i
        $gates.size = size of array $gates
      end
    end
  end
end
endsub

But the problem is, that there is one exception to the rule:
explorers always MAY enter hostile sectors if that is their only way out of a dead end branch of the universe.
And I just noticed that my whitelist wasn't complete. I whitelisted only the first sector with >2 gates starting from a sector with only 1 (a dead end).
But the real definition of a sector that needs to be whitelisted is every sector with more than 2 gates AND only one leading to the rest of the universe.

I'm testing the new dead end code right now. Gives me a bit of a headache because it's recursive :)


edit: okay, please test the new version and see if it solves your problems :)

Post Reply

Return to “X³: Terran Conflict / Albion Prelude - Scripts and Modding”