lua aimbot
Moderator: Moderators
- 1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
lua aimbot
how hard would it be for someone to, for example, make a predictive lua d-gun aimbot? can we expect this to emerge?
-
- Posts: 250
- Joined: 22 Jul 2006, 19:58
Well, one thing that might help would be to record the screen position of the user. Then if you are watching the demo and someone is dgunning, but don't have their screen over their com, you can assume they were cheating. I don't really like the idea of host control over widgets, because the host would have to be fairly knowledgeable about what widgets might be problematic, and I don't want the typical nub host to be like "IDLE CONS WIDGET IS GAI I'M DISABLING IT, UM, SETTINGS ARE DGUN LIMITED AND COM CONTINUES."
- 1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
- BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
it's a widget who displays an icon in the bottom part of the screen for each factory/builder who is currently idle; it workes pretty much as the unit groups but instead of displaying the groups, it will display a list of idle builders.1v0ry_k1ng wrote:I dont use the idle cons widget atm, whats the use of it?
-
- Posts: 250
- Joined: 22 Jul 2006, 19:58
I've yet to see a widget that does anything I'd object to. And I think I do my d-gunning way better than any script would
And no to the "only widgets that everyone else has" idea. I'd just get rather angry at not getting to use some widget and delete all the widgets, defaults included and make sure no one else can use their favorite widgets either.

And no to the "only widgets that everyone else has" idea. I'd just get rather angry at not getting to use some widget and delete all the widgets, defaults included and make sure no one else can use their favorite widgets either.
Anything that makes (or does) game critical decisions:Tim-the-maniac wrote:How do you define cheating mat?
1) Something like predictive dgunning of units is not an easy skill to learn, and can be the difference between winning or losing. Therefore it should not be scripted.
2) Something like turning metal makers on and off with energy is just mindless tedium that no one will find fun, and therefore that is acceptable.
3) Streamlining tasks that would otherwise require a lot of micro, for a simple idea (such as your transport widget) are acceptable because they add depth to the game. As would be a widget that shares all your units to an ally if you kit a key combo is acceptable (it streamlines something that was already possible before).
4) A widget that does this automatically if your com falls below a certain health threshold is not acceptable, because it is making a critical game decision for the user.
I see some similaries with world of warcraft here. In the early days of wow you could controll nearly everything with LUA, but you have to workaround about a lot of things, because the LUA-Implementation was not really powerfull (dymanic stuff for example...)
Then more and more things got locked, but the Implementation got more powerfull.
With v2.0 they changed the whole system and made a distinction betwen 'battle'-mode and 'rpg'-mode. So a lot of critical things can only changed out of battle.
'Unfortunately' in spring the battle never stops.
I thing in spring the only way to control this, is to limit the ammount of control LUA get. So for example a weapon like the dgun should not be able to be controlled via LUA. But if you don't want to cripple the flexibility of LUA, this should be controllable by the mods.
Maybee something like a 'Luacontrollable=false'-parameter for weapons and unitstates could work.
ps:
Does the current unitsync system could allow a snipermode for inacurate weapons by prefetching their next mismatch and readjusting the attackpoint. (This is apart from a maphack the only possible hack for spring that I can imagine)
Then more and more things got locked, but the Implementation got more powerfull.
With v2.0 they changed the whole system and made a distinction betwen 'battle'-mode and 'rpg'-mode. So a lot of critical things can only changed out of battle.
'Unfortunately' in spring the battle never stops.

I thing in spring the only way to control this, is to limit the ammount of control LUA get. So for example a weapon like the dgun should not be able to be controlled via LUA. But if you don't want to cripple the flexibility of LUA, this should be controllable by the mods.
Maybee something like a 'Luacontrollable=false'-parameter for weapons and unitstates could work.
ps:
Does the current unitsync system could allow a snipermode for inacurate weapons by prefetching their next mismatch and readjusting the attackpoint. (This is apart from a maphack the only possible hack for spring that I can imagine)
Garry's mod for Half-life 2 has a built in LUA manager that makes sure everyone is on the same page as far as scripted weapons and tools are concerned, and if you don't have it the script, it downloads it for you. Pretty nifty.
What I think needs to happen is that you see all of the LUA scripts your host is using, and they are all downloaded to your computer, and then for yourself, you get to choose which ones your want enabled or disabled for you as an individual, but of course the host would have complete control over which would be used in the first place.
What I think needs to happen is that you see all of the LUA scripts your host is using, and they are all downloaded to your computer, and then for yourself, you get to choose which ones your want enabled or disabled for you as an individual, but of course the host would have complete control over which would be used in the first place.
Last edited by Neuralize on 20 Feb 2007, 09:05, edited 1 time in total.