[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
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 :)

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

Post by neuroliquidity » Mon, 23. Dec 13, 04:01

Cheers, mate ;)

I've been testing this for the past few hours and it seems to be working a lot better (much better than the half-kludge that I attempted ...)

One observation ... While I actually understand your making the the choice to flee into unknown sectors (possibly) if the GE is in a dead end, shouldn't that be part of the configurations?

Rather than just a Yes/No option for 'Explore Hostile' and 'Explore Unknown', should it it be 'Explore Hostile Sectors: Yes/No/Only If in Dead End' and 'Explore Unknown Sectors: Yes/No/Only If in Dead End'?

While this might (very likely?) cause issues with the AI if that last option ('Only in Dead End') is selected, it would guarantee that the user is able to make sure that the GEs behave as configured. If a GE is killed, or ends up just flying in a small selection of space endlessly, because of how it's been configured ... but if that's the desired choice ... isn't that beset?

But .... It looks like I don't have to micromanage them too much anymore (to make sure they don't flee unto unknown space) so that's the big benefit. The smaller point on configuration, above, might require updating other (big?) portions of code ... and might be best kept for a 'rainy day' -- or just ignored ;)

So, Gnas, thanks for the patch ... and the script. You're genius ;)

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

Post by Barleyman » Mon, 23. Dec 13, 14:56

After spending half an hour to figure out just how to make satellites spawn, I'd like to suggest making it a bit easier.

The 1st post could have a line explaining how to do it. In other words, In galaxy explorer options, "Buy range" rolls over from 9 to "Spawn".

Otherwise maybe put Spawn Yes/No as it's own item.

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

Post by Barleyman » Mon, 23. Dec 13, 14:57

After spending half an hour to figure out just how to make satellites spawn, I'd like to suggest making it a bit easier.

The 1st post could have a line explaining how to do it. In other words, In galaxy explorer options, "Buy range" rolls over from 9 to "Spawn".

Otherwise maybe put Spawn Yes/No as it's own item.

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

Post by gnasirator » Tue, 24. Dec 13, 20:03

You're right Barleyman, I'll update the first post with a small info line. Thanks for the sugestion.

@neuro: I'm happy to see that the fix works. And your suggestion is also good, but as you say, I'll save the work for a rainy day :)

Ashnag
Posts: 37
Joined: Wed, 2. May 12, 10:17
x3ap

Post by Ashnag » Tue, 18. Mar 14, 20:31

Hi

i'm using this script for a while, always satisfied with it, but i noticed something that should be changed, in my opinion.

If i use this script for a ship, stopping it after a moment, the script seems to stay memorized. i explain :
I'm using M6 as explorers, cause they are very good at this. But if i stop the script to use this ship of my own, there is a problem. Each time this ship is shot by an enemy, the script awakes and turn it on a Galaxy Explorer again.

I've tried a lot of ships, M6, M1, M3, they all do the same.
Well, is it me or is it a bug ?
And, anyway, thanks for the script, very useful indeed.

Post Reply

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