P.U.R.E. 0.8 RC3

[Argh]

Dunno, Hoi, I haven't communicated with him for 10 months now.

Ok, I tried disabling the setting that you suggested, and the problem didn't go away. If this helps any, maybe the explanation "too fast" isn't quite accurate. It's more like the camera moves in too big of jumps. I just barely hit the arrow key, and it jumps halfway across the map (on smaller maps)....

What are your system specs? Current recommended minimum specs are a processor running at 1.8Ghz, video hardware no older than a Radeon 9800 and 512MB DDR RAM. Any lower than that, and you should probably expect lousy performance. Sorry, the Spring engine is pretty CPU-intensive, and P.U.R.E. demands a fairly good GPU.

[AF]

New users don't remember the screen resolutions. I remember having to pull up display properties to remind myself what the numbers were, which is the main point. It should be a combo box not a text input.

Either way most users run at 1024x768 and its the default, there are even users who insist on it, so we should design to accommodate.

In the meantime there was work on ctrpanel.txt UI hacks that could help with moving around the command buttons perhaps someone who knows more about this could help correct and implement the suggestions for you?

Either way balancing gets a higher priority in this community despite GUI having a bigger effect on the end user (when I say end user I am not talking about the average spring player, we should design for brand new users who've never been here before).

Argh since you say we should just shut helpomatic off after a while (although the big picture actually serves a useful purpose), perhaps you should make your own version of the googly eyes widget to tell people how to access the widgets menu?

[Pxtl]

Great. When I get a minute and can test it with the PURE RC3 files, I've got a new AppLauncher, then. Only new feature is rollovers for the image buttons, but it's .NET 1.1 instead of 2.0.

[Argh]

New users don't remember the screen resolutions. I remember having to pull up display properties to remind myself what the numbers were, which is the main point. It should be a combo box not a text input.

Talk to koshi, that's not my job.

Either way most users run at 1024x768 and its the default, there are even users who insist on it, so we should design to accommodate.

First off, "we" aren't designing anything. I am. Second off, no, I don't believe that everybody still plays at that resolution in 2008.

In the meantime there was work on ctrpanel.txt UI hacks that could help with moving around the command buttons perhaps someone who knows more about this could help correct and implement the suggestions for you?

The only thing that would really interest me is a wholesale rewrite of the core UI, allowing for dynamic resizing of the buttons and other elements (they are currently at a fixed size, which is why my 1600/1200 screens look great, and 1024/768 looks very cramped. In short, it could be done, but it's a major rewrite of a lot of Trepan's code. I don't have the time to do that, nobody else seems to be interested in doing that, or they are doing it... but in the context of large software that I do not want to integrate with P.U.R.E., such as IceUI, instead of a modular approach like I'm using in P.U.R.E., and none of that work that's available isn't poisoned with GPL.

Sorry, it really just comes down to manpower and coding expertise on that, and I think there are things that are more important to do with my time at the moment.

Argh since you say we should just shut helpomatic off after a while (although the big picture actually serves a useful purpose), perhaps you should make your own version of the googly eyes widget to tell people how to access the widgets menu?

Brief O' Matic discusses Widgets, and how to turn them on/off. Try reading it, maybe. I'm considering making it more detailed, so that it's basically an instruction manual.

Great. When I get a minute and can test it with the PURE RC3 files, I've got a new AppLauncher, then. Only new feature is rollovers for the image buttons, but it's .NET 1.1 instead of 2.0.

Wonderful. If it's around this weekend, it'll go into RC4.

[Peet]

Second off, no, I don't believe that everybody still plays at that resolution in 2008.

Check the current Steam stats. 33%.

[koshi]

New users don't remember the screen resolutions. I remember having to pull up display properties to remind myself what the numbers were, which is the main point. It should be a combo box not a text input.

Talk to koshi, that's not my job.

Yeah, talk to me about how expert mode is for experts that don't know their screen resolution and simple mode provides a, guess what, combobox with predefined resoultions.
A different default that mirrors current desktop resolution is possible ofc, if a) someone gives me a patch for that that works on all plattforms and b) same is implemented engine side as well.

