P.U.R.E. RC4.2

[Argh]

How can that possibly desync you? Can you give more details?

Well, I know for a fact that people with faster computers are literally in the sim and playing before other people have caught up. I've observed that with DRB, with two machines in the same room.

If they're delayed enough, I think that causes a sync error due to timeout. Best guess atm, I haven't the foggiest how all of that works.

Also KingRaptor reported that uninstalling pure broke his spring install.

The full installer's basically a complete install of Spring. I wouldn't be telling people to install it, if the "bare bones" was syncing with the full installs, but they don't sync- see my post in Dev about that set of issues.

If he installed it to the same directory... yeah, it'll do that. There are other issues there- UnitSync / SpringSettings seems to assume that Spring's only installed in one place.

[lurker]

Springsettings works fine here with multiple installs, they just share settings.

Shouldn't the uninstaller remember what it installed better? Oh well.

So you mean delayed sync and timeouts, not an actual sync error. Wait, that gives me a very bad idea of what you mean about the next spring. Please tell me you're not playing the sounds out of the archive; that means every single music file will have to be held in ram. But if it's an issue to extract the files, and it's already a big waste to extract them every game anyway, why don't you use lua to extract more slowly, or keep the same method but stagger the extractions a bit, or at the very least check if the files have already been extracted before you extract again?

[Argh]

Please tell me you're not playing the sounds out of the archive;

I can't play them out of the archive, that functionality isn't even available yet.

Shouldn't the uninstaller remember what it installed better?

It remembers just fine... it's just that it's a complete install of Spring, including the engine.

at the very least keep it the same method but stagger the extractions a bit?

I'll certainly try that, and delay the music a bit later.

But if it's done at game-start, shouldn't all clients be waiting for each other to finish that before trying to proceed?

Mainly, I think that this problem is pointing to something I've brought up time and again- Spring should have better support for pre-loading assets into RAM, period. 120MB for the music files (or less, if I randomly only selected say, 6 of them per game-state) is not a big deal these days, unless your hardware is truly ancient.

[lurker]

Please tell me you're not playing the sounds out of the archive;

I can't play them out of the archive, that functionality isn't even available yet.

I was referring to

This is a problem related to unpacking large files from an archive, and will not be resolved until the next version of Spring is delivered.

They wait for each other for loading, but you still have to send out response packets every so often, and extremely slow file extraction may or may not interfere.


And when the installer 'installs' a file with an identical copy, the uninstaller shouldn't delete that file, but it's not like I expect that level of care from any real-world installer.

[Auswaschbar]

So you mean delayed sync and timeouts, not an actual sync error. Wait, that gives me a very bad idea of what you mean about the next spring. Please tell me you're not playing the sounds out of the archive; that means every single music file will have to be held in ram. But if it's an issue to extract the files, and it's already a big waste to extract them every game anyway, why don't you use lua to extract more slowly, or keep the same method but stagger the extractions a bit, or at the very least check if the files have already been extracted before you extract again?

No, next spring version can STREAM music out of a content archive. The amount of RAM used is almost equal compared to playback of a real file.

[lurker]

It can do both streaming and normal sounds out of an archive? Good, happy for all. I was thinking about the normal sounds feature and probably mixed it up a bit, sorry.

Argh, would you like me to build you a 78.2 with that capability?

[Argh]

Argh, would you like me to build you a 78.2 with that capability?

If they can be in the regular Lobby, yes, because then I can also deploy some of the other new tech.

[Forboding Angel]

Argh, if you keep having trouble, I can mirror the file(s) for you if you want.

[rattle]

Look! Fanart!

[zwzsg]

Leaving a 404 in the download link of the release thread is not good publicity.

[smartie]

world builder is really impressive. I played around with it for about an hour building a city. Nice work.

[Hoi]

Bug: when you try to build the goverment building or the appartment on the left of the buildpic of the goverment building it doesn't work, I don't know what's causing it, but maybe the footprint of those buildings is too big for the buildrange of the unit which builds the stuff.

It's very cool though and pure has improved a lot since RC3, the only thing missing is a superunit for resistance!

[Andromeda]

The Resistance doesn't need a superunit

[Noruas]

Although i stilll hate the majority of this mod, i will say you are on the right path to destruction.

[zwzsg]

I don't know what you did there, but on my computer Pure has like one frame per 20s. And show "game over" a couple frame after game start. Then I tried with LuaUI off and at 640x480, same.

Only error I found in infolog was:
[ 0] error = 2, LuaRules/draw.lua, error = 2, LuaGadgets/gadgets.lua, [string "LuaRules/Gadgets/glsl_lighting.lua"]:43: attempt to call field 'CreateShader' (a nil value)

[Argh]

What video hardware were you trying to run it on?

[zwzsg]

A video hardware that can run every other Spring mod fine:

OS: Microsoft Windows 2000 Professional Service Pack 4 (build 2195)
Hardware: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+; 2047MB RAM, 3938MB pagefile
Video mode set to 640 x 480 / 32 bit
[ 0] SDL: 1.2.10
[ 0] GL: 2.0.5646 Win2000 Release
[ 0] GL: ATI Technologies Inc.
[ 0] GL: Radeon X1900 Series x86/MMX/3DNow!/SSE2
[ 0] GLEW: 1.4.0

I tried deleting every gadgets of PURE_CORE.sdz, still uberlag.

[Argh]

If every Gadget's gone, so is the GLSL, so it's not that.

[Argh]

Ok, we're pretty sure the bugs are fixed, and that the bare-bones build will now sync with the full installer, Google's Widgets are all available, etc., etc.

The UI stuff (i.e., larger buttons) and doing something about buildings on the Minimap isn't finished yet, but that's a small patch, and it can wait.

I'm going to upload new versions of the bare-bones and the full installer, post to ModDB, you know the story.

Changelog:

1. All Resistance MultiTrucks cost more.
2. Artillery Shells cost more, and have slightly lower DPS.
3. Crash bug appears to be resolved.
4. You can now use Choose Position, and be assured that your units won't get stuck on buildings.
5. Mesa City (the "pro" map) has been rebalanced a little, so that the southern flank works better for the south-east corner.
6. Music's been yanked out of the installer, so that load times are closer to par for all players in a MP game. The music will still play- see the instructions included in the archive, if installing bare-bones.
7. Google_Frog's collection of helpful Widgets has been included. They are disabled by default. Use F11 to activate, etc.

That's it for now, the UI stuff will get addressed in a future patch, along with any balance changes that seem to be necessary, some improvements I have planned for World Builder, etc., but that will take several days, and I think that it's finally ready for prime-time and a formal release announcement on ModDB, unless serious bugs are found. We'll worry about the compiled 78.2 in a future version, I want to use a lot of the major features but I think it's more important to get the build circulating and talk it up.

[Eman]

Might post direct links...