lua aimbot

[Argh]

Heh. It's like the guys in CS when cheating was a lot more common, who'd jump out've a building's window, headshot three dudes within a 5-second period from 100 feet away, then miraculously suffer "lag" that made them warp around a corner before your shots could register

I guess my stance on this is pretty much that allowing the use of LUA widgets that all parties don't have is just asking for accusations of cheating, once we have functional widgets that can do fairly powerful things. It'd be better to let users collectively decide that LUA widgets are something that users will need to download and install, just like maps.

[ZellSF]

Zell, the predictive dgunning groupAI could dgun hawks, imagine it going at full throttle on a fast PC against a group of brawlers that just arrive.

d-gun range isn't that large, so there's by far more effective aa to build when there's T2 air around.

[Masse]

Zell, the predictive dgunning groupAI could dgun hawks, imagine it going at full throttle on a fast PC against a group of brawlers that just arrive.

d-gun range isn't that large, so there's by far more effective aa to build when there's T2 air around.

still commander with dgun aimbot is instakill rapid fire anti air gun... trust me
any group of planes going over commander will get annihilated when such a ai is there

(krogothe once proven that with pretty little effort)

and probably that could be used on other units too when u get in trouble with planes and got only land defence... just force your ambushers or any other cannons to fire down the planes

[Fanger]

i find it amusing that almost all this cheating discussion centers around dgunning...

anywho.. given the ability for mods to setup specific lua setups I dont think its a serious issue..

[Peet]

i find it amusing that almost all this cheating discussion centers around dgunning...

anywho.. given the ability for mods to setup specific lua setups I dont think its a serious issue..

Aha, yes, a solution! EE ftw!
and simbase.

[10053r]

Honestly, and I know people will disagree with me, but this game is not about the ability to twitch and click fast. It's about the ability to think quickly, and make critical decisions quickly.

I have no problems with any widgets that do anything that could theoretically be done by the user by themselves, even if it does them all at once. I have no problem with anything that makes more efficient use of the information available to the user, even if that information would be impossible to correlate by any human being in real time. This is real time strategy here, not some test of hand-eye coordination.

Who cares if someone dgun's planes? Or even shoots them down with annihilators? My units already aim for themselves. Honestly, I think it's kind of stupid that they don't aim optimally already. In real life any laser than can pivot that fast has a chance of hitting aircraft. In fact, the US military has a 747 based laser designed to shoot down incoming missles going several times the speed of sound. I don't know if it works, but if the US military had nanolathes and the ability to build things from the atom up, I should hope it would.

Some of you would say that this will make the game less fun. I disagree. Clicking fast is not fun. Having to make critical decisions about where to commit my resources is fun. Making critical decisions about when to be offensive, and when to grow my economy is fun. Mods will adapt to players getting more use out of the units they already have. Some of them will adapt by putting artificial restrictions on things (like making dguns do no damage to flying aircraft), but the smart ones will say, "How can I adapt my mod so that it is not about micro?"

Automation is coming people, both in game and in real life. Worrying about it puts you squarely in the camp of the RIAA, MPAA, and buggy whip manufacturers.

[LordMatt]

Dgunning (and doing it right) is a more critical game decision often times than anything else. It determines whether your com survives or dies, and YOU must make that decision. There is a lot more subtlety than just hitting the d key and clicking, and you show your own lack of skill by not realizing it. If we wanted to play this game vs a computer, rather than another human, we would be playing AIs.

[ZellSF]

First, unless you're playing on an extremely small map, keeping your air away from a com isn't that difficult, he can't d-gun that fast anyway, flak is probably just as dangerous to any attack force.

Second, on land you need to cloak, set commander to don't fire at will, probably move a lot around, decide when to give up and combomb the army, and I doubt an AI can do that nearly as well as a human can.

[imbaczek]

Add a weapon tag 'canbefiredbyscript/helperai=0/1'. Problem solved.

[1v0ry_k1ng]

Who cares if someone dgun's planes? Or even shoots them down with annihilators? .

how about anyone who wants to play a balanced, fair game?

[AF]

Add a weapon tag 'canbefiredbyscript/helperai=0/1'. Problem solved.

This would make all skirmish AIs impossible to use.

[imbaczek]

Add a weapon tag 'canbefiredbyscript/helperai=0/1'. Problem solved.

This would make all skirmish AIs impossible to use.

Note that I specifically said 'helperai' and not 'ai' with skirmish AIs in mind.

