As of this update, the DX merge is officially functional and complete within the CVS main branch. Tell Inquisitor we won't need to roll back at all, but Goober5000 needs to go and look at his SEXP code since he messed up a bunch of checking functions with it
has primitive sensors it can't target anything and objects don't appear
on radar if they're outside a certain range. This range can be modified
via the sexp primitive-sensors-set-range.
--Goober5000
one ship would return after only dealing with the first ship.
Also added the following sexps:
is-ship-stealthed
ship-force-stealth
ship-force-nostealth
ship-remove-stealth-forcing
They toggle the stealth flag on and off. If a ship is forced stealthy, it won't even
show up for friendly ships.
--Goober5000
subcategorizations are possible. Here are the instructions from sexp.h...
"Adding more subcategories is possible with the new code. All that needs to be done is
to add a #define here (a number from 0x0000 to 0x00ff ORred with the category that it
goes under), some appropriate case statements in get_subcategory() (in sexp.cpp) that
will return the subcategory for each sexp that uses it, and the submenu name in the
op_submenu[] array in sexp_tree.cpp."
Please note that I rearranged a whole bunch of sexps in the Operators[] array in sexp.cpp
in order to make the subcategories work better, so if you get a whole bunch of differences
or even conflicts, just ignore them. :)
--Goober5000
"Since there is no way to keep track of subsystem status once a ship has departed or has been destroyed, check the mission log. This will work in 99.9999999% of all cases; however, if the mission designer repeatedly sets and resets the scanned status of the subsystem, the mission log will only return the first occurrence of the subsystem cargo being revealed (regardless of whether it was first hidden using set-unscanned). Normally, ships keep track of cargo data in the subsystem struct, but once/ the ship has left the mission, the subsystem linked list is purged, causing the loss of this information. I judged the significant rework of the subsystem code not worth the rare instance that this sexp may be required to work in this way, especially since this problem only occurs after the ship departs. If the mission designer really needs this functionality, he or she can achieve the same result with creative combinations of event chaining and is-event-true."
Please note that this problem only occurs with cap-subsys-cargo-known-delay, only if the subsystem scanned status is revealed more than once, and then only after the ship is no longer in the mission. Sufficiently rare, I figured, that I could afford to not worry about it.
--Goober5000
PLEASE NOTE: These sexps will cause cargo-known-delay and cap-subsys-cargo-known-delay to not work correctly if set-scanned and set-unscanned are used more than once. I'll fix this later.
--Goober5000
Goober5000