GhostRadar v1.11 *fixed*

[Argh]

Just tried sticking their modified code into World Builder, and activated LockLuaUI.txt...

None of the Widget code in the main body of P.U.R.E. operates.

F11 no longer brings up Widget menu, but takes a screenshot. Various other things seem to be screwed up. My credits Widget, which is in P.U.R.E.'s main body, doesn't run. Looks like it doesn't properly handle VFS situations involving more than one game file.

I'll get back to the blacklist application- this isn't going to work for me. World Builder is supposed to remain separated, and if LockLuaUI.txt doesn't allow everything that's called up via dependency to operate, then this is just not going to work...

[trepan]

No need to address anything, CA has it working.

http://spring.clan-sy.com/phpbb/viewtopic.php?p=283605

So what's the bloody mystery, go look at how CA did it. Recognize
that you can't figure it out for yourself, and copy it from folks who have.

[Argh]

I've just taken a longer look at CA's code for this, and the problem is here:

Code: Select all

local ORDER_FILENAME     = LUAUI_DIRNAME .. 'Config/widget_order.lua'
local CONFIG_FILENAME    = LUAUI_DIRNAME .. 'Config/widget_data.lua'
local WIDGET_DIRNAME     = LUAUI_DIRNAME .. 'Widgets/'
local MOD_WIDGET_DIRNAME = MODUI_DIRNAME .. 'Widgets/'

So how do I point VFS at another "game's" SDZ, using a relative path? Insofar as the WidgetHandler code is concerned, World Builder is a "game"...

[Acidd_UK]

I'll have your babies for making this

[Argh]

Making what? A blacklist app? Already done, it's in P.U.R.E., and it works. It's a pretty crappy way of going about this, however. It'd be almost trivial to circumvent. CA's solution is a lot more foolproof.

However, doing it the right way, by locking LuaUI, does not work, because of the VFS problems I've mentioned here. That means that any games that include World Builder are basically hosed on using this, because World Builder needs to include some Widgets. In my tests, CA's solution works for either World Builder, or P.U.R.E.'s Widgets, but not both- one gets shut down.

I have no idea how to get both LuaUI directories to be treated as one directory for the purpose of being initialized by the WidgetHandler, and I have a sneaking suspicion I'm just not going to be able to figure that one out, frankly.

[Acidd_UK]

Making what? A blacklist app?

No, my post was on topic.

[Google_Frog]

I like idea of the widget but it cheats. It remembers what a unit is even when it has moved our of radar range and re-entered.

[Acidd_UK]

This is a very gray area. IMHO its not cheating, but the widget-facing spring code should probably have something in to randomise a widget-facing id when it enter/leaves a player's los, which would then prevent this.

Edit: If a unit is destroyed, does it's unitId get reused?

[very_bad_soldier]

Thx Acidd

This is a very gray area. IMHO its not cheating, but the widget-facing spring code should probably have something in to randomise a widget-facing id when it enter/leaves a player's los, which would then prevent this.

If I understood correctly Trepan did something like that in SVN. So expect this widget to expire with next spring release. But this is perfectly ok. I really think the EnteredRadar function gives/gave too much information when it delivers the real unitId.

BTW: AFAIK real cheating is not possible in a widget. So you can only try to make the most of the information you get from the engine.

Edit: If a unit is destroyed, does it's unitId get reused?

If it is so, this widget has a bug I just assumed it is not.

[Forboding Angel]

VBS, would you make a gadget version of this? I have a feeling that someone is going to bork the inner workings of this so that regular players can't use it. I however really like it.

Soooo, doable?

[Acidd_UK]

From what little Trepan said, it sounded like unit ids are randomly assigned rather than starting at 0? 1? and incrementing. So this will fix the if unitid<no_teams : its_a_commander issue, but I think it needs to be more complex on a per-player basis.

For example, it's reasonable (imho) to keep the unit pic on the unit when it goes from los->radar - it's not even as 'powerful' as ghosted buildings when you think about it, since they persist even when radar is lost), but you should lose the info on the unit when it goes out of radar.

If that's done by reassiging some pseudo random id, then the lua interfaces would have to give you the 'real' unit id of friendly units, but an anonymised id for units entering radar. I hope that makes sense, but it's not a totally simple fix from what i understand...

On a separate note, I would love python bindings tot he lua callouts. Assuming these are effectively Lua wrappers round C functions, it should be (relatively) simple to wrap those same C functions with Python. I Heart Python. Would anyone be interested in such a thing? I remember Biscuit Mage did a similar thing (using swig) with the group AI interface a year or so ago, and it worked rather well....

[BaNa]

This is epic *lua thing*, perhaps on the op side, but meh. I hope it doesn't get broken. The going out of radar- coming in to radar range thing could be fixed i guess, but don't hurt the rest pls.

[BaNa]

My personal take on Widgets is that anything that tells you about the capabilities of the enemy, and isn't built into the game design... is cheating, period.

I disagree. The two widgets that I've seen doing that only do things that good players can deduct.

Defense range does more or less the same thing that good players could do anyway, which was: pretend to build X defensive building in the spot of ghosted enemy building and mark range on map.

