Problems with move to debris/asteroid ... turn turret ... command

[oechre]

the code I wanted is:

Code: Select all

$return=0
while $return != FLRET_FIREFREE
  $return = [THIS]-> move to debris/asteroid $Debris and turn turret $Turret to target:timeout= 60000
end

This will lock the game because pretty often the command will spam FLRET_ERROR

the workarround I found is to insert the following code into the loop

Code: Select all

if $return == FLRET_ERROR
  =[THIS]->move arround 9500ms
  = wait 10000 ms
end

This solution however is not much to my liking because the ship will eventually find a spot to fire from but it can take a darn long time
Has anyone an idea for a better sollution?

Thanks in advance

[Gazz]

This will lock the game because pretty often

Of course. You just don't do loops without a wait.
Even 100ms will prevent the game from locking up.

You could also try evade with "avoid (debris)" to turn the ship away from the debris and possibly get another turret to bear.

[oechre]

Thanks a bundle, I was looking for a better fly command then 'move arround'
somehow I overlooked the 'avoid' one.

I'll try it right now to see if it can reduce the time needed to get a FLRET_FIREFREE return

[esdejie]

Hi everybody. My reply comes years & years later
I run a "basic" X3R, and had a look to the debris prospection.
First, these "debris" cannot be seen as standard space objects, but rather as debris fields.

• If you manually select one of them and try to get it in your script with the instruction get player tracking aim, you get null for an answer

• if you use set player tracking aim in your script, you just see the tracking aim in game, and it points rather the debris field than any debris rock around

Thus, it is very difficult to figure out what your script really does
Second, this autopilot is a real punition: it spends more time eviting than going where it is supposed to
Third, the destruction run toward debris has the funny habitude to deliver a FLRET_ERROR here and there. A lot of factors play a role in the occurrence of this error:

• if your script spends any 15" (15000 ms) after shooting at a debris, the debris-field-object has time enough to rearrange itself, and you lesser the chances to get a FLRET_ERROR at next move

• this error seems to be depending upon the vicinity of the mining ship. If the miner runs away enough (2500-5000 m), he can finally make a successful attack run again

• in fact, this error relies on the proximity of any of your ships. Let's say you have your test miner running the script, and you are in your own ship, just 1 km away, carefuly looking at what happens. The FLRET_ERROR occurs on your test miner (on which you run the debugger), and his script takes him away in response, 1km, then 2, then 3 a.s.o. ... That won't work,'till you go yourself many km away Once you and your miner are far enough, the miner endly performs his attack move

• to run my miner away from the debris field, I don't have any avoid instruction on X3R. And the move around is not so reliable: sometimes it doesn't take my miner far enough. So I had to set up an external script, which determines a "far away point" in the same sector, then flies my miner toward it, mile after mile, testing the attack move at each mile.

• result is: no need to wait a lot between 2 stops while fleeing away from the debris: that doesn't change anything. The attack-run on debris can usually be performed when your miner reaches a distance between 2500 to 5000 m from the debris-field (my final far-point is ~17000 m away from the debris)

[esdejie]

As I explained, using any move to pos to go away from the debris field was the quickest way I found to remove the FLRET_ERROR status of the attack run.
The time lost can be easily compensed with a good collection algorithm:

• after your collecting move toward debris, use catch ware (+ little wait) in a loop, untill it returns FALSE

• then test exist on the debris; if TRUE, test it for collectable mineral: if TRUE, perform another move toward same debris, and make another catch loop. Nota: this other move on same debris often doesn't actually move: it just gives another FLRET_FIREFREE, which allows other ware catching in the same debris field.

• if the debris-field is not existing anymore, examine another debris

• if not collectable anymore, have an attack run on it, or examine another debris

Actually, my miner examines 10 debris for collecting in a row, and only 5 debris for shooting in a row, in a same global loop. I tried to use another ship to shoot at not-collectible debris, but it invariably ended crashed on another ship or a rock. Urgl, oups. So I only put 1 mining ship at a place. If I put 2 miners in a sector, a one is on ore deposits, the other on silicium deposits; no collision that way.

While shooting, the miner always test if the debris has collectible mineral before and after his attack run. Why ? Because the attack run (and its lot of eviting moves) often lead to collisions with rocks which weren't collectible before collision but become collectible after collision.
And it would be very stupid to destruct any valuable collectible mineral ! You loossse profit !

With the hope that I could help somebody avoiding headaches with those damned debris