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

[gnasirator]

ah, in german X3, SETA is called SINZA ...

and now, after a night of much thinking and in-head simulation, I came up with an Idea:

What was the attended OOS update rate? 3 secs? And unattended? 10 secs?
What, if I write a script, like this:

Code: Select all

while [TRUE]
wait 3500ms
pos.new = this -> get position

if ! pos or pos.new != pos
this -> set local var 'is.watched.by.player' to value TRUE
else
this -> set local var 'is.watched.by.player' to value FALSE
end
pos = clone array pos.new
end

If this runs permanently in a thread, could this be a way to tell the script if the player is watching, or not?
If it works, I could use it to circumvent the problem by using 'cheat' code for the escaping routine, but only if the ship is unwatched.

I would then just put the ship directly into the next sector, no matter if jump drives installed, or not. If jump drives are installed, I'll also remove the ecells needed. Like this, it would look for the player as if the ship behaves correctly and as soon as he watches the explorer, everything will look normal but still it would drastically improve their chance of survival.

I'll check the is.watched code now ... if you have any other code ideas for finding the watched status, please tell me!

greetings![/code]

[gnasirator]

ah, in german X3, SETA is called SINZA ...

and now, after a night of much thinking and in-head simulation, I came up with an Idea:

What was the attended OOS update rate? 3 secs? And unattended? 10 secs?
What, if I write a script, like this:

Code: Select all

while [TRUE]
wait 3500ms
pos.new = this -> get position

if ! pos or pos.new != pos
this -> set local var 'is.watched.by.player' to value TRUE
else
this -> set local var 'is.watched.by.player' to value FALSE
end
pos = clone array pos.new
end

If this runs permanently in a thread, could this be a way to tell the script if the player is watching, or not?
If it works, I could use it to circumvent the problem by using 'cheat' code for the escaping routine, but only if the ship is unwatched.

I would then just put the ship directly into the next sector, no matter if jump drives installed, or not. If jump drives are installed, I'll also remove the ecells needed. Like this, it would look for the player as if the ship behaves correctly and as soon as he watches the explorer, everything will look normal but still it would drastically improve their chance of survival.

I'll check the is.watched code now ... if you have any other code ideas for finding the watched status, please tell me!

greetings!

[DrBullwinkle]

SINZA - Got it. Thanks!

I understand your loop but I do not understand what you are trying to accomplish with it. Why do you care whether the player is watching?

The COMBAT firing "turns" are 5 seconds watched and 30 seconds unwatched. I have no idea whether those times apply to anything other than combat.

My (limited) experience with WAIT inside loops is that they do not always work as expected. I think that is because the engine is event driven rather than procedural, and events get processed when the engine gets around to them. So anything based on precision timing is likely to have inconsistent behavior.

Regarding a forced jump, yeah, that's perfect. And be prepared to jump again if the destination is unfriendly.

[gnasirator]

jepp, I assumed, you would like the idea

regarding the routine: I changed it a bit now.

I'm checking the new position every 100ms now and count the checks to get an approximate update time.

If that time is > than 7500 secs, the player is not watching, I assume.

Position updating IS actually underlying the same update rates as fighting. That I have found out already.
And because explorers are always moving, I can use this to find out if the player is watching or not.

Reason: I don't want the player to see the explorers do their dirty little tricks. That would ruin the experience!
AND if the player is watching, the escape routine, I wrote is working as intended.

[gnasirator]

jepp, I assumed, you would like the idea

regarding the routine: I changed it a bit now.

I'm checking the new position every 100ms now and count the checks to get an approximate update time.

If that time is > than 7500 secs, the player is not watching, I assume.

Position updating IS actually underlying the same update rates as fighting. That I have found out already.
And because explorers are always moving, I can use this to find out if the player is watching or not.

