Planning for 0.77 Release
Moderator: Moderators
Re: Planning for 0.77 Release
Hey... as much as I know it's hosing me... do not release before the sync errors are fixed.
Finding the sync errors is much more important than rushing this for my sake.
I hate saying that... I'm probably going to regret saying that... but don't release a broken product because of me, please. I didn't have any choice but to release, people, and it's probably going to haunt me, but it's done and that's all there is to it. That said... if, perchance, that error got fixed before the 26th of this month... that could be a giant thing.
Also, I've spoken with Koshi, and the errors with SpringLobby are being addressed, as soon as the Installer is updated. Making sure that the Installer is up-to-date, and isn't missing files, etc... that is very important to what I'm doing, frankly. Can't put out releases if everything's broken on arrival- things like that Tips file are a big deal, wasting a lot of my time.
Finding the sync errors is much more important than rushing this for my sake.
I hate saying that... I'm probably going to regret saying that... but don't release a broken product because of me, please. I didn't have any choice but to release, people, and it's probably going to haunt me, but it's done and that's all there is to it. That said... if, perchance, that error got fixed before the 26th of this month... that could be a giant thing.
Also, I've spoken with Koshi, and the errors with SpringLobby are being addressed, as soon as the Installer is updated. Making sure that the Installer is up-to-date, and isn't missing files, etc... that is very important to what I'm doing, frankly. Can't put out releases if everything's broken on arrival- things like that Tips file are a big deal, wasting a lot of my time.
Re: Planning for 0.77 Release
we won't release a game that desyncs since we can't play it - and that's what we're here for in the end, right?
Re: Planning for 0.77 Release
Exactly. Players first.
- clericvash
- Posts: 1394
- Joined: 05 Oct 2004, 01:05
Re: Planning for 0.77 Release
I hate to point it out but it's just common sense, the whole point of spring is to play, it won't get released unless it works, your sake or not.Argh wrote:Exactly. Players first.
Re: Planning for 0.77 Release
I found a few more issues with Registry stuff.
Turn off the following, please:
"Show In-Game Clock"
"Show In-Game Player Information"
"Team-colored NanoSpray" (which, btw, OVERRIDES CUSTOM COLORS)
"Use Hardware Cursor"
None of that should be ON by default. Most games / mods are coming with Widgets that do these jobs, or get broken in various ways by these things. And "Use Hardware Cursor" causes the cursor to not draw at all, for a lot of Vista users.
"Reflective Units" is OFF, despite the fact that pretty much trashes all of the advanced shaders.
Turn it ON by default... the percentage of users whose machines can't handle reflections is low, and is shrinking rapidly.
Terrain Detail is set to 80. If the objective of these settings was to help users with low FPS (hence the above) then this is really counterproductive- that setting is, in all of my rendering tests, the single-largest drain on FPS, besides the more exotic water settings. Seriously... the FPS difference between 80 and 32 is HUGE.
I'd say... go to 64, turn reflections ON, so that our shiny new video games no longer look like they were made 5 years ago...
Sorry if this seems like pointless moaning, it's just that this is all stuff that just looks like it wasn't really ever picked over by anybody in detail.
For now, I'll just use my installer to write custom data to the Registry, to deal with all of this stuff. I'm amazed that I didn't hear tons of complaints about how crappy everything was, frankly...
Turn off the following, please:
"Show In-Game Clock"
"Show In-Game Player Information"
"Team-colored NanoSpray" (which, btw, OVERRIDES CUSTOM COLORS)
"Use Hardware Cursor"
None of that should be ON by default. Most games / mods are coming with Widgets that do these jobs, or get broken in various ways by these things. And "Use Hardware Cursor" causes the cursor to not draw at all, for a lot of Vista users.
"Reflective Units" is OFF, despite the fact that pretty much trashes all of the advanced shaders.
Turn it ON by default... the percentage of users whose machines can't handle reflections is low, and is shrinking rapidly.
Terrain Detail is set to 80. If the objective of these settings was to help users with low FPS (hence the above) then this is really counterproductive- that setting is, in all of my rendering tests, the single-largest drain on FPS, besides the more exotic water settings. Seriously... the FPS difference between 80 and 32 is HUGE.
I'd say... go to 64, turn reflections ON, so that our shiny new video games no longer look like they were made 5 years ago...
Sorry if this seems like pointless moaning, it's just that this is all stuff that just looks like it wasn't really ever picked over by anybody in detail.
For now, I'll just use my installer to write custom data to the Registry, to deal with all of this stuff. I'm amazed that I didn't hear tons of complaints about how crappy everything was, frankly...
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: Planning for 0.77 Release
I already told you and I just rechecked that:Argh wrote:Turn off the following, please:
"Show In-Game Clock"
"Show In-Game Player Information"
"Team-colored NanoSpray" (which, btw, OVERRIDES CUSTOM COLORS)
"Use Hardware Cursor"
ShowFPS,
HardwareCursor and
TeamNanoSpray
are OFF by default. ShowClock is ON indeed.
Re: Planning for 0.77 Release
Delete all your Registry keys in the SJ branch, and do a clean install of a SVN build.
I'm not making this up, though. I've tested here under Windows XP Pro many times- the first time you install, those are the settings you get in SpringSettings before running Spring for the first time, therefore they are the UnitSync defaults.
Oh... wait... you're saying that UnitSync may be what's wrong... Fine, fine... but either way, it's a problem, on a brand-new install
I'm not making this up, though. I've tested here under Windows XP Pro many times- the first time you install, those are the settings you get in SpringSettings before running Spring for the first time, therefore they are the UnitSync defaults.
Oh... wait... you're saying that UnitSync may be what's wrong... Fine, fine... but either way, it's a problem, on a brand-new install

