Join us at the Oolite Anniversary Party -- London, 7th July 2024, 1pm
More details in this thread.

Progress

General discussion for players of Oolite.

Moderators: winston, another_commander

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

Commander McLane wrote:
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().
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Progress

Post by Commander McLane »

Ahruman wrote:
Commander McLane wrote:
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?
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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).
User avatar
Micha
Commodore
Commodore
Posts: 815
Joined: Tue Sep 02, 2008 2:01 pm
Location: London, UK
Contact:

Re: Progress

Post by Micha »

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.
The glass is twice as big as it needs to be.
User avatar
Gimi
---- E L I T E ----
---- E L I T E ----
Posts: 2073
Joined: Tue Aug 29, 2006 5:02 pm
Location: Norway

Re: Progress

Post by Gimi »

Micha wrote:
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).
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6570
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

HUD legends now accept the equipment_required key. This is Berlios Feature Request #5359 now implemented.
User avatar
Wildeblood
---- E L I T E ----
---- E L I T E ----
Posts: 2319
Joined: Sat Jun 11, 2011 6:07 am
Location: Western Australia

Re: Progress

Post by Wildeblood »

Micha wrote:
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?
User avatar
Micha
Commodore
Commodore
Posts: 815
Joined: Tue Sep 02, 2008 2:01 pm
Location: London, UK
Contact:

Re: Progress

Post by Micha »

Wildeblood wrote:
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?
All targets, beacons or otherwise.
The glass is twice as big as it needs to be.
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Re: Progress

Post by Eric Walch »

Gimi wrote:
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.
User avatar
Gimi
---- E L I T E ----
---- E L I T E ----
Posts: 2073
Joined: Tue Aug 29, 2006 5:02 pm
Location: Norway

Re: Progress

Post by Gimi »

Eric Walch wrote:
Gimi wrote:
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).
User avatar
Micha
Commodore
Commodore
Posts: 815
Joined: Tue Sep 02, 2008 2:01 pm
Location: London, UK
Contact:

Re: Progress

Post by Micha »

Yes, the SVN version in trunk should be updated. My oversight.
The glass is twice as big as it needs to be.
User avatar
Selezen
---- E L I T E ----
---- E L I T E ----
Posts: 2527
Joined: Tue Mar 29, 2005 9:14 am
Location: Tionisla
Contact:

Re: Progress

Post by Selezen »

Eric Walch wrote:
Gimi wrote:
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.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6570
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

Selezen wrote:
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.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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.)
m4r35n357
---- E L I T E ----
---- E L I T E ----
Posts: 296
Joined: Wed Jan 19, 2011 4:00 pm

Re: Progress

Post by m4r35n357 »

Ahruman wrote:
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?
Post Reply