Poll: Locking client widgets

[CarRepairer]

With every stable release, add a new widget that turns off local widgets. Expert users will have to manually turn their widgets on again, while novice users would be protected from spring default widgets or anything they may have downloaded without knowing the consequences.

Don't bother doing stuff that would make us hated among the expert users. Anyone could fork CA and turn it off anyway.

[licho]

WTf anyone can fork anything and nobody ever does, what sort of argument is that.

[Saktoth]

Unless there is a technical reason, keep CA open and clean. CA keeping its own list of which widgets are activated widgets should be enough to keep it conflicting with BA widgets. Just how bad can these 'ghost units' cheats be, really? Why arent they already in CA anyway?

[licho]

Reason is newbie experience of experience of person who just tries CA after playing BA with x custom widgets.

Result is GUI chaos, bugs, broken features, FPS drops.

Maintaing set of most usefull widgets is much better and gives user stable and secure experience.

Interface chaos is enough to make person never try CA again (as shown by forum thread). And since we are going to have our own interface we should disable other stuff.

Ghosted unit is imo huge cheat and also looks ugly. No way you would know that radar dot X is actually unit Y. You do realize it reveals it even when map shows just circled (undetermined) dots?

[Saktoth]

Okay, so thats a cheat. There really cant be an engine change here?

Either way i think the best approach is seperating 'widgets activated in CA' from 'widgets activated in BA', so that if you turn a bunch of stuff on in BA it defaults to off (default widget setup) in CA. But you can enable anything you want, otherwise we dont remain the default place to make widgets.

[SirMaverick]

I implemented "Yes, but allow expert users to override.". Haven't seen poll earlier.

Complete lock is not an option (too many rage, I can't test things...). And things like "ghost radar" should be handled at engine level.

Ghost radar: you only see that ID of a unit, nothing more. You had to see it earlier to know exactly what type of unit that is. This is what ghost radar does, remember units that went out of LOS.

[Google Frog]

Either way i think the best approach is seperating 'widgets activated in CA' from 'widgets activated in BA'.

Engine has had per-mod lua preferences for a few versions. This is already implemented.

Ghost Radar is very annoying but I don't think it's worth a lock. Hopefully there will an engine patch for this, I know lurker is very annoyed by it. All it would take is returning an 'unable to see unitID' to radar dot queries.

[CarRepairer]

Replying to Google Frog:

Hopefully there will an engine patch for this, I know lurker is very annoyed by it. All it would take is returning an 'unable to see unitID' to radar dot queries.

Unfortunately no, it's more complicated than that. You need to get a unitID for a radar dot as lua needs to be able to do things to radar dots just like doing things to visible units. What would be needed is a separate set of unitIDs that are locally generated and applied to all new unknown radar dots. In fact it's even more complicated than this since synced and unsynced might want to communicate these unitIDs.

[Licho]

Winner: Yes, but allow expert users to override. (40%)