Re: Planning for 0.77 Release
let the installer remove the keys that changed from 0.76 before writhing them?
Re: Planning for 0.77 Release
UnitSync doesn't even know which settings are used by the engine, so it can't have any defaults for those.Argh wrote:Delete all your Registry keys in the SJ branch, and do a clean install of a SVN build.
I'm not making this up, though. I've tested here under Windows XP Pro many times- the first time you install, those are the settings you get in SpringSettings before running Spring for the first time, therefore they are the UnitSync defaults.
Oh... wait... you're saying that UnitSync may be what's wrong... Fine, fine... but either way, it's a problem, on a brand-new install
Your requests have to go to koshi -> SpringSettings is a seperate app, not written by the engine devs.
Re: Planning for 0.77 Release
But Koshi said it was reading from UnitSync... er... but what about that first time, when there aren't any Registry entries yet?
Re: Planning for 0.77 Release
That first time values are determined by defaults i provide from SpringSettings, that's why i keep asking for sane defaults all the time. Sorry if i said anything misleading on that part.
Now, I could go and change those defaults, but i won't maintain diff branches just for diff defaults. So anything I change will be for everyone/thing. If that's cool with good. If not, please find some consensus.
Please also note that only values are set to defaults that actually have UI elements.
Btw: How's the move to fileconfig on windows coming?
Now, I could go and change those defaults, but i won't maintain diff branches just for diff defaults. So anything I change will be for everyone/thing. If that's cool with good. If not, please find some consensus.
Please also note that only values are set to defaults that actually have UI elements.
Btw: How's the move to fileconfig on windows coming?
Re: Planning for 0.77 Release
No, I'm sure I just misunderstood... I'm trying to cram a little too much into what passes for my brain this week.Sorry if i said anything misleading on that part.
At any rate... here would be my feeling about defaults:
Re: Planning for 0.77 Release
ground decals can be set to 1.
Re: Planning for 0.77 Release
Oh yeah, forgot that was fixed and runs fast.
Re: Planning for 0.77 Release
never use 16bit zbuffer! it isn't faster at all. so most gfx don't support 16bit texture formats, instead they still save it as 32bit, but only using 16bit!
And it cause ulgy artefacts with BumpWater and BumpWaterUseDepthTexture=true cuz of the missing precision.
And it cause ulgy artefacts with BumpWater and BumpWaterUseDepthTexture=true cuz of the missing precision.
Re: Planning for 0.77 Release
I thought that some users of ATi cards had trouble if it wasn't set to 16...
Re: Planning for 0.77 Release
AFAIK ATi only sucks with depth textures, but they should support 24- and 32-bit renderbuffer objects.
Re: Planning for 0.77 Release
r6443 (minor installer change) should be ported to 0.77 branch.
Auswaschbar, should I do this or do you rather do it yourself? (to keep better track of what goes in and what not etc.)
Auswaschbar, should I do this or do you rather do it yourself? (to keep better track of what goes in and what not etc.)
Re: Planning for 0.77 Release
So, whats the status about 0.77 ??
Re: Planning for 0.77 Release
Last I heard there is a massive issue with large games and spring freaking out.