Reason: I don't want the player to see the explorers do their dirty little tricks. That would ruin the experience!
AND if the player is watching, the escape routine I wrote is working as intended. So no need to dump this beautiful piece of code (I'm actually quite proud of that ).

[DrBullwinkle]

Whether or not the player watches, a jump is a jump, no matter what the code behind it. There is no "dirty secret" for the player to see. It is just a jump.

Checking every 100 ms is OK for testing, but will crush performance in the game.

And, let me repeat: YOU CANNOT RELY ON WAIT FOR PRECISION TIMING. And by "precision" I mean within a minute or so. I am not kidding... it does not work the way you think it "should". Even if it appears to work during debug, as soon as the game becomes busy processing other events, your WAITs will run when they want to -- not when you want them to.

I have a WAIT loop that processes some of the surrounding code immediately; ignoring the WAITs. Then, many seconds later, processes the WAITs. It was funny the first time.

[gnasirator]

yes, I know. That's why I added a bit of flexibility to it, checking if turns take longer than 7.5 secs.

And it even works perfectly! As long as SETA is off :/

And yes, a jump is a jump. But for ships without jump drive, jumping is a dirty trick

So .... I still have to do more testing. But first: breakfast


Edit: GREAT IDEA!!
I'll use the game time stamps for time measurement. That should be accurate, I hope! And therefore I can increase the wait periods, as I don't rely on them anymore

[DrBullwinkle]

That's why I added a bit of flexibility to it, checking if turns take longer than 7.5 secs.

Maybe a translation error, but you do not seem to understand the degree to which WAIT is unreliable. I don't think you can reliably time anything in X. Not the way that you would in most programming languages.

WAIT is ok for making a pause, or allowing control to shift to another script. But, as far as I can figure out, you cannot *time* anything with it. Not reliably. And certainly not with a resolution of a few seconds. It is not that precise.

for ships without jump drive, jumping is a dirty trick

Oh, I see. OK, that is true. But *you* are the only person who would not put a jump drive on an explorer, especially if it helps them to survive.

(Well, you and *maybe* the poorest of XRM players, who cannot yet afford a jump-capable explorer.)

Plus there are the performance issues, and the fact that nobody will ever watch an explorer (except for testing).

But, hey, if you are having fun, then enjoy!

[DrBullwinkle]

PS: IIRC, Lucike uses his own jump routines. I wondered why, but reports of your experiments make it seem like the only thing that can work.

[gnasirator]

I do have fun

And I will not rest until this is perfect!! And by perfect I mean it

And yes, I do understand how unreliable wait is:
every wait is an interrupt point which causes the script handling to switch to the next script, waiting for procedure.
And only when all other scripts have been worked through to a point where they themselves could be exitted by an interruption point the script handling switches back to the first script. If THEN the wait period is over, it will continue, if not, the other scripts get another run.

And furthermore there are certain events which cause a wait itself to interrupt. Therefore wait can't even be a 'wait min' as even that is not guaranteed.

But before my idea to use time stamps, the waits were the best method for time measuring, I could think of, so I had to try

edit: GOT it
Now explorers always know if they're watched or not. If they're not, they escape safely by instant beam into a neighbouring safe sector.
If they are watched, they use the working regular escape routines.

A short SETA test with 40 explorers spreading out through the universe resulted in ALL explorers surviving, except the one I watched who then tried to jump and failed because of the jump drive charge time

So -> Great success!

Check out version 1.9.4

edit2: FINALLY, 1.9.4 is out .... that took really long. Especially the fine tuning of the new code was mind crunching.
But it seems, as if it works, now

Explorer losses reduced to ~ZERO!

Have fun!

[vvex]

for ships without jump drive, jumping is a dirty trick

Oh, I see. OK, that is true. But *you* are the only person who would not put a jump drive on an explorer, especially if it helps them to survive.

(Well, you and *maybe* the poorest of XRM players, who cannot yet afford a jump-capable explorer.)

JD is not only a lot more expensive, but also needs XL-cargo capable ship in XRM (i.e a lot slower than your typical m5). And with Advanced Universe, u can't really jump to the "neraest" sector or gate.

So with that setup in mind, it *is* a dirty trick.

Then again when you think about it, that is really only necessary because of X3's limitations. Can't see why a 750m/s with a ship with 50km scanner range would *EVER* fail to steer away from trouble, so I'll take it and have no problems using the script (even though I try to keep my game as "cheat free" as possible).

gnasirator, thanks for all the work. Gonna get a couple of explorers up and running again. Hopefuly all is fine now, but if I run into any excessive problems I'll let you know



EDIT: actually, have to hold off for a while ... The main download doesn't work, and downloading from the "Temp" link gave me "error in packed (.rar) file" when trying to install. Ah ye, file size is 0b so it either didn't upload correctly or that download site sucks...

[gnasirator]

mirror changed

it's about time that x1tp site goes online again. It's a really great hoster!

@your comments, vvex:

Those thoughts were part of the reason, why I implemented that 'cheat' escaping. The other part was the sucky OOS engine update interval, destroying my beloved avoidance script.
But now I am truly satisfied with it, because no one will ever notice that the explorers actually 'cheat-escape' most of the time

edit: 1.9.5 -> Result: ZERO losses
Harr!

edit2: So? Can anyone confirm this? Does it work as intended?

[LordGaara]

I will test the new version tonight and give you some feedback. Looks cool tho. Good work.

Cheers,
Martin

[DrBullwinkle]

Does it work as intended?

Hmmm.... I don't have an easy way to test the flee script, but I did notice that:

• - Explorer retreats to undiscovered sector (with discover new sectors "off").
  
  - Explorer does not deploy satellites (Cover entire sector = "on", Number of jumps = Spawn). Explorer does not even fly to center of sector -- it only explores.
  
  - When surrounded, the Explorer jumps back and forth between two gates (forever). It never attempts to jump to a nearby safe sector.
  
  - I observed the Explorer flying right past an enemy wing. However, the wing had no action script, so perhaps they had no hostile intent.
  
  + In an hour of testing, I did not observe noticeably degraded performance. That is not conclusive, but it is a good sign.

The reason that I cannot test the flee script is because I do not know how to script in enemies and give them a patrol script. I can create enemies (Cheat Package - Create Ships), but I cannot give them an action script.

I imagine that a script to do it would only take a few lines, but there are enough other problems with this version that I did not do it.

If you have such a test script, would you post it?

[gnasirator]

yes I do have one: I place a xenon ship and let it do nothing and keep it locked in place

Explorers flee from xenons ...

Code: Select all

Arguments

    1: pos , Var/Sector Position , 'position'

Source Text

001   skip if $pos[0]
002   |return $aanull
003   
004   $owner = Xenon
005   $x = $pos[0]
006   $y = $pos[1]
007   $z = $pos[2]
008   $sector = $pos[3]
009   $ship = create ship: type=LX  owner=Xenon addto=$sector x=$x y=$y z=$z
010 @ = [THIS] -> call script 'a.ausstatten' :  Schiff=$ship
011   
012   $task = [PLAYERSHIP] -> get next available task: starting=65
013   [PLAYERSHIP] ->start task $task with script 'a.repair.lock.loop' and prio 0: arg1=$ship arg2=$aanull arg3=$aanull arg4=$aanull arg5=$aanull
014   return null

a.repair.lock.loop

Code: Select all

Arguments

    1: ship , Var/Ship , 'ship'

Source Text

001   $max.shield = $ship -> get maximum shield strength
002   $max.hull = $ship -> get max hull
003   $x = $ship -> get x position
004   $y = $ship -> get y position
005   $z = $ship -> get z position
006   while $ship -> exists
007 @ |= wait 100 ms
008   |$ship ->set ship speed to 0
009   |$ship ->set position: x=$x y=$y z=$z
010   |$ship ->set hull to $max.hull
011   |$ship ->set current shield strength to $max.shield
012   end
013   return null

But I see, I still have to do some work. I will focus on those problems next. I still remember that I was fighting against this jump-stuck problem already. It's really hard to figure an all-match solution out for this, especially, if explorers are supposed to flee safely at highest prio.

But the first two points are definitely in need of fixing. point 3 is also not intended, but I had my brain messed up already, trying to fix that

point 4 is intended. Explorers only flee from actually attacking ships, or xenon, khaak and turrets.

[DrBullwinkle]

Can you randomize the jump? Random sector? Random gate?

What is a.ausstatten?

EDIT: One more thing that I noticed: The evasion really does work now, more or less. When you get it tuned up you should definitely put it into libraries to be used for other scripts.

[gnasirator]

all a.* scripts are my utility scripts, I wrote for my testing environments.
I can spawn/destroy ships in large amounts based on type or class, lock them in position, or use them for breakpoints in the code.

a.ausstatten would be translated as a.fit.ship. it fits newly created ships with their maximum equipment.

The jump destination is chosen by the same criteria, as the normal choice for the next sector (plugin.explore.get.sector), except, when watching a ship without jumpdrive. Those try to avoid enemies and choose the gate accordingly.

If I randomize the jump destination, I would surely avoid the get-stuck problem but create others:
- possibility to enter forbidden sectors (get enemy)
- possibility to fly back into the just visited (old) sector

so I use get.sector script which basically does as following:

1. get array of all known gates in sector
2. if there is an unknown sector found and explore.unknown is true, use that one.
3. if not: filter out old sector and then hostile sectors (if chosen not to visit them) as long as min 1 gate is left
4. from the remaining known sectors, use one as destination

And sure, after I have this stuff finalized, I will be glad to create some usefull libraries out of that stuff.
I thought about creating one for setting breakpoints in code for debugging, the evasion stuff and for reunion I just created two scripts mimicing the find station commands from TC/AP which support an exclude array for blacklisting.

But first, I have to get galex and mk3 finished completely

edit: how can I reproduce the get-stuck between two sectors error? In my tests the old sector seemed to be correctly filtered out. and there is always at least 3 gates within two sectors, so this shouldn't occur :/

edit2:

- Explorer does not deploy satellites (Cover entire sector = "on", Number of jumps = Spawn). Explorer does not even fly to center of sector -- it only explores.

Did you have enough money to afford the satellites? Because I can't observe that behaviour in my tests. But having not enough money would cause this (intended).

Else, I think I got it now ... have tweaked and adjusted some more stuff about sector finding and so on. They even find their way out of a dead end surrounded by enemy sectors now with discover new/hostile off

so please test 1.9.6!

[DrBullwinkle]

a.ausstatten would be translated as a.fit.ship.

Sorry, I should have been more precise. I meant, "please post a.ausstatten".

I can spawn/destroy ships in large amounts based on type or class

And please post *that*, as well, because that is what I was looking for. You posted code for *a ship*. If I am going to test this, I need code for *ships*. Plural. With a command attached (such as patrol).

or use them for breakpoints in the code...

I thought about creating one for setting breakpoints in code for debugging

I noticed that your scripts have a subroutine for breakpointing. That is far more interesting to me than Galaxy Explorers, TBH. Lack of a proper debugger is holding me back from doing more scripting. (Also lack of understanding how to best use TC's "debugger"). I would love to hear how you do it.

If I randomize the jump destination, I would surely avoid the get-stuck problem but create others

Why? Why not pick a random destination sector, then apply your usual tests?

so I use get.sector script which basically does as following:

From your description, it would seem that get.sector is gate-centric and based on the current sector. That logic does not really make sense for selecting a jump destination.

sure, after I have this stuff finalized, I will be glad to create some usefull libraries...

But first, I have to get galex and mk3 finished completely

Suggestion: It is easier to develop the reusable code (libraries) *first*. Trying to unravel spaghetti code to convert to libraries later can be ten times more time-consuming. I will say it again: DESIGN FOR REUSABILITY will make your life easier and your code better.

(It is easier to do with a real editor, which is one of the reasons why I keep saying that I do not think it is possible to write good code with the Script Editor.) (Although you do a better job than most. )

how can I reproduce the get-stuck between two sectors error? ...

there is always at least 3 gates within two sectors, so this shouldn't occur

How is the number of gates relevant? For jumping, the gates do not matter.

To reproduce, put enemies on both sides of the gate (with the explorer in between).

My test was not very sophisticated. I did not have code to create a sector full of patrolling xenons, so I added wings of static xenons. I kept blocking the explorer's path, hoping to make him jump to a safe sector.

Instead, he just went back and forth through the gate, which had enemies on both sides.

Did you have enough money to afford the satellites?

I had plenty of money in the save that I was playing just before I did the Humble Trader start for testing.

Oh... um... yeah. Never mind.

Thanks for the explanation. I will add some money to my account for the next test.

[gnasirator]

you are right about so many points

but to be honest, I wish I could foresee which exact methods I need put in a library and how those method would have to work.

I am programming along the current needs and only after it's done, I can see that this or that might be nice to be put in a library.

btw: My Tools. Have those extracted and the call of breakpoint causes the ship to rename, you hear an alarming sound and you then have 20 seconds time to activate the script trace of that ship. voila, you are at the script position.
and if you use the task argument, the breakpoint will kill all other tasks except the submitted one.

About the criticism on get.sector I know what you mean but on the other hand, there is no real need for the explorers to jump more than 1 sector so why make things more complicated?

And btw, gate choice now IS randomized as of 1.9.6. So no more getting stuck, except if there are enemies on both sides of a gate. Jeah that IS a problem. But actually a very rare one, isn't it? especially when not watched (what they are most of the time), the explorers insta-jump away, avoiding that problem.

ah and about xenons: they don't need to patrol static is fine. As I said, any xenon triggers the getaway. And if you block every gate of a sector, explorers will stick to the last one and fly through it and not get stuck. already taken care of that one

[DrBullwinkle]

I wish I could foresee which exact methods I need put in a library and how those method would have to work.

EDIT: You do not have to have perfect foresight to make libraries. Just think about which parts of code will be reused, and build the library at the same time that you build the script. It does not have to be perfect on the first try. Continue to develop the library as you go along.

This is one place where a real editor is important, because it allows you to have multiple scripts open at the same time. That makes it much easier to break your code into smaller pieces. Smaller packages = better code.

Smaller packages are also easier to code and maintain, because they have less spaghetti.

You can still use the script editor during debug, of course.

My Tools. Have those extracted and the call of breakpoint ...
voila, you are at the script position.

Nice! I have been looking everywhere for something like that! Thanks.

there is no real need for the explorers to jump more than 1 sector

Case: Explorer flees into a sector that the player discovered. That sector is full of enemies, with no explored gates beyond.

Only choice is to jump two (or more) sectors back to safety.

if there are enemies on both sides of a gate. Jeah that IS a problem. But actually a very rare one, isn't it?

Not rare at all, especially later in the game, when there are enemies in many sectors.

when not watched (what they are most of the time), the explorers insta-jump away, avoiding that problem.

I believe you, but that is hard to test. How can I watch what the explorer is doing if I cannot watch him?!