lua aimbot - Page 2

lua aimbot

Discuss Lua based Spring scripts (LuaUI widgets, mission scripts, gaia scripts, mod-rules scripts, scripted keybindings, etc...)

Moderator: Moderators

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by 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
Posts: 1187
Joined: 08 Jul 2006, 19:07

Post by ZellSF »

AF wrote: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.
User avatar
Masse
Damned Developer
Posts: 979
Joined: 15 Sep 2004, 18:56

Post by Masse »

ZellSF wrote:
AF wrote: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
User avatar
Fanger
Expand & Exterminate Developer
Posts: 1509
Joined: 22 Nov 2005, 22:58

Post by 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..
User avatar
Peet
Malcontent
Posts: 4384
Joined: 27 Feb 2006, 22:04

Post by Peet »

Fanger wrote: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
Posts: 297
Joined: 28 Feb 2005, 19:19

Post by 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.
User avatar
LordMatt
Posts: 3393
Joined: 15 May 2005, 04:26

Post by 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
Posts: 1187
Joined: 08 Jul 2006, 19:07

Post by 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
Posts: 3629
Joined: 22 Aug 2006, 16:19

Post by imbaczek »

Add a weapon tag 'canbefiredbyscript/helperai=0/1'. Problem solved.
User avatar
1v0ry_k1ng
Posts: 4656
Joined: 10 Mar 2006, 10:24

Post by 1v0ry_k1ng »

10053r wrote: 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?
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

imbaczek wrote:Add a weapon tag 'canbefiredbyscript/helperai=0/1'. Problem solved.
This would make all skirmish AIs impossible to use.
imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Post by imbaczek »

AF wrote:
imbaczek wrote: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.
User avatar
1v0ry_k1ng
Posts: 4656
Joined: 10 Mar 2006, 10:24

Post by 1v0ry_k1ng »

if spring is awareness of projectiles speeds and headings you could make a dodge projectiles AI as well...
Sheekel
Posts: 1391
Joined: 19 Apr 2005, 19:23

Post by 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?
User avatar
1v0ry_k1ng
Posts: 4656
Joined: 10 Mar 2006, 10:24

Post by 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.
User avatar
Scikar
Posts: 154
Joined: 30 Jan 2006, 07:13

Post by Scikar »

Sheekel wrote: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
Former Engine Dev
Posts: 1200
Joined: 17 Nov 2005, 00:52

Post by 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...
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by 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
Posts: 57
Joined: 05 Aug 2006, 15:49

Post by 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
Former Engine Dev
Posts: 1200
Joined: 17 Nov 2005, 00:52

Post by 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...
Locked

Return to “Lua Scripts”