Future plans for Oolite 1.x

[another_commander]

I am a little puzzled by some of this, specifically the suggestion that HUD removal and the ability to take a screenshot could be removed. At first glance these are very negative steps, and I don't see the logic behind them.

Guys, we are already working on them. As far as we can see, screenshots will be re-inserted in Deployment and HUD hiding also. Disabled screenshots is a regression bug and HUD hiding is now almost a standardized feature. Remember that the Test Release configuration (which is the only one currently in existence) has all this included and enabled anyway.

[Cody]

screenshots will be re-inserted in Deployment and HUD hiding also. Disabled screenshots is a regression bug and HUD hiding is now almost a standardized feature.

Music to my ears, and not just from the screenshot angle... I've recently taken to hiding the hud during combat, and often whilst cruising.

[Smivs]

Thanks for that. So can we take it that both features will be in the MNSR then?

[Disembodied]

use of injectors is optional, you do get my point about optional/configurable stuff? FWIW, I don't have docking computers installed, and I find it improves my enjoyment of the game greatly, but I wouldn't presume to remove that option for others . . . .

Yes, I get your point, but this isn't some optional piece of kit, like a docking computer or injectors – it's a core game mechanic. Personally I don't think offering game-mechanic options are helpful: I think it's better to make the game work right in one way instead of trying to keep different options open and ending up with a bodged compromise. Having lots of options within the game is great; having lots of options about the way the game itself functions is virtually impossible to do well.

A properly functioning TAF would be very similar to a Torus anyway – except that players who wanted to could choose to scoot through masslocks (or they could poke along and sightsee if they preferred). It would also prevent the player from magically being able to hunt down enemies who are trying to flee on injectors, or from being able to magically escape a pursuer if they manage to get outside scanner range. For my part, because a properly functioning TAF would do everything the Torus is mean to do (i.e. cut out the boring parts of flying between the witchpoint and the station) AND offer other gameplay advantages too, I don't see the point in keeping both systems. I have personal objections to the "Stardreamer" technobabble, but I'd be happy with some other brand of handwavium to explain it all away.

Again, though, I would stress that this would, in my opinion, only be doable in a new, entirely hypothetical version of the game, a new edition of Oolite (like another_commander says, "Torus is not to be touched for Oolite 1.x, regardless of build configuration") – and to be honest if such a new edition were to be on the cards there are other bits of game mechanic, e.g. concerning trading and exploration, which I'd prefer to see changed first.

[Cody]

if such a new edition were to be on the cards there are other bits of game mechanic, e.g. concerning trading and exploration, which I'd prefer to see changed first.

Aye, I'll second that!

[Switeck]

Considering how coarse-grained keyboard control is, I sometimes have to slow the game down to x0.5 or even x0.25 to hit much of anything. If TAF is to be removed, then it would be nice if the keyboard gained a fine aiming control mode like the joystick (and mouse?) already has. As it is, the Adder and similar ships are too "twitchy" for me to snipe with.

[Fatleaf]

I hope this thread doesn't become a 'wish list' for every desire that can be thought up. I fear that is one of the reasons the SGA wanted a break. Too many wants and it brassed him off. A clean up and a few already sensible features that enhance the game would be great. But for my thoughts I would vote to keep the torus and the news of the screen shot feature is staying is all I would like to hear.

And a big thanks to all the Dev team for providing a great game and a great community that surrounds it.

[Capt. Murphy]

......... and, most importantly, the project is without a leader. My idea and proposal at this stage is to close any pending issues that can be closed in the time we have left and publish a final stable version in Test Release mode, same as what we've always had, before the end of the year.

As I said, consider this my personal point of view. It is not intended as a guideline or an official plan. It is just what I think is reasonable, given the circumstances and the present availability of the developers, which is unfortunately limited at this stage.

Sounds like a good plan though.....it's sad to see development in a bit of a no-mans land - so close to a MNSR, but not quite there. Good luck to the Dev Team...

[Thargoid]

I'd firstly probably better apologise for triggering the thread topic again.

My own personal view is that there seems to be a little bit of a build-up of "post-MNSR" ideas and requests which could be done fairly quickly (indeed some I think are already coded but "switched off" at the moment). Mainly due to the 1.76 release plan getting stretched out and delayed longer than originally conceived iirc.

So perhaps a 1.75.4 release may be worthwhile to catch things up and as a milestone for freezing (again) to be an intensively playtested release that will then become 1.76 once all bugs are fixed or at least identified. That way we can get a 1.76 release that won't immediately be followed by 1.76.1 with all of those new features etc.

That said of course it needs the dev team to have both the time and the desire to push through such a plan, which is the key point that has brought us to this stage anyway. So the decision should be from them alone - we players and supporters shouldn't be trying to force anything to happen against their willingness to do it.

[Eric Walch]

I'd firstly probably better apologise for triggering the thread topic again.

No problem at all. This whole thing made me realizing that when the current trunk is fool proof, a compile in a slightly faster deployment version could introduce new bugs because of leaving out some 'debugging' code that is actual needed. Although, going through the majority of the switches, I think the two that now surfaced are probably the only ones.
For my part was it this week the first time I ever compiled Oolite in deployment mode. And because you miss all the nice debugging tools in deployment, I doubt if any of the other developers has played a deployment version for prolonged time. I will now start, but I almost feel naked, not being able to probe other ships or even cheat by using the console

Shift-8 was a full-blown feature in 1.65, so this is indeed a regression bug!
...
I've got a couple of other fixes waiting to be committed, I'll see if I can fix this (and the hud one) in the next hour or so...

I see you fixed this nicely in the current nighty. And also the addition of the 'o' key to the keyConfig list so that this hud key becomes user configurable like any other key. (I just updated the wiki with this)