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

[gnasirator]

ah sure, it should be 'safe station', right?

okaaaay ... I think I know, what happened to the menu:
I adjusted the spawn menu to the new changes and deleted the file by accident. I fortunately had a backup, but it seems, the backup was not modified yet. I must have picked the wrong file then ...

I will correct that on sunday! I didn't understand you right, the first time

!!! Good point, I just realized that I have to merge the improvements I made to the MK3 delivery service over to the galaxy explorer service. I totally forgot about that.

My todo list grows longer and longer.

If you are not swarmed by your girlfriend.

Well, she can't because then I'm back at home while she lives ~100 miles away

[DrBullwinkle]

ah sure, it should be 'safe station', right?

Yes. Or, since it is a title, "Capture - Safe Station" would also be OK. I slightly prefer it with "proper case" (capitalized first letter), although it is a very tiny matter.

she lives ~100 miles away

That's the best way. Absence makes the heart grow fonder.

Paul Newman and Joanne Woodward had the longest-running marriage in Hollywood. She lived in Beverly Hills and he lived in Connecticut (5,000 km apart). They had to fly to see each other. Of course they owned a private plane so it was not a difficult flight. But, still, some "free space" is healthy.

[gnasirator]

But, still, some "free space" is healthy.

That's it, exactly. And it really is


edit: I re-released the fixed version. all should be fine now!

[DrBullwinkle]

all should be fine now!

If by "all" you mean "the spawn-mod configuration for captured ships", then, yes. It works now.

(And thank you for shipping it as .xml!)

However, my explorers are still sitting at the same station that they have been at for two days; waiting for their "delivery".

[gnasirator]

*cough* try again (new version)

I simply forgot about that. All the changes together now make up for a new version number.

I switched to the autotrade delivery service. Explorers are now using that. It should even work fine, if the improved MK3 scripts are not installed. But I will test that tomorrow, just to make sure.

Thus I don't need to update two instances of the script. in fact, the delivery scripts could also be released as a lib. It's very easy to use and doesn't need anything else.
But it's not my work, so I can't do it.

[DrBullwinkle]

OK, I tried 1.9.8.4.

Explorer #1 continued to stay at the same station that he has been at for several days. He was still waiting for his delivery. I tried Stopping him and restarting Galaxy Explorer, but he continues to wait.

So I sent Explorer #1 on an errand to see whether he could be forced to start. No Joy. He now sits in his new location; waiting for a delivery.

Explorer #2 also waited at the same station he has been at for several days. I noticed that his cargo bay was not maxed, so I sent him to a Trading Post for Cargo Bay Extension. Then I restarted Galaxy Explorer on him, and he began exploring!

Interestingly, Explorer #2 jumped between sectors rather than flying through gates. Jumping is good; thank you.

Explorer #2 is now sitting at a base; his current task cycles between "None" and "Explore Galaxy" about once per second.

Also, I just noticed that more than half of my UT's are "waiting for delivery". While that keeps them safe, it is not really the best thing that they could be doing.

So:

• - Explorer #1 is still stuck waiting for delivery.
  - UT's are doing the same thing -- stuck at a base; waiting for delivery.
  - Have I mentioned that requiring energy cells for emergency jumping is a bad idea?
  - (and by "bad idea" I mean that it is IMPOSSIBLE to make it work reliably?)
  - What is Explorer #2 doing?

So far, I think the best versions are:

• Mk3 Optimization v1.7.6 (almost perfect, except for the rare loop)
  Galaxy Explorer 1.7.8

I switched to the autotrade delivery service.

Should there be plugin.autotrade.deliver... scripts in the package? I do not see that.

the delivery scripts could also be released as a lib. It's very easy to use and doesn't need anything else. But it's not my work, so I can't do it.

I understand the dilemma. However, there is nothing stopping you from documenting "How to Use Autotrade.Deliver Scripts as a Library".

[gnasirator]

Your problems are a riddle to me. I can't imagine how that happens. Could you give me another save game, maybe?
In my tests explorers always just work well, including the delivery service.


I have nothing to do with the message from the ship computer. It's a setting you can switch on or off in the command menu from the ships. I don't use it but I guess I can't change anything about it anyway. It's hardcoded.


How exactly did explorer #2 jump? With jumpdrive? Maybe tell me first, what ship types you are using right now.
Large ships use their jump drives because they can afford to keep a certain amount of energy in their cargo bays. Small ships only keep an emergency fuel amount.
Yes, you have mentioned that emergency ecells are bad. Noted. But I won't change that, as it is a major change in game dynamics which I want to avoid


The scripts should not be in the package. Simply because they even already exist in vanilla games. Given it is not the improved version, it still works. So I can keep scripts seperate.


