QA. A Rant.

[Argh]

How?

I'll be happy to test it and see if that resolves stuff.

[Forboding Angel]

Oh my fucking god. You've been testing with heatmapping on and you're calling us idiots???

heatmapping=false; in the movedefs

9 months ago pathfinding wasn't mature. It was fucking dead in the damn water. Kman made it a billion years ago and no one understood shit about it so everyone left it alone. The fact that it's actually being worked on is a fucking miracle. Perhaps you should get your facts and history straight before you start blasting everyone here based upon assumption and supposition.

[smoth]

ha ha ha oh wow, seriously argh? why didn't you just ask us? Forb was like plastering that to everyone for a LOOOONG time.

[Argh]

We should not have to turn something like that off. If the default behavior is broken, that is a QA problem...

Anyhow, I'll give it a try.

If it works, fine, but that's like shipping Photoshop with an option that makes it impossible to make JPG until you turn off some obscure thing. It doesn't excuse it so much as make it totally incomprehensible.




Still working on the map format, but here's where it's at. Got the fragment shader pretty much ready, and the vertex displacement shader works, but I'm having issues with light- the vertexes seem to be behaving like the geometry hasn't moved, in terms of light. Otherwise seems to be fine. If that means I have to re-light it, oh well, I can just reuse the lighting shader code. I'm too tired to mess with it further tonight.

I could go around that issue over here, but then I won't have something to share.

If you have the skills to help, you know where to find me.

This puppy can already do whatever resolution we want and and it's about ready for the combiner, which will be a lot like the one I wrote for SSMF. Speed isn't going to be a problem.

[Johannes]

Heatmapping is off by default no?

Pathfinding is still much worse than it used to be, also with heatmapping off. If you don't agree you're just wrong.

Pathfinding used to be ok, main downside was the 8-directionness (in lack of a better word) of it as far as I see and I'm sure most players would agree. The current pathing does has not changed that. Well I don't know what it is supposed to improve at all.
It's nice that the pathfinding is worked on, but not when we get forced to play with degenerate versions.

[hoijui]

if you do changes , and end up with something that the majority likes, then it will be used even if all spring devs do not like it. if you are sure you know better how it should be done, then you can be just as sure that your work is not being wasted.
it just looks like you do not even trust yourself.... maybe that work is still not worth it, if a new path finder is already in development...
does something inside you actually have some sense...
?
Hallelujah! praise the lord! for he has planted a corn of sense! glory!!

[Carpenter]

if you do changes , and end up with something that the majority likes, then it will be used even if all spring devs do not like it.

Are you trying to say that some people actually enjoy playing with a bad pathfinding? :D
Ok maybe it got better again since the version where it was totally ruined but I agree here with Johannes, it's not what it used to be.

[hoijui]

that has nothing to do with what i said, which is:
when you give us current release with better path-finder, without other changes, it will be used as eg, in 0.82.7, until there is a better alternative.

[Carpenter]

that has nothing to do with what i said, which is:
when you give us current release with better path-finder, without other changes, it will be used as eg, in 0.82.7, until there is a better alternative.

Oh yes, of course but still, johannes wins. XD

[Forboding Angel]

Johannes needs to just shut up. Repeating himself all over these forums isn't going to help anything.

Hoijui, please have whoever is working on pathing look at Evo. Evo remains largely unaffected by the pathing troubles and that's worth noting.

[smoth]

I don't have any major issues outside of stuff like units sometimes trying to move through areas that are too narrow. I didn't even disable heatmapping.

[Tobi]

It's funny how in the past everyone argued pathfinding sucked, and now that apparently it got worse, it suddenly was good in the past

I could probably write some Lua that would automatically do that part.

By all means, go ahead.

Remember that it preferably needs to have the least amount of human interaction as possible. It should preferably be possible to run it on a headless box (e.g. using spring-headless). It should give a good/bad outcome. It shouldn't require someone carefully analyzing the game to see whether some units got stuck or so. It should be as easy as possible to keep up to date if improvements/API changes are made, otherwise that won't happen. Etc.

And what do you have then? A test that tests maybe 0.1% of the functionality of Spring. It won't test shadows on ATI (not even if it's run & inspected manually by a developer), it won't test sound, it won't test against <random crash X that only happens on Win XP SP 3 with ATI driver 5.67 beta 4>, etc., etc.

I'm not arguing against automated tests but with something like Spring you have to realize how hard it is to get any significant test coverage.

You're really simplifying the problem. The only way something like Spring can be properly tested on a range of hardware is if the community is involved. Not by adding some process here or there. (unless you count releasing a few days before go-live as a process maybe...)

As for the rest of what you've said, Tobi, you've totally skipped around the entire argument.

Nope, I haven't.

I have said why I don't believe some kind of repetitive QA process will ever work [for spring], and I have mentioned solutions that I believe actually would help.

You just need to download a few of them and run a SP scenario for a bit- fire up a map, give each side a few units, give them some orders.

That is exactly why we make the builds available a day up to a week before the final build.

You guys have already broken backwards compatibility twice this year, which means that that vast majority of games downloads on SpringFiles are literally unplayable.

That's by design -- has nothing to do with QA.

You can't tell me that pathfinding doesn't suck, that shadows work on ATi, that sounds aren't obeying their parameters or that turning off map drawing doesn't make a giant difference in FPS.

Indeed we can't, because we don't have ATI and maybe don't have the ears or sound devices or knowledge to even notice sounds aren't obeying their parameters.

Again, I believe testing a piece of software like this can only be done as a community effort, because 2 or 3 developers running a few tests before release as "QA process" will maybe find 0-10% of the bugs present (we've all seen how easy it is for big bugs to slip through.....), while even 10-20 people playing 2-3 games each (with different mods) will probably find 20-30% of the bugs already.

So, if you have the time, organise play tests before release. Preferably try to organise play tests every X time to ensure bugs are found as early as possible before release (like I did years ago...). Then as organiser of those playtests, make sure to hunt down the details about every bug, because most players will just mention the issues in (in-game) chat and then forget about them (at least in my experience.)

I hope I made my point clear now

[Pxtl]

I tend to agree that the big stumbling-block is simply the lobby. Without lobby support, there is no testing.

[zerver]

Exactly how are shadows broken? I have shadows with the 10.4 driver and AtiHacks enabled. Some people reported it working even without AtiHacks using the very latest drivers.

[Argh]

Exactly how are shadows broken? I have shadows with the 10.4 driver and AtiHacks enabled. Some people reported it working even without AtiHacks using the very latest drivers.

They aren't working over here with 10.5, except for ground shadows; if they're working at all for you, then I'll try rolling back to 10.4 or rolling forward to the latest (but I'm afraid to try that because 10.6 broke practically all of my OpenGL applications that I depend on).

Anyhow, seeing as I haven't gotten any PMs about what got broken in the Lambert term when I applied a vertex shader, I'll keep working on the rest of the map shader tonight, as it's close to meeting the goals otherwise, and I think people will be very pleased with what it can do.

On the other stuff about testing, I agree that it can't possibly catch all the bugs, but at least it can identify the major things that are still broken. Right now I feel like we're stuck doing beta-tests, and I'd rather that the dev-->game-dev communication included a test cycle with our games or something, so that you guys know what we're seeing and perhaps we can all be a little more team-like and a little less acrimonious. Right now, I feel like you guys are operating in the dark about what issues we're seeing, and I hate having to yell at you, but nothing else seems to work.

[Gota]

with 10.4 i couldn't play previous spring v at all.

[MidKnight]

Oh, you guys. Stop piddling about already and do something that'll help solve the problem.


The server source is freely available. I'm sure aegis will accept a patch adding test version support if the code's well-written, and if that's in the server, the lobby devs will write for it! Go write it!

Tobi said something interesting about removing the 90% of spring that is useless features! Try it out! Make a fork and release it monthly to moddevs! try and squash bugs and recreate special stuff with Lua. Maybe we'll end up with a much more maintainable engine!

Argh, you are angry about the lack of shadows on ATi software. Blobshadow works and does so much faster than the native spring shadows. Expand that into a full-featured shadow widget!

All of you guys! Try and find time to let the devs use your rigs for testing! Download the latest test spring (if this were more conspicuously available, devs, more people would test it) and report bugs to mantis!


There's so much you guys could be doing to help improve the engine and solve these problems.
Instead, you're arguing.

[aegis]

aegis will accept a patch adding test version support if the code's well-written, and if that's in the server, the lobby devs will write for it!

um
http://cgit.springlobby.info/cgit/aegis ... l.py#n1076

it's not even a matter of well-written - the code to add multiple engine support is so incredibly simple it's been mostly done and commented out in the server for at least a year...
the hardest part (not very hard) would be adding a toggle via compatibility flags.

in fact licho and I talked specifically about it in the last few days and I'm planning on prodding it in the next few days.

[zwzsg]

Tobi said something interesting about removing the 90% of spring that is useless features! Try it out! Make a fork and release it monthly to moddevs!

As I keep saying, replace Spring.exe by a Lua interpreter, or better yet, a readme.txt that says: "Write your own stuff!" and yes, there'll be less engine bugs... but a ton more bug in the mod side of code! So an overall decrease of quality.

[AF]

eh I thought uberserver supported it after I requested optional fields for engine version as well as engine name so I could do glest/TA3D/etc without hackish kludges in AFLobby