What will be the practical difference to shipDied() for scripting purposes?
“regardless of what happened to it” – a ship can end its existence in at least three ways: by dying (including remove(), which is currently implemented as an explosion without special effects), by jumping and not being followed by the player, or by staying behind when the player jumps.
Commander McLane wrote:
I understand that entityDestroyed() will trigger earlier.
No, later. The ship is still valid (i.e., isValid is true and other properties are accessible) in shipDied().
What will be the practical difference to shipDied() for scripting purposes?
“regardless of what happened to it” – a ship can end its existence in at least three ways: by dying (including remove(), which is currently implemented as an explosion without special effects), by jumping and not being followed by the player, or by staying behind when the player jumps.
Could we find another nomer, then? In the non-dying cases "destroyed" is counter-intuitive for me. When reading your post I automatically associated it with being, well, actively destroyed by something. For instance we have shipDestroyedTarget(), which clearly only means the explosion case.
As it fires immediately after the ship becomes invalid, what about becomesInvalid() or becameInvalid() as a name?
A while back, we modified NPC ships to use equipment items in roughly the same way as the player. Because of the unfortunate naming, the has_energy_bomb shipdata key – which actually refers to Q-bombs – was implementing as adding EQ_ENERGY_BOMB instead of EQ_QC_MINE. The corresponding test also used EQ_ENERGY_BOMB, but testing for or adding Q-bombs with scripts didn’t work. This is fixed in r4491.
A side effect of this is that NPC Q-mines added with has_energy_bomb now take up a missile slot. To deal with this, if a ship has a non-zero has_energy_bomb value, does not explicitly set max_missiles, and missiles is less than 32, the missile capacity is increased by one (even if has_energy_bomb is fractional and the roll fails).
Moving on from the now-no-longer-MNSR (aka, 1.76), and moving onto the Next Unstable Release (aka 1.77 (WiP)):
* Reverse Advanced Compass Controls:
The '|' key (ie, Shift-\ on US/UK keyboards) now moves backwards through the list of beacons. This key can be remapped, as per usual.
Moving on from the now-no-longer-MNSR (aka, 1.76), and moving onto the Next Unstable Release (aka 1.77 (WiP)):
* Reverse Advanced Compass Controls:
The '|' key (ie, Shift-\ on US/UK keyboards) now moves backwards through the list of beacons. This key can be remapped, as per usual.
Saw the change in the change log at Berlios. I guess the Oolite Reference Sheet needs updating then.
"A brilliant game of blasting and trading... Truly a mega-game... The game of a lifetime." (Gold Medal Award, Zzap!64 May 1985).
Moving on from the now-no-longer-MNSR (aka, 1.76), and moving onto the Next Unstable Release (aka 1.77 (WiP)):
* Reverse Advanced Compass Controls:
The '|' key (ie, Shift-\ on US/UK keyboards) now moves backwards through the list of beacons. This key can be remapped, as per usual.
What about when it's not in beacons mode? Do you mean moves backwards through the list of possible compass targets, or just the list of beacons?
Saw the change in the change log at Berlios. I guess the Oolite Reference Sheet needs updating then.
I think we need to be careful with updating documentation. Now we have an official stable release, I think the Reference sheet should only document the 1.76 version. Same for the wiki.
Post 1.76 changes should probably only be documented in the wiki in footnotes for some time and not between the current documentation of the stable release.
Saw the change in the change log at Berlios. I guess the Oolite Reference Sheet needs updating then.
I think we need to be careful with updating documentation. Now we have an official stable release, I think the Reference sheet should only document the 1.76 version. Same for the wiki.
Post 1.76 changes should probably only be documented in the wiki in footnotes for some time and not between the current documentation of the stable release.
No problem with this, but the documentation that you check out via SVN could be updated, as that has no impact on what has already been included in 1.76, or am I wrong? I have already updated my local copy, as I was finishing my Oolite keyboard map and had it open.
"A brilliant game of blasting and trading... Truly a mega-game... The game of a lifetime." (Gold Medal Award, Zzap!64 May 1985).
Saw the change in the change log at Berlios. I guess the Oolite Reference Sheet needs updating then.
I think we need to be careful with updating documentation. Now we have an official stable release, I think the Reference sheet should only document the 1.76 version. Same for the wiki.
Post 1.76 changes should probably only be documented in the wiki in footnotes for some time and not between the current documentation of the stable release.
Would it not be an idea to include the documentation in the source code? The reference sheet would then have an "official" release version that would be in line with the actual application.
At my workplace I tend to include the documentation in the version control system for any project.
Would it not be an idea to include the documentation in the source code? The reference sheet would then have an "official" release version that would be in line with the actual application.
At my workplace I tend to include the documentation in the version control system for any project.
This is what we are currently doing. The reference sheet is part of the source code tree.
As of tonight’s nightly, the energy bomb is once again disabled and will be compensated with a Q-bomb or 900 credits (the cost of an energy bomb). It is currently possible to reenable it by editing equipment.plist, but this may change before the next stable release.
(As with all feature changes, this won’t affect any 1.76.x bug-fix release.)
It is currently possible to reenable it by editing equipment.plist, but this may change before the next stable release.
Disclaimer noted, but to me this really seems like a step too far, a real middle digit to Elite. Is this subject to
debate, or is 1.76 going to be the last version where it is possible to do all the things we could do in Elite?
