Need help with SIGNAL_KILLED and an OOS combat script

[halo112358]

I wrote a simulator script that spawns two groups of enemies, each with a leader and wingmen, then starts the two leaders to kill each other with !ship.cmd.attack.pl.

I did this so that I could log the results of OOS combat between two groups, I'll extend and generalize it a bit more once everything is working - for now I have a problem. Once the leader dies leadership is not handed off properly for OOS combats, it seems to work fine IS but OOS the two groups stop and do nothing once each lead ship dies.

I'm confused, IS it works great, OOS (which is what I really wanted) it breaks after the lead ships die.

here's the code

Here's what I'm doing:

[xTemon]

I think the problem is in the first sections count

[ttl]

The killed signal doesn't work corectly OOS, as far as I understand. Like you don't get killed by who on the log message, when your ship dies OOS, but you do if IS.

People who know better can hopefully fill in.

[halo112358]

[Red Spot]

havent had to good a look at your scripts ..
though there is at least 1 suggestion I could make from what I did read ..

dont give the new-leader a command like your doing right now
the way the vanilla signal_killed works is that it is entirelly based on NPC-ships, meaning its very tempermental on playerowned ships and custom-commands (better said; it probably wont work!)

imo the "most secure and least problematic" method of starting a script/command on an object (ship/station/....) is by using the command
"<var/object> start task <var/number> with script <some script> prio <var/number> ............."

the "start command" command only works on vanilla commands and the "START script .." command has shown me some unexplainable behaviour so I'd try not to use it on ships (its not like its the plague, but .. er .. beter save than sorry ..)



G

[xTemon]

[halo112358]

Thanks for all the replies, I'll make the suggested changes when I get home tonight

ps: the initial leader of each group was the centaur.

[Squelch]

I just compared your custom ship killed to the vanilla script. As it is the same, but includes the debug log output, I suspect Endremion is correct in saying it should come after.

How long does [THIS] exist after being killed?

It may be purely a timing issue. In that case perhaps a new variable set should be generated in signal killed for use by log at a less critical time

[halo112358]

Ok, I've figured out what's happening - now I just need to figure out a clever way to fix it.

The real problem is that in OOS combat signal_killed is reporting $killer = null - this prevents signal_killed from ever calling signal_attacked on the new lead ship with $killer as it's target.

This is the boilerplate code for handling SIGNAL_KILLED (stock x3 code):

[B-O'F]

Hi halo112358,

I remember a problem with $killer not being used correctly in a stock script being discussed a long time ago - another variable was used instead. Whether this pertains to your problem, I am not sure.. I will try and find it and let you know the result later, but I have to go out now.

Boron - Ol Fh'art

[EDIT]
I found my text copy of this thread, but no pointer. It was "minor bug in signal captured " by Red Spot started Sat Jan 21, 2006, with posts from djssuk, moggy2, and Cycrow.. Extra search should be able to find it.

The really interesting bit is:-

Red Spot
Posted: Sat Jan 21, 2006 7:04 pm
naaa .. it is supposed to work like the signal.killed..

leader dies -> wingmen get leader command and signal.attacked gets triggered to attack the killer (in this case capturer)

but in this code the 'killer' argument from the signal.killed script is changed to 'privateer' .. but the actual variables using it not ..

so the new-leader never gets ordered to attack the capturer (being the player)
(the above code is just a part of the whole script)
G

[/EDIT}

[jlehtone]

[halo112358]

[jlehtone]

In sector, the stock formation leadership inheritance definitely does work. I think I've seen this occur OOS too, but not being sure, will recheck. Step one is to know for sure what ints do. When we know that we can point the finger on something.

I would assume that the 26--33 part is a failback. Normal expectation is that the Leader does emit SIGNAL_ATTACKED before it dies. If it does not, it will at least emit SIGNAL_KILLED, and 26--33 in it is supposed to emit that SIGNAL_ATTACKED. Whether that works OOS is another thing.

One of the X2 bonuspack scripts (was it UT or BPH?) did report its killer, even from OOS. No idea how it did that, but overwrite of SIGNAL_KILLED handler seems logical. Has X3 broken something?

Btw, you could log the new leader in the signal-handler. Can one print the current command of it too?

[Cycrow]

i tested the killed signal and seems that killer is always null. The attacked signal returns the correct attacker OOS thou.

so if your looking for a work around, u could try having the SIGNAL ATTACK record the attack as a local varible on the ship, then when the ship is filled and $killer is null, just get this local varible that should be the last attacker.

it might not be 100% acurate, but it'll be better than not working at all

[halo112358]