Death Comms OXP
Moderators: winston, another_commander
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4830
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Death Comms OXP
Not sure if this has been done before, but here's a little OXP to add a bit of comms flavour to battles. Essentially, this OXP will occasionally transmit a final comms message from a ship that is exploding, kind of like a death cry. Things like "Oh no!", or "Aieeee!", that sort of thing. Only standard ships (no police or Thargoids).
Comments and suggestions welcome!
Download OXZ version 1.3 here: DeathComms.oxz
Also available via the download manager.
Comments and suggestions welcome!
Download OXZ version 1.3 here: DeathComms.oxz
Also available via the download manager.
Last edited by phkb on Thu Sep 10, 2015 7:15 am, edited 4 times in total.
- Diziet Sma
- ---- E L I T E ----
- Posts: 6312
- Joined: Mon Apr 06, 2009 12:20 pm
- Location: Aboard the Pitviper S.E. "Blackwidow"
Re: Death Comms OXP
Great idea!
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
Re: Death Comms OXP
I'm really new to javascript, but doesn't this override existing shipDied functions?
Code: Select all
ship.script.shipDied = this.$shipDied;
Re: Death Comms OXP
"Do you have any famous last words!?"
"Not yet."
"...is that famous?"
Very fun idea, I look forward to seeing this in action.
"Not yet."
"...is that famous?"
Very fun idea, I look forward to seeing this in action.
Reports of my death have been greatly underestimated.
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4830
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Death Comms OXP
Yeah, I'll add a bit of protection for the next version.popsch wrote:but doesn't this override existing shipDied functions?
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4830
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Death Comms OXP
OK, version 1.1 should address the issues raised popsch. It should play nice with other OXP's now. Link in the first post.
Re: Death Comms OXP
It's a very nice idea. Now still, doesn't that break all OXPs that also use this.shipKilledOther? Maybe I misunderstand something about how the callback system is working in Oolite: does it permit only one callback, or is it a list of callbacks?
If it's only one callback, then other OXPs such as exhibition or your own GalCopAdminServices won't work anymore.
A really necessary extension for Oolite would be to change the callbacks to support lists of callbacks, in the same way that many other systems and languages support registering event handlers.
If it's only one callback, then other OXPs such as exhibition or your own GalCopAdminServices won't work anymore.
A really necessary extension for Oolite would be to change the callbacks to support lists of callbacks, in the same way that many other systems and languages support registering event handlers.
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4830
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Death Comms OXP
Not really. I'm using two different methods to determine when a ship is destroyed: method 1 for when a ship is destroyed by an NPC, and method 2 for when a ship is destroyed by the player.popsch wrote:doesn't that break all OXPs that also use this.shipKilledOther?
For method 1, I'm attempting to attached my script to the "
shipKilledOther
" event of all NPC ships, but only when there is no existing script in place. If there's something there already, I'm not changing anything. For method 2, I'm defining a global "
shipKilledOther
" function, which all OXP's can define, which is called for when the player kills another ship. When the player destroys a ship, every OXP that has a "shipKilledOther
" function defined will be called, GalCopAdminServices included. You raise an interesting question, though. If two OXP's want to utilise the same event on an NPC ship, how do you attach your script to it without overwriting the previous one? Doing a "
ship.script.shipKilledOther += this.myfunctionname;
" certainly doesn't work (I just tested it).Re: Death Comms OXP
Something like thisphkb wrote:You raise an interesting question, though. If two OXP's want to utilise the same event on an NPC ship, how do you attach your script to it without overwriting the previous one? Doing a "ship.script.shipKilledOther += this.myfunctionname;
" certainly doesn't work (I just tested it).
Code: Select all
if (ship.script.shipKilledOther) {
ship.script.$myoxp_old_shipKilledOther = ship.script.shipKilledOther;
}
ship.script.shipKilledOther = function(parameter) {
// your code goes here
if (this.$myoxp_old_shipKilledOther) {
this.$myoxp_old_shipKilledOther(parameter)
}
}
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4830
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Death Comms OXP
Thanks, cim, that's brilliant! Version 1.2 now up which reverts back to using thecim wrote:Something like this {snip}
shipDied
event, and (I think) will be fully compatible with other OXP's that use shipDied
.Re: Death Comms OXP
Sidenote: Monkey patches are evil and usually the last resort. If you can avoid it.
Races, clashes between patches, overhead and completely uncontrollable runtime behaviour is really not such a good thing.
Oh, and if your code does not modify properties/values in the patched script call the other code before your own.
Races, clashes between patches, overhead and completely uncontrollable runtime behaviour is really not such a good thing.
Oh, and if your code does not modify properties/values in the patched script call the other code before your own.
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4830
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Death Comms OXP
Thanks Svengali! Now I know what a Monkey patch actually is!
I can see how they might be problematic, but in these sorts of cases where you want to utilise the same ship event as another OXP, what options are there? Other than not using the events in the first place, I mean.
I can see how they might be problematic, but in these sorts of cases where you want to utilise the same ship event as another OXP, what options are there? Other than not using the events in the first place, I mean.
Re: Death Comms OXP
Personally I think there is only one 'clean' way for OXP/OXZ content.phkb wrote:I can see how they might be problematic, but in these sorts of cases where you want to utilise the same ship event as another OXP, what options are there? Other than not using the events in the first place, I mean.
Offer the option to be used by other AddOns, e.g. via
script_info
keys or script properties, un-/registering functionality or direct calls. The other way round ('tell/flag if you want to be excluded') does not work unless all other AddOns create code/flags for features they are not interested in. This doesn't make sense.I'm fully aware that 'global mechanisms' like Random Ship Names wouldn't do anything this way for OXP content unless flagged / invoked, but races, clashes or timeouts caused by modified content is a nightmare. Another advantage would be that concurrent AddOns can safely be installed at the same time. In the end it's a question if we think that users can know every little detail of the things 'under the hood' or if authors finally do start being responsible.
For Oolites native entities there's no real way and I guess patching is the only real option.
Here you are on your own to determine if you can safely modify or not. Clashes are unavoidable unless this community starts looking for solutions. All in all it's a difficult question. Performing lots of checks in
.shipSpawned()
is a time eater par excellence while not checking anything is simply asking for trouble.- phkb
- Impressively Grand Sub-Admiral
- Posts: 4830
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Death Comms OXP
I can tell you've had a bit of experience in the "nightmare" of Monkey patching... thank you for your thoughts on it. It would be good to have a core-design solution that would circumvent the need for monkey-patching, even working in a similar way to the player-centric global events would be nice.
In the interim, I'll add more documentation for this OXP that a monkey patch is in use so future OXP's will know what to expect.
In the interim, I'll add more documentation for this OXP that a monkey patch is in use so future OXP's will know what to expect.
Re: Death Comms OXP
As I mentioned before, it would be good for Oolite to have a solid solution for the problem, otherwise compatibility between OXPs will become even more an issue than it is now. The monkey patch is a possible approach, but why not internalize this in Oolite by registering and de-registering listeners for events? The concept of event listeners is quite widely used in many languages and frameworks through the observer pattern: https://en.wikipedia.org/wiki/Observer_pattern