I could document that. But would it be worth the effort? It's so simple -> just call the delivery script on a ship. done. Everyone who wants to can figure that out in no time


To sum it up:
Please send me your save, that I can check the idling and Explorer #2.

[DrBullwinkle]

Oh, right... you are *not* sending the message. I knew that.

Here is my save: X06.sav

[gnasirator]

However, your script must call !move.jump or !move.jumptonearestgate in order for Free Jump to work.

I was going to suggest modifying the !move.jump* scripts anyway.
I am always using them, so this should solve your free jump issues

I'm currently downloading your save...

[DrBullwinkle]

Free Jump for AI's is a *feature*, not an "issue".

The issue is sitting at the station doing nothing.

The question is, "What is Explorer #2 doing after he has finished exploring?". Is he checking for new sectors? Missing satellites? What condition(s) is he waiting for?

[gnasirator]

I didn't have much time before university, but what I could see at a glance, was, that several of your ships were waiting in sector->null with an unknown command.

Did I mess up adjusting my game to your mods? Because the delivery ships jump to null after initialization, too. That would explain the waiting.
I don't know, why that happens but it is definitely unique to your game. I will try to get your save running properly this evening when I'm back from cycling!

Maybe I can figure out, what's going on then.

So long!

[DrBullwinkle]

several of your ships were waiting in sector->null with an unknown command.

How do you see that? Which ships?

When I look on the Property Owned sheet ("r" key), all of my ships appear to be in known sectors with known commands (or "None"). I have not noticed any missing ships (although it could be possible).

the delivery ships jump to null after initialization, too. That would explain the waiting.

It would indeed. I am fairly certain that the UT's worked properly under 1.7.6.



Looking at plugin.autotrade.delivery, at line 30 I see:

Code: Select all

skip if [OWNER] == {Player}

[OWNER] is a constant... I do not see how it could *ever* be equal to the race object reference {Player}?



Also, if I read the following correctly, then plugin.autotrade.delivery will create the Goner Ranger in sector null if it cannot find a station selling the ware that it seeks:

Code: Select all

0093 start.ship:
         ...
0097 skip if $upgrade.seller->exists
0098   goto label spawnware
         ...
0146 spawnware:
           ***sub spawnware does not set $upgrade.seller!!!***
           
           *sub spawnware does not have an endsub*
0157 goto label return

0086 return:
           *sub return does not have an endsub*

********************************************
* If the code finds its way to this line, then 
* $upgrade.seller will be null:
0121 create ship: ... addto=$upgrade.seller ...
********************************************

At least, that's what it looks like to me.

[gnasirator]

Good point!
I will check on that but first I have to get your game running properly.

As far as I can remember, the delivery script only sends a ship if there is an upgrade seller. Else it would spawn the ware or cancel.

I saw your ships being in null because I couldn't access their command menu and they don't have a sector in the property sheet.
But now I'm sure that this is a problem with my game installation.
For example, you sent me the 03.cat and 03.dat but I already have one. So I changed the name to 04 and moved the other cats from your package accordingly upwards (05, 06).
I still have the feeling, that my Bullwinkle instance of the game is messed up. any hints?


And [OWNER] is a pointer at the race of the object, the script is running on. So it can be Player or anything else. Depends. Just like [DOCKEDAT] etc.

Code: Select all

skip if $upgrade.seller->exists
  goto label spawnware

This makes sure, no upgrade ship is spawned in null.
The spawnware routine needs no endsub. It simply checks if the ware may be spawned and ends the script by going to label return.
The label return ends the script, hence doesn't need an endsub either.

[DrBullwinkle]

Good point!

Which point is that? I made like half a dozen of them.

the delivery script only sends a ship if there is an upgrade seller. Else it would spawn the ware or cancel.

OK, maybe that is what it is doing. The sub spawnware does goto sub return:.

I saw your ships being in null because I couldn't access their command menu and they don't have a sector in the property sheet.

OK, that does not happen to me.

I still have the feeling, that my Bullwinkle instance of the game is messed up. any hints?

Not many. I did not tell you that I also have Immersive Environments and IEX installed. They do not seem relevant to most scripts, but you never know.

I have adjusted a few scripts since I posted my game files. I can re-zip the scripts and t folders for you, if you want.

However, the only thing that I can think of that might cause the problems you and I both experience are the Mk3 1.7.7 updates.

I will reinstall 1.7.6 and see if that clears up the Mk3's.

And why won't you tell me what an explorer does when it is finished exploring?

[gnasirator]

The first one! I kind of answer to your posts from top down. I'm just too lazy to quote all the relevant lines from you


It would be nice, if you repacked the files for me. Not only the scripts but also the mods. I have a feeling that something doesn't fit in for me. At least the 03.cat/dat files are already present in my game with a different size.