[Pxtl]

Yeah, talk to me about how expert mode is for experts that don't know their screen resolution and simple mode provides a, guess what, combobox with predefined resoultions.
A different default that mirrors current desktop resolution is possible ofc, if a) someone gives me a patch for that that works on all plattforms and b) same is implemented engine side as well.

Can't really blame people for being suspicious of "simple mode" can you? I mean, after frustrating things like units turning into little grey boxes and the grounddecal bug, I'm sure most users stay on expert mode so they can keep an eye on the features that cause bugs.

[Argh]

Yeah, talk to me about how expert mode is for experts that don't know their screen resolution and simple mode provides a, guess what, combobox with predefined resoultions.

Er, sorry, I wasn't trying to imply that you weren't doing a fine job, I'm very sorry if it seemed that way. AF's response seemed to indicate that he wants the expert mode to behave like the simple mode in that respect. I'm saying that since users start in simple mode... where's the problem, exactly?

Check the current Steam stats. 33%.

Ok, let's accept that figure. One-third of the playerbase is at the low end (although people who can run CS:S at 1024 without stutter will be fine in Spring).

The fact is... the main problems with space allocation simply can't be solved without significant sacrifices to quality, or by having a separate-and-not-really-equal solution, such as a completely different UI treatment for players on the low end. I guess I should consider that approach, but I don't think I'm going to be willing to use the time to maintain two different sets of content, for a problem effecting only a third of the potential playerbase which can be fixed by accessing a menu.

That said... maybe one idea I should explore is to use some of the wasted space on the UI to put a button that brings up the Widget menu and adjusts other stuff. That would be simple... and relatively easy.

[koshi]

Yeah, talk to me about how expert mode is for experts that don't know their screen resolution and simple mode provides a, guess what, combobox with predefined resoultions.

Er, sorry, I wasn't trying to imply that you weren't doing a fine job, I'm very sorry if it seemed that way. AF's response seemed to indicate that he wants the expert mode to behave like the simple mode in that respect. I'm saying that since users start in simple mode... where's the problem, exactly?

Heh no worries, that "talk to me" was directed at AF.
I agree, I don't see anything wrong with that behaviour either.

[Argh]

NP, just thought I should make that clear- you've bent over backwards to make the initial user experience easy for this, and I'm getting snippy, it's been a long week.

Ok... gtg, I'll be back on Friday, and around pretty much for the entire weekend, at which point... if everything works out... I'll release RC4.

[Pxtl]

New applauncher. New features include rollover, error logging, and .NET 1.1.

Icon-ripping is lost, it needs a bona-fide icon file for the control-box. To fix your defective icon selection from RC3, use

Code: Select all

IconTarget="PURE_ICON.ico"

also, there are new tags for rollovers.

ExitRolloverImageTarget (for exit button in lists, same as ExitIdleImageTarget but for roll-over)

RolloverImageTarget (for buttons, like IdleImageTarget but for rollover)

Errors are dumped into AppLauncherErrors_yyyy-MM-dd.log, so if anyone reports crashes in AppLauncher, forward their log file my way.

[Google_Frog]

Overmind metal makers still produce M when off.

[Saktoth]

Okay. Wow. Well. Me and google have played some PURE and i dont know if this has been mentioned, or not, or whatever, but, a little feedback.

I take it that the fact its run almost entirely on MM economy is deliberate, in the style of Nanoblobs or Gundam? It hasnt worked very well for those mods so id really reconsider that but if its your design goal for it to run like this then...

Just like nanoblobs it runs like a cow in no time, with hundreds of units on screen at once, only its effects and units are way more CPU burdensome so it does so even earlier and harder.

As for actual bugs though... Metalmakers still make metal while off. And drain no energy. So, they're just free metal. I dont suppose that parts deliberate?

