[Bobboau]

you know I always intended to implement as 'spawn list' were you have one or more ships that get spawned when a ship dies (and the position relitive to that ship's center).
don't supose you'd be willing to give that a go seeing as you are fresh on the relivent code

(it would also be cool if spawning of weapons would be posable on death)

[Goober5000]

Originally posted by Bobboau
you know I always intended to implement as 'spawn list' were you have one or more ships that get spawned when a ship dies (and the position relitive to that ship's center).
don't supose you'd be willing to give that a go seeing as you are fresh on the relivent code

(it would also be cool if spawning of weapons would be posable on death)

No, that's not needed.  It can be done with the current sexps: when a ship is about to die, create W number of ships at X, Y, and Z relative to the ship's center.  Much more customizable that way.

What would be useful, though, is a create-weapon sexp, just like create-ship.

[Bobboau]

not if you wanted to make a ship class that relies on spawning ships, if you made a shivan ship that was realy easy to kill but once you killed it it spawned five smaller ships, that were faster and tougher, there are things that it would work vastly superior as a ship property than sExp. and if you wanted one of those smaller ships to it'self spawn three other ships, the sExp system wouldn't work because the ship wouldn't be in game, and it would be totaly imposable in waves as well for the same reason.

[WMCoolmon]

Originally posted by Goober5000
What would be useful, though, is a create-weapon sexp, just like create-ship.

Yeah, I was thinking of some fire-weapon/create-weapon SEXPs for cutscene type things.

[mikhael]

Originally posted by Goober5000
Because of the prohibition on return values, the de facto paradigm for writing sexps is to have the sexp do everything correctly or else fail.  It's the mission designer's responsibility to ensure that the failure condition cannot take place.

Great slimy tentacles! And we want to adhere rigidly to the SEXP system exactly WHY?

[StratComm]

Probably because of the exact confusion that lead to this discussion in the first place.  If an action SEXP has a return value, non-coder types may interpret that is meaning the SEXP should be used in conditional evaluations.  Which it should not, if it actually affects any change in the mission.

[WMCoolmon]

Er, no, that wasn't confusion. The SEXP worked exactly as I expected it to, and Kara used it exactly as I had intended it to be used. The problem lay in the system itself...it seems to evaluate SEXPs that return any kind of value every frame regardless of where they're placed.

The way it's set up is inefficient though. You'd need a minimum of three SEXP calls to duplicate the intendented functionality of the original. (One ship-exists call before it, one after it). Otherwise you could just set a variable equal to the ship-create call and check its value.

Granted it's pretty unlikely that the SEXP call will fail, unless you're near the ships limit.

[karajorma]

Hmmm. I meant to post after posting the thread on General Freespace.

I've just checked and you can use SEXPs with ships spawned using ship-create perfectly well. I created a ship and then blew it up a few seconds later in a different event simply by using the when-argument SEXP so that I could supply the ships name as the < argument >.
 String variables should no doubt work just as well

And WMCoolmon is correct. I didn't get the use of the SEXP wrong. Apart from the hack that Goober suggested there aren't any ways of simply using the SEXP from the action operator part of the event.



Problem at the moment is that if you put the ship-create SEXP in the conditional part of the event everything works fine until the newly created ship is destroyed. At which point its exact double pops up! I think we're going to have to hack the SEXP in like Goober suggested while it remains a conditional cause I do like the idea of being able to respawn ships that are already dead

[Goober5000]

Well, sorry... WMC made it an action event earlier today.

And in a fit of OCD, I went and added its create-weapon counterpart.

Code: [Select]

// Goober5000
{ OP_WEAPON_CREATE, "weapon-create\r\n"
"\tCreates a new weapon\r\n"
"\tTakes 5 to 10 arguments...\r\n"
"\t 1: Name of parent ship (or < none > for no parent)\r\n"
"\t 2: Class of new weapon\r\n"
"\t 3: X position\r\n"
"\t 4: Y position\r\n"
"\t 5: Z position\r\n"
"\t 6: Pitch (optional)\r\n"
"\t 7: Bank (optional)\r\n"
"\t 8: Heading (optional)\r\n"
"\t 9: Targeted ship (optional)\r\n"
"\t10: Targeted subsystem (optional)\r\n"
},

[karajorma]

I can work around that. every-time ship-destroyed -ship-create should work just as well

[Goober5000]

Oooh...

Have a look at this.
http://fs2source.warpcore.org/temp/warpdrive.zip

[karajorma]

Very cool It really does look like you're travelling at warp speed

BTW I noticed that the mission started out as my Bosch singing 6 bottles of beer on the wall mission

[Goober5000]

Er... yeah.

[mikhael]

Originally posted by StratComm
Probably because of the exact confusion that lead to this discussion in the first place.  If an action SEXP has a return value, non-coder types may interpret that is meaning the SEXP should be used in conditional evaluations.  Which it should not, if it actually affects any change in the mission.

You've just made a case against side-effects. That makes me feel dirty. Its times like this I thank the FSM that I am not a fredder.

[Trivial Psychic]

I noticed a weird problem regarding warpout speeds.  They're different for the player than for AI controlled ships.  I was flying a Whitestar wing, (without using the special warpin/out table entries) and I ordered my wingmen to warpout one by one.  When they did, they acellerated to about 150 m/s, but when I jumped, I dropped down to about 42 m/s.  There appears to be a warpout speed restriction when it comes to the player's ship.  Any chance this could be limiting my previous tests with the table entries?  Any chance that this restruction could get lifted (ONLY in cases where table-defined warpin/out entries are present, to preserve backward compatability)?

[karajorma]

Moved on from the 12-October CVS build to try my BoE stuff with Ship-Create and it appears as though when WMCoolmon changed the SEXP into an action operator he rolled the bug back into it.

The 14th-October build seems to be making up the number for the ship regardless of what I tell it to call the ship.

[WMCoolmon]

No, Goober 'bulletproofed' it. I'll let him take this one since I'm not sure what he was trying to accomplish with that code...

Code: [Select]

if ((ship_name == NULL) || (ship_name_lookup(ship_name) < 0) || (ship_find_exited_ship_by_name(ship_name) < 0)) {
sprintf(shipp->ship_name, NOX("%s %d"), Ship_info[ship_type].name, n);
} else {
strcpy(shipp->ship_name, ship_name);
}

Translated into English:
"If a ship name isn't provided, or the ship doesn't exist, or the ship isn't logged as having departed, make up a ship name based on the class. Otherwise, use the name provided."

When I fixed I had it as "If a name isn't provided, make up a ship name. Otherwise, use the name provided."

[karajorma]

That's odd. Cause I am providing the ships name (Via a when-argument list) and it's still causing bugs. You can find the mission I was using on this thread (it's the modified Bearbaiting one).

[WMCoolmon]

No, the problem is very simple...

In order to use the name provided, the ship must already be in the mission, but also have already departed. I think those two things are mutually exclusive.

[karajorma]

I see. Wasn't looking closely enough

That said I think Goober changed it when he made it possible to use none as a ship name. If that't the only edit he made then the bug predates his changes cause I'm using the 14th October build and those changes were made on the 16th.

I'll wait for Goober's comments and/or a new CVS build before commenting any further though

EDIT : Just tried the 16th October CVS build and the bug is present there.