Trident Down

j f gearing · Post by **j f gearing** » Thu Apr 09, 2009 4:48 pm

I think I'm stuffed but I'll ask anyway
I am re-doing Trident Down and have done the mis-jump to Arama
I arrive in the middle of a huge punch up and receive an SOS fron an escape capsule
When I press the comms log button the <> symbols do not appear around the target vessel on the scanner (my graphics card does odd things in oolite)
Obviously it is somewhat difficult to pick out the escape vessel amongst 5 million thargoid robo fighters and other junk
Can anyone suggest a way round this or shall I just bog off and join the assassins guild

Cheers

JG

LittleBear · Post by **LittleBear** » Thu Apr 09, 2009 5:38 pm

Hold down the ¬ key. This will highlight on the scanner the last ship to hail you, which all be the escape pod. Remember where it is though, as if a thargoid dies and sends some curses, the ¬ key will no longer mark the pod. That should help you keep an eye on him long enough to scoop him.

j f gearing · Post by **j f gearing** » Thu Apr 09, 2009 5:53 pm

Sorry but I think you missed my point
holding down the ¬ button does not highlight the target although it does bring up the log

Cheers

JG

LittleBear · Post by **LittleBear** » Thu Apr 09, 2009 6:01 pm

Hmm, thats odd. It should bring up the log AND put "" around the golf club on the scanner which sent the message. Works on my system with Oolite 1.72.2

j f gearing · Post by **j f gearing** » Thu Apr 09, 2009 6:10 pm

I'm on 1.72.2 also
I think it's my graphics card, the triangles on the long range scanner are almost invisible and the indicator on the gunsight which points to a targetted ship has vanished
I think I'm stuffed

Cheers

JG

LittleBear · Post by **LittleBear** » Thu Apr 09, 2009 6:32 pm

You could add a beacon to the pod so it'll show on your space compase. Not really cheating, as due to your graphics card oddities you no other way of finding it. If you open up the OXPs shipdata.plist and add the following code to the pod's entry:-

Code: Select all

<key>beacon</key>
<string>P-Pod</string>

Then exit and save. First time you load up Oolite hold down the SHIFT key to commit the changes. The pod should now be mark with a P, so you can track it with your compase.

j f gearing · Post by **j f gearing** » Thu Apr 09, 2009 7:37 pm

Not much luck there I'm afraid. Wasn't quite sure where to put it
It's a big plist, planted it in 3 places where I found "pod" but no luck
I suppose if I asked for a rough idea where to stick it, I'd get a dusty answer

Cheers

JG

Screet · Post by **Screet** » Thu Oct 22, 2009 10:29 am

Hi,

I've finally reactivated Trident Down as it seems that it's previous activation somehow got stuck when some other oxp did overwrite the mission screen. I was able to solve that by clearing the trident down variable, causing it to start anew.

Playing with trunk, there's a large amount of warnings, but that's to be expected. However, when I did dock at Raceedat, I did continously get the mission screens there and the variable in my savefile did stay as "RACEEDAT1A" which apparantly caused the whole thing to be stuck again. Nothing happened anymore, thus I did take a look at the plist and then modified the string in my savefile to "RACEEDAT1B" - then I was able to continue.

While docked at Raceedat, there've been some exceptions written to the log, as if the result of the screen was not being parsed properly. Sadly, I was too asleep to act properly and save that log to a different name, thus I don't have the message anymore.

EDIT: After finding the trail, it was the same again: Constant re-display of the mission screen and this written to the log:

Code: Select all

[script.error.exception]: ***** EXCEPTION NSInvalidArgumentException: performSelector:withObject: null selector given while handling legacy script actions for trident_down

Unless that's a temporary glitch with trunk, it looks like this oxp will require some update once the next version of Oolite is released.

Screet

Makara · Post by **Makara** » Thu Oct 22, 2009 11:15 am

Screet wrote:
However, when I did dock at Raceedat, I did continously get the mission screens there...

