Spring RTS Engine

it CAN be figured out by the player. unitids are readily available to anyone.

god dammit, widgets are not cheats.

Readily available? How?
And the fact that they are available is a flaw in Spring.

lurker wrote:And the fact that they are available is a flaw in Spring.

+1, nearly impossible to fix.

Why is it nearly impossible to fix?
Precis of my post here viewtopic.php?p=297443#p297443 - Surely you just need all 'local' code to be given pseudo ids (for blips) rather than unit ids in the appriate APIs (widgets, group ais, anything else?)

the problem is the same as with any cheating protection - few undetectable modifications of engine code would make any protection against leaking ids useless.

Tribulex wrote:it CAN be figured out by the player. unitids are readily available to anyone.

god dammit, widgets are not cheats.

How ?

imbaczek wrote:the problem is the same as with any cheating protection - few undetectable modifications of engine code would make any protection against leaking ids useless.

Well, it depends on what you mean by cheating. At the moment, the leaking unit ids is a built in feature of the luaui interface, and as such can't really be classed as a cheat in the same way as a custom-modded spring exe could.

Well, I would say remembering a unit id after it leaves radar range is a detrimental engine bug. As for the other people that think even displaying what a unit is after it gors from los to radar is an exploit, let me remind you that spring does this naturally with the radar dots. In some mods you may notice that after a unit goes from los to radar, its dot is no longer a blank one, but rather its minimap icon. I believe this happens for commanders in BA, and all units in CA. So showing a transparent model over that icon merely helps those not as familiar with the minimap icons.

A unit that leaves range and comes back being replaced with a ghost seems dubious to me. Everything else is fine.

Masure wrote:

Tribulex wrote:it CAN be figured out by the player. unitids are readily available to anyone.

god dammit, widgets are not cheats.

How ?

By a human function called memory!
-I know it is a old post

I haven't been using gl. functions but when looking at the code... Doesn't it draw ghosts even if it is out of screen view? Or does the functions themself take care of that?

--skip buildings, they get ghosted anyway

Unless ghosted buildings is disabled. Now here you could say that a widget is a cheat or an outlaw!

Pendrokar wrote:

Masure wrote:

Tribulex wrote:it CAN be figured out by the player. unitids are readily available to anyone.

god dammit, widgets are not cheats.

How ?

By a human function called memory!
-I know it is a old post

You would not be able to tell units apart once they left radar range and re-enter it. I dont know a way for players to figure out the actual unitId.

Pendrokar wrote: I haven't been using gl. functions but when looking at the code... Doesn't it draw ghosts even if it is out of screen view? Or does the functions themself take care of that?

Yes (it draws outside screen) but only for the radar range. AFAIK later in the rendering pipeline geometry outside view gets culled anyway (which isnt completely free). So probably its still possible to improve the rendering by checking visibility before sending stuff into the rendering pipeline. But I dont know if you would get a noticable performance increase. Maybe some OGL-Wizards could share their opinion about this.

Pendrokar wrote:

--skip buildings, they get ghosted anyway

Unless ghosted buildings is disabled. Now here you could say that a widget is a cheat or an outlaw!

GroupAIs are gone now, right? So the argumentation applies for units nowadays too (since there is no RadarAI freely available anymore). It's indeed arguable.
But theres no way back now, better keep it available to the public rather than trying to keep it concealed which would only hurt "newbs" who dont have it already.
An engine-side fix would be needed to really get rid of the unitID-problem I think.

very_bad_soldier wrote:

Pendrokar wrote: I haven't been using gl. functions but when looking at the code... Doesn't it draw ghosts even if it is out of screen view? Or does the functions themself take care of that?

Yes (it draws outside screen) but only for the radar range. AFAIK later in the rendering pipeline geometry outside view gets culled anyway (which isnt completely free). So probably its still possible to improve the rendering by checking visibility before sending stuff into the rendering pipeline. But I dont know if you would get a noticable performance increase. Maybe some OGL-Wizards could share their opinion about this.

culling occurs on per-face/per-vertex level, so it runs everything through the vertex shaders -> slow
Always do a cpu frustum test if you are interested in performance it is WAYS faster.

Please don't resurrect past masters.