[1v0ry_k1ng]

if spring is awareness of projectiles speeds and headings you could make a dodge projectiles AI as well...

[Sheekel]

So when is this considered cheating?

At the LANs I go to, we've decided to ban the use of helper LUA scripts. I guess we want people to have to actually play the game, not write a script to do it for them. Micromanagement anyone?

[1v0ry_k1ng]

I dont think the metal maker and factory gaurd widgets are cheating; they are things that spring should do by default. stuff discussed in this thread would definatly be cheating though.

[Scikar]

So when is this considered cheating?

At the LANs I go to, we've decided to ban the use of helper LUA scripts. I guess we want people to have to actually play the game, not write a script to do it for them. Micromanagement anyone?

Judging from your avatar we're not in the same camp, but personally I prefer to be telling my Cans to attack a factory in my opponents base instead of ordering them in and then leaving them while I go off to turn off some metal makers so that their lasers still work. I come back and they walked into a comm and got dgunned.

By your argument, why should we even have repeatable queues on buildings, patrol paths, hell we should even say units can't attack anything unless you order them to.

I don't think an auto dgun AI is going to be a good thing, but I'm certainly glad I don't have to manually upgrade every mex, assign idle nanotowers to assist buildings and turn off metal makers when my energy is drained.

I think the solution lies with the lobby to be honest. Get the lobby to check the lua scripts a player has against the hosts, and warn the host if a players scripts don't match. Then allow the host to download them from a client and upload to other clients. If a host is suspicious of a script he can disable use of scripts that aren't also on his machine. This also lets hosts decide if certain widgets are or aren't permitted, rather than Spring or a mod enforcing it.

[trepan]

I've probably mentionned it in another post, but here it is again...

I've added a .nohelp server command which disables GroupAIs and
LuaUI's control of units. It also disables GlobalAIs at the moment, but
I'm in no big rush to fix that

P.S. Ya, I should probably rename it to .noAI if I'm not going to fix it...

[AF]

Trepan, neglecting AI is a huge mistake. AI in spring has already suffered gross neglect because of changes made during the coding of Lua APIs. AIs cant even detect water atm because of your changes, and submarines chasing after you in the code fixing your mistakes to fix AAI.

A lot of people put a lot of time and effort into skirmish AI projects and there's an army of people who then support those AIs writting config files, testing, training AIs, writting documentation and telling people how to use them.

You've already killed off groupAI, whats next?

[pktm]

[quote="Tim-the-maniac"]Thats a pretty crappy idea :/
How often are you gonna be able to use any of the non-standard widgets...[/quote]

Where is the problem to create a release-cycle for LUA-widgets, so people can get their fresh copy of all-time standard widgets?
Why should spring be doomed to be an unmanaged, uncoltrollable piece of software? NO good software handles things like that, because the disadvantages are higher than the advantages.

Have a look at mods of other games. Who is complaining about people not playing a special favorite warcraft3-td-map because he doesn't downloaded it? Noone.
And the same way it could work here.

Organize the releases of the LUA-widgets. That could prevent cheating, inkompatibilities like people having different versions of the widgets and disables the possible uncontrolled growth of widgets (like having 29 different kind of a player-info-widget). You would do better software!

We have the same thing on mods. If you don't have the right mod, you cannot join a game with that mod. You can download it if you want.

[trepan]

AF:

1. So you're pissed that I added LuaUI without investing more of my time
into improving the AI interface? Adding to LuaUI does not remove existing
AI interface features. You could post patches to improve the AI interface,
but it would appear that you prefer to whine.

2. I did not break any calls for AIs. submarine is not chasing after any bugs
of mine that I am aware of. I took a look at the 0.70b1 code, and it would
appear the ground clamping existed in AICallback::GetElevation() even then
(note that I did not have SVN acces at that time).

3. I didn't "kill off" GroupAI. In fact, I've made it more accessible by allowing
units to be assigned to a GroupAI with keybindings. I have removed none
of its functionality, with the exception of it being able to see decoy unitdef
parameters when it shouldn't (which is a bug fix).

Yes, LuaUI can replace some of the existing GroupAIs (and is easier to code,
and for players to use), but so what? The players can decide what they want
to use.

4. The reason that I'm in no rush to fix .nohelp for GlobalAIs is that I don't see
a lot a multiplayer games using GlobalAIs. The only time that .nohelp is useful
is in multiplayer games. I also don't expect it to get used all that much...