Guncraft do 0.01 damage to default, and some units arent in an armor category, such as radar towers, so they're in default and get 0.01 damage from guncraft, is this deliberate?

[Google_Frog]

Why not remove MM's completely? It plays a lot better without them.

You should really look at your turret costs and think. Laser turrets cost 180m, gun turrets cost 300m. The laser turret is better. Also the resistance gun turret cost 42.

[IllvilJa]

Hello folks!

I were curious about the state of P.U.R.E RC3 so I downloaded the Linux distribution of it, reading the note that it was a bare bone Linux distribution requiring me to rebuild spring. Fine.

I unpacked it in a separate directory and then "cd" down into that directory and looked at the contents.

And from there I am, a bit, lost.

I looked for any 'configure' file to run but no such thing. Neither could I run "scons config" or "scons configure". No README or INSTALL file either. And there were no directory called 'src' or something with any source to build the game from (the download page hinted that spring had to be built from source, and I considered the possibility that the source for spring could happen to be included in the download).

I also tried to copy the LINUX_BUILD_RC3.7z file to the ~/.spring/mods directory but no luck, I could only select P.U.R.E 0.55 in the mod list (which actually is a great version of P.U.R.E as well).

Yes, I did read this thread to find any clues (ok, ok, I perhaps skimmed parts of it).

Also, I do have the Spring source handy (I actually have built and played the game on my linux PC).

Anyone who can provide me some hint on where I can start to get P.U.R.E RC3 running on my laptop machine? Any help is appreciated.

(...and yes, I have a creepy feeling the answer is something easy and obvious...)

[Argh]

@IllvilJa:

Try asking here. Sorry I can't be more help, my knowledge of Linux is basically zero.

[Argh]

And now, for something more cheerful (since this day online seems to have started on the snippy side):

This weekend, I will not be releasing RC4. Why? Because something wonderful is afoot, and I think it's worth spending another week working on it.

Here's a little demonstration of why:






This... is nothing short of revolutionary. World Builder itself, the core concepts, are pretty cool stuff, but this will be changing everything about how we perceive maps and how we build them. Call that hubris if you want, but what you're seeing here took minutes, not hours or days.


I will be releasing an Alpha build of the World Builder Editor, which is what these screens show examples from... this weekend at some point. Please, don't download it, unless you're willing to accept that it's Alpha, and therefore subject to a lot of probably-violent changes over the next week or so, I'm just looking at initial comments.

Also... I have a serious problem with Spring, and I wanted to know if anybody knows the answer to how to get rid of something:

When a Unit is selected, Spring draws the text, "Selected units #". I can't seem to find a reference to this anywhere in Lua, so I'm guessing that this hardcoded as to position and value. Can this get removed or at least turn-offable? If I could get that turned off... I will be able to substantially reduce the footprint of the UI. Any help on this would be greatly appreciated.

[Forboding Angel]

WOW!!!!

Lathans Features!!! YAYZ!!!!

And selected units is hardcoded... I'm in IRC atm and trying to draw some attention to it.


Edit:

[16:44] <Forboding_Angel> Hey backez
[16:44] <Forboding_Angel> Damn, Baczek
[16:44] <Forboding_Angel> You still here?
[16:46] <baczek> aye
[16:46] <Forboding_Angel> Well Darn... "Selected Units" text is currently hardcoded into the engine gui thingy. Could someone look into giving us the possibility to remove it or at lease move it around, pretty up the text, etc etcf?
[16:46] <Forboding_Angel> O you are here, yayz
[16:47] <baczek> will remove it when luaui is enabled
[16:47] <Forboding_Angel> In .77 or currently?
[16:47] <baczek> in a minute or two
[16:47] <Forboding_Angel> Lub u! Where do I send the virgins?

[Saktoth]

Argh, a comment on the balance/bug discussions?

[Argh]

Well, the MM Power drain is obviously a bug, not a feature. As for the rest, I need to digest it for a bit, before saying anything.