A similar thing happened to me with this OXP - the briefing kept getting stuck on the 2nd page. Not 100% it was at Raceedat though. Also seemed to be getting other strange results with this OXP in place (UPS informing me that "Chance" - I think - hadn't been reset, or similar. Usually associated with cargo disappearing despite being displayed). I just assumed that it was the combination of OXPs set in Galaxy 4

Running Oolite 1.73.3 on Windows XP, so not trunk exclusive by the look of it.

Ramirez · Post by **Ramirez** » Thu Oct 22, 2009 5:57 pm

I've had a look I think it's the <string>clearMissionDescription: xxxx</string> that's causing the trouble. In earlier versions this flagged an error in the console but didn't do any harm, but now it's holding up the script. Replacing them with <string>clearMissionDescription</string> should fix the problem.

I also see that the d100 method isn't supported, which for some parts of the script might cause a problem. Is there a way to fix this temporarily, short of rewriting in javascript?

Screet · Post by **Screet** » Thu Oct 22, 2009 6:20 pm

Ramirez wrote:
I've had a look I think it's the <string>clearMissionDescription: xxxx</string> that's causing the trouble. In earlier versions this flagged an error in the console but didn't do any harm, but now it's holding up the script. Replacing them with <string>clearMissionDescription</string> should fix the problem.

Just tried it and yes, it does fix the problem

Ramirez wrote:
I also see that the d100 method isn't supported, which for some parts of the script might cause a problem. Is there a way to fix this temporarily, short of rewriting in javascript?

Good question, as there are other scripts using such a thing without any warnings generated:

Code: Select all

                       <string>d100_number greaterthan 60</string>
			"d100_number lessthan 10",
                       conditions = ("d100_number lessthan 14");

TD does use such a thing twice - and only the one version where it's not in the conditions is listed. Maybe it just needs to placed a few lines down.

After moving that d100 into the conditions and replacing the clear commands, this is the only message I get from Oolite about TD:

Code: Select all

[script.unpermittedMethod]: ***** SCRIPT ERROR: in trident_down.27.do.6 ("gui_screen_string oneof GUI_SCREEN_MAIN, GUI_SCREEN_STATUS, GUI_SCREEN_EQUIP_SHIP, GUI_SCREEN_MARKET, GUI_SCREEN_SHORT_RANGE_CHART"), method "gui_screen_string" not allowed. In a future version of Oolite, this method will be removed from the handler. If you believe the handler should allow this method, please report it to [email protected].

About a rewrite: I heard that the mission handling is being changed, it should stay compatible but maybe there's new things coming which you would want to take advantage of if there's a conversion to js, thus it might be a good idea to wait until the not-so mystical next stable release and then probably ask pmw for help

Screet

Post by **Eric Walch** » Thu Oct 22, 2009 9:31 pm

Ramirez wrote:
I also see that the d100 method isn't supported, which for some parts of the script might cause a problem. Is there a way to fix this temporarily, short of rewriting in javascript?

It is supported, but those two occasions that flag the error have never worked. This bug and the fix was reported elsewhere.

You did not use that random number as a condition but as a command in the DO part.

Screet · Post by **Screet** » Fri Oct 23, 2009 12:06 pm

Argh. I've now been rammed to death more than 20 times in a row

Are the ATU Vipers doing such a move on purpose or is it just this turret-subentity thing which appears to make collisions more likely?

Yes, I could simply have cloaked and thus even stayed clean...but where's the fun in hiding?

Screet, who thought to be almost free of kamikaze fighters...

Post by **Kaks** » Fri Oct 23, 2009 1:26 pm

Screet, is that what you get using 1.73.4, or is it from your own build?

If it's the latter (that 'free of kamikaze fighters' line makes me think so) it could be that you inadvertently changed something that triggers the ATU vipers suicide attacks. Do you get the same behaviour using 1.73.4?

If it's the former, that sounds 'a bit' unusual...

Screet · Post by **Screet** » Fri Oct 23, 2009 2:57 pm

Kaks wrote:
Screet, is that what you get using 1.73.4, or is it from your own build?

If it's the latter (that 'free of kamikaze fighters' line makes me think so) it could be that you inadvertently changed something that triggers the ATU vipers suicide attacks. Do you get the same behaviour using 1.73.4?

Yes, it's my own build, but I did NOT change behaviour of ships. IIRC intercept behaviour (at least in trunk) explicitly does exempt the target of the ships from causing collision alerts or collision avoidance behaviour but intercept AI would switch itself off if the disired range is achieved - and I expect that to happen before a collision could happen, thus I did not modify it.

My guess is, that it's the turrets - I sometimes have my ship explode close to objects while I would not expect any collision probability.

Screet