Ghosted radar may be a bit shadier, but you can usually guess what units are based on their speed. And if you have LOS on units, you wont magically forget that those 20 points are stumpies/flash whatever if they turn back into blips. The only part of it that may be op is when they leave the sight of the radar.

I think the real answer is a lockdown on Widgets that aren't installed by the game or in the base folder, initiated in the Lobby. Competitive games should not be decided because some asshat is using a Widget that tells him where everybody is, what their ranges are, and what they're covering, etc.- it basically removes all of the elements of information warfare that are an essential part of the RTS experience.

These elements of information warfare are clunky and archaic. Do you really think modern warfare lacks such help? Is it so hard to imagine a HUD that acts more or less the way defencerange does? Do you really think that all the information radar returns is speed and position? Nothing about size? And especially after LOS has been set up, do you think everybody *forgets* what kind of enemy it was?

I for one welcome these changes. They wont make you into a better player magically, but they are very useful. And in cases this ghosted radar widget facilitates more scouting, since you have more to gain by getting LOS on those units.

And may I add: Competitive players should know about widgets, just like they know the details of the mod and units and whatnot.

[Google_Frog]

My personal take on Widgets is that anything that tells you about the capabilities of the enemy, and isn't built into the game design... is cheating, period.

Agreed. The game tells you what the unit is when it enters los and if it leaves and turns into a dot you could stare at the dot remembering what the unit is. There is no extra info being shown it's just a memory aid (if the widget worked properly).

Ghosted radar may be a bit shadier, but you can usually guess what units are based on their speed. And if you have LOS on units, you wont magically forget that those 20 points are stumpies/flash whatever if they turn back into blips. The only part of it that may be op is when they leave the sight of the radar.

Widgets aren't OP or UP they are micro saving devices. The leaving radar bug does show extra info and is certainly cheating.

Ghosted radar may be a bit shadier, but you can usually guess what units are based on their speed.

Are you saying it should tell people what the unit is all the time? The speed method is unreliable because there are many things of similar speed and radar drift makes them look faster or slower.

[BaNa]

Widgets aren't OP or UP they are micro saving devices. The leaving radar bug does show extra info and is certainly cheating.

you managed to nail it better than me, although i would say that cheating is a very strong word. I used the phrase "OP" in a novel way to signify that this widget/feature of said widget may give the player using it an advantage in battle. I did not mean that it's DPS is too high or anything of the sort.

Are you saying it should tell people what the unit is all the time? The speed method is unreliable because there are many things of similar speed and radar drift makes them look faster or slower.

meh, it works in most cases that matter, such as jeffe/flash; flash/stumpie; and com/flash. And I am not saying it should show what unit it is by default, although I do feel that the blip way of showing things is very lacking and 1 dimensional.

[Argh]

This kind of a thing is a cheat, pure and simple, now that I've tested it out.

The whole idea of the radar system is to make the blips a mystery, and require players to keep track of stuff on their own, and judge what's important based on clues such as speed. Moreover, there's the non-trivial aspect of the blips moving around all the time.

I can see all sorts of abusive uses of this kind of thing- for example, let's say you have a game with an AWACS-style airborne radar. Well, with this thing, you can just fly some cheap aircraft over the enemy's base, get all of the unit positions exactly forever. Gee, that makes deciding what's a priority target pretty darn easy, doesn't it?

Moreover, it destroys the unreliability of the blips, as it doesn't move the positions to the false position, but instead constantly gives you the correct position. Just force-fire your stuff at the ground, instant pwnage.

In any game with long-range artillery that isn't terrible... it's a cheat, not a legitimate player aid. Meh, I don't even like ghosted buildings, but this is worse, because it effectively ghosts mobile stuff, like, say, mobile nukes in BA.

I guess I'll have to send the latest P.U.R.E. beta to Trepan to take a look at the VFS issues, as I do not want players to be able to use stuff like this in my game, period.

[AF]

radar jammers for the win!

[very_bad_soldier]

This kind of a thing is a cheat, pure and simple, now that I've tested it out.

I respect your opinion of hating this, thats no problem. But I dont think it is that simple.
Besides in-out-radar-behaviour (which is an engine issue) the widget does not more than RadarAI does too (which is spring default).

The whole idea of the radar system is to make the blips a mystery, and require players to keep track of stuff on their own, and judge what's important based on clues such as speed. Moreover, there's the non-trivial aspect of the blips moving around all the time.

If this is the idea of the radar system, why do functions like "UnitEnteredRadar" provide the actual unitID? And making use of that information you call cheating? With the same argumentation one could call comnapping cheating which is considered as "part of the game" (yes, BA of course ).

Moreover, it destroys the unreliability of the blips, as it doesn't move the positions to the false position, but instead constantly gives you the correct position. Just force-fire your stuff at the ground, instant pwnage.

Are you sure? The widget does NOT manipulate any radar blip positions. Please tell me which mod you used to test this. I will have to see it for myself.

[Hoi]

blips dont move when spotted anymore

[UAF]

Well, this sounds like an engine issue that should be fixed.
And in the meantime, why not just make a widget that automatically turn RadarAI on?
Or does this widget do more then that? (apart of the "cheating")