Oh and I didn't tell you what they do, because ... well ... they don't do anything, because they never finish

[DrBullwinkle]

the 03.cat/dat files are already present in my game with a different size.

I don't follow you.

You have a separate X3 folder with my game in it? Then you should have only my .cats, right? Why would you have your own 03.cat?

If you are trying to use my mods in your own game folder, I can see how that might cause trouble.

If you do not know what is in your 03.cat, then why not re-install the .cats that I sent you?

I'm confused.

I didn't tell you what they do, because ... well ... they don't do anything, because they never finish

OK, then we can put both Explorers 1 and 2 in the "Anomaly" Bucket.

[DrBullwinkle]

OK, there *is* something funky about about Explorer #2.

("Funky" is a technical term. It means, "messed up". Also, "smelly".)

Explorer #2 does not have a Location in the Property Owned sheet. It's current order toggles between "None" and "Explore Galaxy" about once per second.

I cannot give a "Stop" command to Explorer #2.

If I try to look at its Command Console, it has "???" in several fields (Shield, Hull, Laser, Freight, Current Max Speed, Acceleration, Current Max Steering, Current Cargobay.

SE's Additional Info for Explorer #2 shows plugin.explore.getSector toggling to plugin.explore.naming, then back to .getSector.

I do not know what any of that means, but it is the only ship like that.

How do you see the delivery ships in sector null? A test script?

Is there a way that I can track the delivery ship, to see what it is doing?

[gnasirator]

yes, there is:
in the delivery script, change the $owner variable to Player. Then all delivery ships will be yours and you can easily see, what they are doing.

So you have the same problem as me. I see those '???' fields, too and I can't explain, why that happens. I've never seen such before.
All delivery ships get created in a valid sector and then jump into null, too. This puts them into the same funky situation.

Honestly, I doubt, that a script can cause this. Have you installed any other mod during the mk3 upgrade from 1.7.6 to 1.7.7?

plugin.explore.get.sector doesn't call naming, as far as I remember. Naming is done only one - in the main script. So this is really strange! Or funky
I'm sorry but I really don't know any further ...

[DrBullwinkle]

I see those '???' fields, too and I can't explain, why that happens.

I did more investigation. It appears that the Explorer can explore its way into a sub-space anomaly. Perhaps it is a null sector, although I cannot prove it. That leads to the question: Is there only one null sector? Or are there an infinite number of null sectors, some of which may even contain alternate versions of ourselves?

I do not know how it happens; perhaps there is a bugged gate in IE or IEX?

No matter how it happens, it is a boundary condition that the code should test for. In fact, there are a number of boundary conditions that the delivery script alone does not test for... they really should be cleaned up before you submit the code for signing. I assume that there are others throughout autotrade scripts.

Each untested boundary condition is another bug waiting to happen, when some game circumstance does not meet your expectations.

I fixed the getSector script. Explorer #2 is now working properly. No future explorers will be trapped by the same sub-space anomaly.

*Link removed. Updated a couple of posts below.*

[gnasirator]

Hmm, nice to read that you are making progress fixing your problems.

But one thing pops into my mind here:
You are trying to make the explorers cope with a malfunctioning universe. I think it makes more sense to fix the real problem and leave the explorers alone. They have sufficient checks assuming that the universe itself works (every gate leads to an existing sector).

About the delivery script: I'm quite sure, that this will get signed. Simply because it still is in vanilla (signed) condition except from some changes I made.
Actually, even the vanilla delivery script is already a modified version from my very first improvement. I created the delivery.go script and made it run on the delivery ship. Before, all scripts were running on the trader which led to problems if the trader was stopped while receiving a delivery. The delivery ship would simply stop working and float around idling.
I'm still a bit disappointed, that I wasn't mentioned in those scripts...

Back to topic:
I'll take a look on your modifications. Maybe some of them also make sense in a functioning universe. But I don't want to fix other peoples bugs by creating workarounds in my scripts. E.g. checking if a gate leads to null is useless simply because a gate leading to null is a fault in itself.
So this is work that doesn't need to be done.

Btw, I think it isn't only a gate leading to null. Maybe even all gates work correctly. I rather think, it's got to do with jumping itself. Because delivery ships are created in a valid sector, the sector of the sellstation. They THEN jump into the customer ship's sector and that's where they end up in null. The customer's sector does exist, though. The customer is waiting in it. So something with the jumping procedure might be wrong...? Maybe that helps your investigations?

I have not been able to get Mk3's to restart on their own. I expected that incrementing the version number would restart them, but it does not appear to do so.

It does, but the check happens only once per complete trade run.


My schedule says that I'll be back home this evening btw. I'm at university right now. I'll take a close look on this stuff then!