[Mobius]

In the actual 3.6.10 INF build(which is a normal build with a modified part of code that boosts the ships limit) I noticed that the change-soundtrack SEXP doesn't work at all. I've also noticed that an INFA mission using navpoints keeps crashing when I select "commit". I used the error checker in FRED and nothing was reported - the mission was, in fact, a normal one.

I'll remove the navpoints this afteroon and check if the mission keeps crashing. Until then I think there's something wrong with the navpoints....I used only the most simple nav SEXPs in that mission(show nav, set nav as visited, remove nav) and I'd like to know if someone else is experiencing similar problems.

[Tolwyn]

Nav code works flawlessly. The error you describe might be caused a spelling mistake (e.g. FRED does not parse nav point names. Which means, if you are checking distance-to-nav, nav-visited, etc and the nav point does not exist in the mission, the game will crash to desktop without any error messages).

[karajorma]

Is that in Mantis? Cause it really should be.

[Mobius]

Damn it, how could I forget this thread?!?

I removed all nav SEXPs and the mission crashed without reporting an error. I also changed an event's conditional from "when-argument" to the dear, normal and widely used "when" and I get an error, "Argument type mismatch". The funny thing is that there's no sign of the string "<argument>" in the SEXP now.

Basically:

cap-waypoint-speed
<ship #1, #2, #3, etc. etc.>
<argument>

now is:

cap-waypoint-speed
<ship #1, #2, #3, etc. etc.>
8

...and FSO reports that the number "8" is causing the error. I changed the name of the event, I created a new one with the same characteristics and deleted the old one...with no avail. This is kind of strange and is getting me mad.

I'm also experiencing another problem: there are 5 transports jumping in progressively with a delay of about 12 seconds from each tranport to the following one. The transports are supposed to appear in the escort list and each name is supposed to be removed from the list when the transport's cargo has been revealed.

The problem is that whenever a transport jumps in its name overrides the one of the transport that came before. I should have:

Capricorn 5
Capricorn 6
Capricorn 7
Capricorn 8
---
Capricorn 9

...but in the list there's only one name. I checked all related events with no avail. Capricorn 5 through 9 have all a priority of 0 in the escort list.

[karajorma]

If you had

when-argument
-something-of
--1
--2
...
--8

Change this


cap-waypoint-speed
<ship #1, #2, #3, etc. etc.>
<argument>


to this


cap-waypoint-speed
<ship #1, #2, #3, etc. etc.>
<string to int>
<argument>

[Mobius]

I used every-of with "8" as the only argument. 

cap-waypoint-speed
<ship #1, #2, #3, etc. etc.>
<string to int>
<argument>

There can be three arguments? I tried to add a third one but it's impossible...

[FUBAR-BDHR]

Use string-to-int as the second argument and <argument> as the operator of string-to-int.  You have to convert the <argument> from string to numeric. 

[Shade]

There can be three arguments? I tried to add a third one but it's impossible...

There can be far more than three, yeah. If it won't let you add more than two, something really weird is going on.

[Mobius]

I don't get it, I can't put in more than two arguments...the ship's name and the max speed...

[Shade]

Oh - You were talking about cap-waypoint-speed. I though it was the <argument> part of the event. Never mind then, everything working... sorry for the scare In the actual cap-waypoint-speed SEXP, you don't manually add in all the arguments from the argument list - You just use <argument>, invalidate it afterwards, and repeat the event until you've been through them all.

[Mobius]

Feeew...

How do I solve the problem? I changed the conditional but looks like FRED doesn't want me to do that and is still convinced of the fact that there's "when-argument" instead of "when"...

[Shade]

I'm not sure I quite understand what you've done with the event now, so I'll just post how it *should* look.

- op when-argument
   - op in-sequence
      # <list of ships>
   - op true (or whatever you need the trigger to be)
   - op cap-watpoint-speed
      # <argument>
      # 15 (or whatever)
   - op invalidate-argument
      # <argument>

Repeat for as many times as needed to cover all ships in the argument list, and that'll cap the speed for every single one of them.

[Edit] Oh, and as for the transports, try setting the initial escort priority (in the misc dialogue in the ships editor) to 90, 80, 70 etc. respectively as you move down the list, and then once a ship has been scanned, set its escort priority to 0 (using when-argument to achieve this for all transports while using just one event is left as an exercise for the reader).

[karajorma]

Mobius, post a picture of your original argument SEXP.

[Mobius]

Oh, and as for the transports, try setting the initial escort priority (in the misc dialogue in the ships editor) to 90, 80, 70 etc. respectively as you move down the list, and then once a ship has been scanned, set its escort priority to 0 (using when-argument to achieve this for all transports while using just one event is left as an exercise for the reader).

I tried it, but with other numbers(5,4,3,2,1), and got the same problem. When a transport is scanned it should be removed from the list, I don't think setting a priority of 0 would be the ideal solution.

Mobius, post a picture of your original argument SEXP.

Sorry for the attachment, it's only temporary...

The first two screenshots represent the actual condition of the SEXP, divided in two parts. The third one represents the old condition of the SEXP(with "when-argument"). I got that pic from a backup mission. There's no fourth pic because the second part of both SEXPs is the same(a bunch of "ship-subsys-guardian-threshold" and "ship-guardian-threshold" SEXPs).

[attachment deleted by ninja]

[Shade]

I don't think setting a priority of 0 would be the ideal solution.

Setting a priority of 0 is the only solution if you want to remove a ship from the escort list while keeping it in the mission.

[Mobius]

Wait a second...

The value 0 as SEXP's argument allows to remove a ship from the list, ok...but setting the value 0 in Ship Status ---> Misc ---> Escort Ship ---> Priority leads to the exact contrary(the ship's name will appear in the list). I didn't realize you were refering to the SEXP.

The transports' names disappear from the list as soon as they get scanned. The problem is that, for example, Capricorn 6 jumps in and its name overrides Capricorn 5's one in the escort list. There's one transport in the list,  not two...strange, because there's space for four entries.

[karajorma]

The first two screenshots represent the actual condition of the SEXP, divided in two parts. The third one represents the old condition of the SEXP(with "when-argument"). I got that pic from a backup mission. There's no fourth pic because the second part of both SEXPs is the same(a bunch of "ship-subsys-guardian-threshold" and "ship-guardian-threshold" SEXPs).[/shadow][/i][/color]

Yep. It's exactly what I though. In the one using the when-argument replace

cap-waypoint-speed
<ship #1, #2, #3, etc. etc.>
<argument>

with

cap-waypoint-speed
- ship #1, #2, #3, etc. etc.>
 - string to int
-- <argument>

and it would work.


That said I do have to question why the hell you wrote your SEXP like that when using when-argument for a list of ships would have been an infinitely smarter idea.

[Mobius]

Ok...

But the problems is that I'm not able to change the conditional in the other mission. It shouldn't happen, a conditional change shouldn't imply any error.

I'll check it as soon as I get home...

[karajorma]

If you change from when-argument to when you're going to have to clean up after yourself. I suppose it might be possible to make the game reset all uses of <argument> to whatever the default for the SEXP is but it's hardly a priority since 99% of the time when you've used a when-argument correctly you're never going to change the conditional unless it's to  every-time-argument.

[Mobius]

I see. Well, the mission crashes for other reasons anyway. I'll try to dig up the error.