[SCR] [X3:TC/AP] [v1.9.8.12] [03/23/14] Galaxy Explorer
Moderators: Moderators for English X Forum, Scripting / Modding Moderators
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..
-
- Posts: 1114
- Joined: Mon, 13. Dec 04, 16:15
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
I'm glad, this is the only thing to complain about
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
I'm glad, this is the only thing to complain about
Skripte:
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.
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.
-
- Posts: 1114
- Joined: Mon, 13. Dec 04, 16:15
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: and the enemy's:. 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.
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
Code: Select all
enemy's_speed * K + safety distance
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.
Skripte:
- DrBullwinkle
- Posts: 5715
- Joined: Sat, 17. Dec 11, 01:44
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.
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.
Peace through superior firepower
Bullwinkle's List | Marine Repairs and Training | Mobile Mining Mk2 | Drone Carrier Software 2 (DCS2) | Ship Tricks: Mini-Guides (with Video)
Bullwinkle's List | Marine Repairs and Training | Mobile Mining Mk2 | Drone Carrier Software 2 (DCS2) | Ship Tricks: Mini-Guides (with Video)
OOS that might not be a proble, tho. And robot explorer exists out of sector most of the time.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.
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.
-
- Posts: 1021
- Joined: Fri, 25. Nov 05, 16:05
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.DrBullwinkle wrote: A fast M6 might make a better explorer in XRM.
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.
Kadatherion wrote: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.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.
-
- Posts: 1114
- Joined: Mon, 13. Dec 04, 16:15
- DrBullwinkle
- Posts: 5715
- Joined: Sat, 17. Dec 11, 01:44
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.
Peace through superior firepower
Bullwinkle's List | Marine Repairs and Training | Mobile Mining Mk2 | Drone Carrier Software 2 (DCS2) | Ship Tricks: Mini-Guides (with Video)
Bullwinkle's List | Marine Repairs and Training | Mobile Mining Mk2 | Drone Carrier Software 2 (DCS2) | Ship Tricks: Mini-Guides (with Video)
-
- Posts: 1021
- Joined: Fri, 25. Nov 05, 16:05
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 ?
Any solution to avoid this ?
-
- Posts: 1114
- Joined: Mon, 13. Dec 04, 16:15
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
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
Skripte:
-
- Posts: 9
- Joined: Sun, 21. Jan 07, 13:42
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 ....
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 ....
-
- Posts: 9
- Joined: Sun, 21. Jan 07, 13:42
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.
Now, does this look like it'll break anything else?
Regards
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
Regards
-
- Posts: 1114
- Joined: Mon, 13. Dec 04, 16:15
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.
Remove.old:
remove.hostile:
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
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
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
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
Skripte: