List of exploits still open

[YokoZar]

Cloaked metal extractors still show red circles for metal usage when hitting f4

Terrain that has become deformed is immediately visible without scouting - allows a player to know where buildings are before even looking. Helps to use f1

[Pendrokar]

Terrain that has become deformed is immediately visible without scouting - allows a player to know where buildings are before even looking. Helps to use f1

Yeah that is only used in greenfields!

Though why is it always terraforming you(to devs) could have just added a metal platform on which the building stand! + How can ground be added if there is no space to take it from?

[LordMatt]

Well these are feature requests, but you should probably still post them in mantis also.

[Tobi]

Metal extractor radius one is in mantis already:
http://spring.clan-sy.com/mantis/view.php?id=212

Didn't find the other one.

Both aren't easy to fix tho, they have in common that they need huge amounts of extra memory for the easy fix (the amount that is unacceptable for a exploit this small IMHO), or they need a fix that's much harder to code.

[Peet]

The latter would require a local copy of the height map tied to LOS....not a fun thing to implement, and would be expensive in cpu time and memory during runtime.

[Argh]

Maybe you guys should bug your favorite mod maintainers, and tell them to turn that stuff OFF, instead of wanting the engine "fixed". Buildings do not have to morph the ground when built. Nothing in P.U.R.E. morphs the ground, because this is one of the major "features" of Spring that I've always thought was of dubious value.

One FBI tag later, and this is no longer a problem, unless the design of the building includes a fake groundplate- which is also super-easy to fix- just take it out of the model, or position it a bit higher, so that it no longer clips ground geometry. It's not rocket science, it just requires non-lazy modders to actually do something more than mess with a few FBI variables.

Asking the devs to "fix" this would be stupid, imo. Because it would also involve tracking, separately, all of the changes to the ground caused by weapons. Which would involve gigantic extra loads for everybody. And I don't want OTA mods screwing up my game's performance because of something that's easy to fix...

And the metal extractor thing seems to be fixed, at least over here.

[Kloot]

And the metal extractor thing seems to be fixed, at least over here.

It hasn't been, but extracted squares only show
up red if they are within ALOS (which makes the
issue with cloaked extractors less pressing, you
need to park units next to every metal spot to
find them all).

[smoth]

ground flattening isn't a bug.

[YokoZar]

I'm a bit confused as to why fixing the cloak metal extractor isn't fairly simple. Just a simple "don't show this red circle if creator is cloaked" in the interface should work.

[lurker]

I'm a bit confused as to why fixing the cloak metal extractor isn't fairly simple. Just a simple "don't show this red circle if creator is cloaked" in the interface should work.

Because then you need to build mexes yourself, know what metal each should be producing, and then check each one seperately to find the cloaked mexes. As long as it's actively mining, cloaking shouldn't do squat about you seeing that it's draining metal when you have a scout right there. I'm not saying some mods wouldn't want that, but it's not 'fixing' to make the engine work that way, it's making an arbitrary ugly change.

[KDR_11k]

I'm a bit confused as to why fixing the cloak metal extractor isn't fairly simple. Just a simple "don't show this red circle if creator is cloaked" in the interface should work.

Spring does not know the concept of a circle for that red stuff, it only knows fields occupied and unoccupied by mexes.

[Tobi]

Indeed, and the field does not store a list of owner unit pointers for each square. So it's impossible when rendering the red field to figure out whether the square is red because of a friendly or an enemy mex (or both), let alone figuring out whether the particular mex is in LOS or not.

Of course we could create a std::vector<Unit*> mexowners[mapsizex * mapsizez], but IMHO the amount of memory this eats is unacceptably high for the small benefit it gives.

Then, it's just a matter of selecting harder to code solutions that eat less memory (and possibly don't solve the problem the ideal way).

One I can think of is adding an extra map unsigned int[mapsizex * mapsizez], which would be a bitmask for by which team(allyteam?) the metal is extracted. Still pretty huge memory footprint for the small benefit, plus it introduces a hard to remove limit of 32 (ally)teams.

Another potential solution would be to store the metal extraction field per allyteam, and only rendering the one of the player's team's allyteam. And then dynamically "merging" the fields when determining metal output (so two mex on same spot don't both give metal). Still quite high memory requirements, and may be slow depending on how often the metal output is determined.

Or not storing the field at all, and dynamically calculating it everytime it is needed. Probably extremely slow though, especially in F4 view.

The ideal solution IMHO would use some sort of compressed map like abstraction that internally stores stuff very efficient (vector based circles in a quad tree/grid?), but of course this is also the hardest to implement

[KDR_11k]

I'd say a second (unsynced?) bit per texel to mark the spots as invisible. That won't necessarily work with conflicting mex areas (e.g. regular and cloaked mex on one spot) but I can live with that.

[YokoZar]

Why not just have a cheap hack where cloak mexes export some sort of tag that says "draw all metal in this radius as green when you hit f4 unless allied?"

Then there'd only be weirdness if a friendly mex was built nearby, but that was weird anyway since, if you're paying attention, you'll notice your own mex getting 0 metal.

[Tobi]

The field is not there just for drawing, it's actually used to compute the amount of metal a mex should output.