Struggling with keys to access all the stuff I need to use

[another_commander]

HDR output mode is enabled only when explicitly requested at launch via the command line. Launching the game normally creates standard 8 bpc backbuffer as it always has been the case.

IMO the issue is that the gfx card is just too old to support the requirements of the new renderer. My initial suggestion would be to drop detail level to Shaders Enabled.

PS: phkb's .GNUstepdefaults edit is not wrong, but the absence of the "hdr" key defaults to NO, so if it is missing HDR is not activated anyway.

[Switeck]

Something to try: can you put

Code: Select all

“hdr” = NO;

into your .GNUstepDefaults file, to see if that clears up the performance issues

Should I use the stylized quotation marks or the simpler " quotation marks?

IMO the issue is that the gfx card is just too old to support the requirements of the new renderer. My initial suggestion would be to drop detail level to Shaders Enabled.

That is what I shall do then.

...Seems to work, and it's not rock-bottom frame rate anymore.

[hiran]

HDR output mode is enabled only when explicitly requested at launch via the command line. Launching the game normally creates standard 8 bpc backbuffer as it always has been the case.

IMO the issue is that the gfx card is just too old to support the requirements of the new renderer. My initial suggestion would be to drop detail level to Shaders Enabled.

PS: phkb's .GNUstepdefaults edit is not wrong, but the absence of the "hdr" key defaults to NO, so if it is missing HDR is not activated anyway.

For quite some time I thought having Oolite log it's command line on startup might be a good idea for troubleshooting based on the logfile.
Would that be a big change in the code?

[another_commander]

For quite some time I thought having Oolite log it's command line on startup might be a good idea for troubleshooting based on the logfile.
Would that be a big change in the code?

Seems quite straightforward. The build containing this is currently cooking.

[hiran]

For quite some time I thought having Oolite log it's command line on startup might be a good idea for troubleshooting based on the logfile.
Would that be a big change in the code?

Seems quite straightforward. The build containing this is currently cooking.

Oh that was quick. Thanks a lot!

[arquebus]

Ok I am losing my mind here, where do I go to set the extra keys?

[phkb]

In the keyboard config screen, where all keys are set.

[arquebus]

In the keyboard config screen, where all keys are set.

My main screen and in-game game options has autosave, docking clearance protocol, sound volume, spoken messages, music, wireframe graphics, graphics detail, field of view, joystick config, view keyboard config, back. The view keyboard config doesn't allow modification. (I'm only able to check this right now on my Mac, which doesn't appear to have a 1.91 build, so maybe there's something else in the 1.91 build? But I don't recall seeing it.)

[hiran]

In the keyboard config screen, where all keys are set.

My main screen and in-game game options has autosave, docking clearance protocol, sound volume, spoken messages, music, wireframe graphics, graphics detail, field of view, joystick config, view keyboard config, back. The view keyboard config doesn't allow modification. (I'm only able to check this right now on my Mac, which doesn't appear to have a 1.91 build, so maybe there's something else in the 1.91 build? But I don't recall seeing it.)

phkb has re-worked keyboard handling into 1.91, and we have not had any release since (note that all the builds on Github are tagged Pre-Release). Today's builds do not cover the Mac, that makes two reasons to not expect it there.

Here is how you can find it:

[phkb]

My main screen and in-game game options has autosave, docking clearance protocol, sound volume, spoken messages, music, wireframe graphics, graphics detail, field of view, joystick config, view keyboard config, back. The view keyboard config doesn't allow modification. (I'm only able to check this right now on my Mac, which doesn't appear to have a 1.91 build, so maybe there's something else in the 1.91 build? But I don't recall seeing it.)

Ah, you're on a Mac, I didn't realise. Unfortunately, we don't currently have a 1.91 build that includes the in game keyboard config. The most recent build we have for 1.91 predates the introduction of it, and we don't have any active Mac maintainers who can produce the package for you. Our Mac build environment is languishing at the moment.

we have not had any release since

Major release, that is. ie 1.92.

[hiran]

we have not had any release since

Major release, that is. ie 1.92.

Interesting. I am open to adjust my wording but would like to have some consistency.
If you call 1.92 a major release, what would you name 2.0? And what do we call the artifacts that get built currently?

[phkb]

If you call 1.92 a major release, what would you name 2.0? And what do we call the artifacts that get built currently?

In this environment, ie Oolite, my opinion is that 1.92 will be a "major" release, in that it will be the one published to the website, the version which will receive dev support, and the one we recommend to new players. And given how long it will have taken us to get there, it will definitely be a major release. My use of "major" reflects the content, rather than the number.

The artifacts being released against "Trunk", which currently all have a version of 1.91, are pre-release versions.

[hiran]

If you call 1.92 a major release, what would you name 2.0? And what do we call the artifacts that get built currently?

In this environment, ie Oolite, my opinion is that 1.92 will be a "major" release, in that it will be the one published to the website, the version which will receive dev support, and the one we recommend to new players. And given how long it will have taken us to get there, it will definitely be a major release. My use of "major" reflects the content, rather than the number.

The artifacts being released against "Trunk", which currently all have a version of 1.91, are pre-release versions.

Aye, then a major release it shall be.

[arquebus]

Ah, you're on a Mac, I didn't realise. Unfortunately, we don't currently have a 1.91 build that includes the in game keyboard config. The most recent build we have for 1.91 predates the introduction of it, and we don't have any active Mac maintainers who can produce the package for you. Our Mac build environment is languishing at the moment.

I'm not on a Mac, only on a Mac when I'm away from home - my gaming rig is a Windows PC.

I think the problem is that I had a really old build of 1.91. (I hate Github, it's so counterintuitive.)

[hiran]

I think the problem is that I had a really old build of 1.91. (I hate Github, it's so counterintuitive.)

I understand that a 1.91 is not comparable to a newer 1.91 or the latest 1.91 or even the older 1.91.
That's why I placed full version numbers on all artifacts that you can download. With that you can download them all, drop them in the same directory and still can tell one from the other.

If we had semantic versioning it would be even easier for humans to compare older and newer version. But well, we have what we have.
This (conter) intuitive stuff is not Github but the way we use it.