[Request] Control Victory Behavior

[ForbodingAngel]

Ok so here is the deal. I have been working on the controlvictory gadget for months now. It is an integral part of evo now (it is the default gametype), and when I'm done (almost there!) it will be able to just be airdropped intoany spring game and "just work"(tm). This will allow someone to add 4 different gametypes to their game with 0 work and 5% effort.

The problem I have is that my bots don't know anything about the cv points. The good news is that the points are contained in configs that are ["cv_" .. mapname .. ".lua"], that means that it's easy as pie to check and see if there is an available config for them.

I would like to request that someone make a super simple behavior that causes the bots to capture cv points. There isn't much to it. You have a list of points in a config, one unit can cap a point but more units is faster at capping. You have a score for each team and the gamemodes are countdown (more points you own the slower your score is counted down, first to 0 loses), tug of war (points are transferred from one player to the other, first to hit 0 loses), and domination (control all points for 30 seconds to score 1000 points, first person to the set score limit (3500 is default), wins).

So yeah, it's relatively straightforward. I really need shard to have the ability to see the points and try to capture them. Any chance I could get some help?

[eronoobos]

Since this is a common type of RTS gameplay, I think it makes as much sense as spothandler.lua (for metal spots) to include it in the default set of modules. But even though your hope is for your gadget to become used by other Spring games, doesn't, say, Spring 1944 have a different way of handling it?

I'm up to helping you out (it does indeed seem like a pretty simple behaviour and module to write). Just I need to think about at what level of universalization within Shard it should be implemented. My first thought is just to put it with the default behaviours and modules, and have the behaviour depend on an empty unit list, that, like attackers.lua, could be filled in by a game config.

[ForbodingAngel]

Spring 1944 uses a very primitive version of the gadget that I've been working on (modified for their purposes).

I would assume that they use configs for theirs, but I don't know for sure. As a default behavior would be awesome, because then it would essentially have drop in AI support. I'm working really hard to make this as simple as possible for everyone.

The configs that evo uses are here: https://github.com/EvolutionRTS/Evolution-RTS/tree/master/LuaRules/Configs/ControlPoints

As you probably suspected, they are just lists of coordinates, but it should be possible to just look in that folder for ["cv_" .. mapname .. ".lua"], which will then net you the coordinates of the rings.

The actual gadget that handles it all is here: https://github.com/EvolutionRTS/Evolution-RTS/blob/master/LuaRules/Gadgets/game_controlVictory.lua

At the top of the gadget is a list of "nonCapturingUnits", which is essentially unitdefs that cannot cap points. It might be worth it to read that as well. Perhaps those should be in a config as well for ease of use? That way, it wouldn't need a specific def just for shard, or maybe shard should have it's own def? I dunno, whatever you think is best.

[eronoobos]

Yes, I think nonCapturingUnits should be put in a config file, perhaps luarules/configs/controlvictory.lua, so that there's no confusion of redundant configs. Actually, I think all of variables at the top of the gadget should be moved to this config. The AI might need them.

So all units besides nonCapturingUnits should loiter around the control points? This does bring up the issue of evaluating map control. The AI should not simply distribute its units evenly across the control points, but pick those that it can actually hope to control. EvoRTS's config is a kind of test case for keeping a Shard config simple and as close to the default as possible. So I don't want to get into the kind of complexity that the BA/BAR config does to evaluate the safety/vulnerability of a location. But there does need to be some algorithm for deciding which points to capture, and with how many units each. The simplest behaviour that comes to my mind is for each capturing unit to always move to the nearest uncaptured point.

Which brings us to the fact that to know which points are captured by whom, the AI would have to duplicate the calculations of the gadget. Could the gadget export such information, either in RulesParams or a function in Script.LuaRules, like ControlPointTeam(x, y, z)?

[eronoobos]

Hm, I'm thinking it would be more elegant and robust for game_controlVictory.lua to register global functions for all the info we want to give the AI. ControlPoints(), NonCapturingUnits(), and ControlPointTeam(x, y, z)

(then none of these things would have to be moved to a config file, the AI would not have to care about the naming conventions of config files, and finally, the gadget gets to control all of these things, in case there are changes in the future)

[ForbodingAngel]

Yeah in thinking about it I came to the same conclusion that it would be better to use GG on various functions so that the AI can just ask. Modoptions (knowing the gametype, etc) can be queried from virtually anywhere so that shouldn't be a big deal (because behavior would/might vary slightly depending on tugofwar/countdown <-> Domination).

I would think that maybe teamScore would be a good think to make available? That way the AI could query all player scores if it wanted. That's assuming that it's behavior would change based upon how well it was winning or losing, which I don't think would be all that necessary, but it's a thought.

As far as configs go, I think really the only thing that belongs in a config is NonCapturingUnits() (we could still just make the function global so that the AI doesn't need to look for configs... It could just ask and get and answer that way), because it is very much game specific. Imo game specific stuff or things that the game would want to possibly change should be either in configs or modoptions. That way it's becomes super flexible. I intend on having a set of short instructions (mainly for configs and modoptions) on how to add this to their game. Should be super dead simple.

Tbh, games could add it as an option and just leave it disabled by default. For example if BA decided they wanted to integrate it, they could just leave it disabled by default in modoptions, but if they had some players that wanted to use it they could just flip a switch (this shit is FUN AS FUCK in teamgames).

Anyway ok, I will start working on making all these global. Takes me a little bit because I kinda have to read up on what I'm doing, but iirc, it's dead simple to do.

[eronoobos]

Rather than GG, I suggest using for example gadgetHandler:RegisterGlobal('ControlPoints', getControlPoints) in gadget:Initialize(), where getControlPoints() is a local function in the gadget. It could then be called from the AI (or any other synced gadget) via Script.LuaRules.ControlPoints()

I mean, call the globally registered functions whatever you like, I just wanted to save you some research.

Cool, I'll work on the AI behaviour.

Somewhat off-topic: Control point game types for BA would be fun!

[eronoobos]

here's what i have so far https://github.com/eronoobos/ShardSpringLua/blob/master/luarules/gadgets/ai/controlpointhandler.lua https://github.com/eronoobos/ShardSpringLua/blob/master/luarules/gadgets/ai/capturerbehaviour.lua

i haven't tried it out yet (i need to feed it some points)

[ForbodingAngel]

Awesome! I'm having a little trouble understanding how to make these available globally. For example, there is no controlpoints or gencontrolpoints functions, there is simply "config.points" which is done at line 100 in the gadget as vfs is reading the config file, and nonCapturingUnits is just a local array.

I.E. The stuff you're wanting aren't actually functions. Not sure what to do.

[eronoobos]

https://github.com/EvolutionRTS/Evolution-RTS/pull/23

[ForbodingAngel]

Oh christ -_- Sorry. Thank you!

[ForbodingAngel]

Ok I added, merged your changes and updated shardluaai. When the game started I simply did nothing so all points stayed neutral. Shard sent a force to attack my base, then I captured one point. Shard sent a force to recapture that point, but after that point had been captured, it's army just sat motionless and never did anything else.

I captured some other points but shard never did make a move to claim any other points, nor did it ever attack me again.

I would suggest that shard should probably cycle through all points and get their status, if it doesn't own a point, send a force to go take it, starting with the points closest to it.

Simplistic, but it should work?

[eronoobos]

Oooops. It already in theory does what you suggest. However, the only time it looks for new points to capture is on UnitIdle. I.e.: the units go out to capture the first point, get there, immediately check for the nearest uncaptured point, which at this point is still the point they are on, and never check again. I'll add a periodic check. I'd debug this myself, but I can't get Evo to work on Windows, and my Linux setup is a wip atm.

[ForbodingAngel]

If you're having trouble getting eco to work on Windows, you are probably missing the Spring Features v1.9 dependency. You can get it using pr-downloader using the rapid tag spring-features:stable or you can just use Spring Features v1.9 and it will get it.

Additionally, you can just use the rapid tag eco:test if you want to get my latest commit via rapid. I would suggest using git, but there are multiple ways to get it :-)

What problem are you having specifically?

Ohhh btw the latest versions only work on 101 and 101+. Use 102.rc3 for best results. On May 31, 2016 9:38 AM, "eronoobos" notifications@github.com wrote:

Oooops. It already in theory does what you suggest. However, the only time it looks for new points to capture is on UnitIdle. I.e.: the units go out to capture the first point, get there, immediately check for the nearest uncaptured point, which at this point is still the point they are on, and never check again. I'll add a periodic check. I'd debug this myself, but I can't get Evo to work on Windows, and my Linux setup is a wip atm.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eronoobos/ShardSpringLua/issues/6#issuecomment-222746291, or mute the thread https://github.com/notifications/unsubscribe/AAWjsnAreuIdwCYJgJ-b7suvakrc8Wk0ks5qHGP9gaJpZM4IpN-z .

[ForbodingAngel]

Shit... everywhere it says eco, substitute "evo". Fucking autocorrect. On May 31, 2016 10:35 AM, "Ben Woods" forbodingangel@gmail.com wrote:

If you're having trouble getting eco to work on Windows, you are probably missing the Spring Features v1.9 dependency. You can get it using pr-downloader using the rapid tag spring-features:stable or you can just use Spring Features v1.9 and it will get it.

Additionally, you can just use the rapid tag eco:test if you want to get my latest commit via rapid. I would suggest using git, but there are multiple ways to get it :-)

What problem are you having specifically?

Ohhh btw the latest versions only work on 101 and 101+. Use 102.rc3 for best results. On May 31, 2016 9:38 AM, "eronoobos" notifications@github.com wrote:

Oooops. It already in theory does what you suggest. However, the only time it looks for new points to capture is on UnitIdle. I.e.: the units go out to capture the first point, get there, immediately check for the nearest uncaptured point, which at this point is still the point they are on, and never check again. I'll add a periodic check. I'd debug this myself, but I can't get Evo to work on Windows, and my Linux setup is a wip atm.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eronoobos/ShardSpringLua/issues/6#issuecomment-222746291, or mute the thread https://github.com/notifications/unsubscribe/AAWjsnAreuIdwCYJgJ-b7suvakrc8Wk0ks5qHGP9gaJpZM4IpN-z .

[eronoobos]

I don't think it's the dependency problem, because I've downloaded it with that rapid tag. It's...

[f=-000001] Loaded widget:  Map Info            <gui_mapinfo.lua>
[f=-000001] Error: Spring 101.0.1-353-gb82bb12 develop has crashed.

the infolog is supremely unhelpful about whatever is happening :-( it also tells me

[f=-000001] Error: (0) C:\Windows\SYSTEM32\ig7icd32.dll(RegisterProcTableCallback+0x3866e2) [0x51A2FE02]

and

[f=-000001] Error: (26) C:\Users\zoggop\Documents\My Games\Spring\engine\101.0.1-353-gb82bb12 develop\spring.exe(skirmishAiCallback_Cheats_setEnabled+0x6bf90) [0x00855DE0]

the last one is especially confusing, as there are no skirmish AIs in the game

[eronoobos]

i have linux again, and now...

[zoggop@aseck bin]$ ./pr-downloader spring-features:stable --filesystem-writepath ~/.config/spring/
pr-downloader 0.7-323-g6836bc6
[Info] Using filesystem-writepath: /home/zoggop/.config/spring
[Info] Found 22 repos in /home/zoggop/.config/spring/rapid/repos.springrts.com/repos.gz
[Progress]   0% [                              ] 0/0 
[Error] ../../tools/pr-downloader/src/main.cpp:188:main(): No file found for spring-features:stable
[Info] Download complete!

also--and this has nothing to do with you and is totally off-topic--for the love of god, why is springlobby's "Download Archive" different from pr-downloader?

[eronoobos]

getting evo:test gives me the game, but not Spring Features

[ForbodingAngel]

I would suggest using my download menu for pr downloader on windows. It frees you from needing to know specifics: https://drive.google.com/folderview?id=0B25BbZxm93S9WU5tOWNkZGpleE0&usp=drive_web Put the bat file next to spring.exe and pr-downloader.exe

https://i.imgur.com/hVw2Hjv.png

As far as SL, I have no idea, if you want to use a lobby to autodownload stuff, use SWL's download function, it uses pr-downloader: https://415a950abc581c1790471984449656708f118b03.googledrive.com/host/0Bys6k7VMCRfUZ0N5MGJXR1pRV2M/

The mapinfo thing is likely to do with a missing dependency error.

[eronoobos]

for some reason it works if i use --rapid-download spring-features:stable basically, i don't understand pr-downloader or rapid

[eronoobos]

omg a menu! something besides opaque lists of seemingly redundant command line options! will try when i'm back in windows.

[ForbodingAngel]

Yeah, I made that menu eons ago. Too bad it's only for winbloze. It would be nice if something were done in python to mimic it. Technically I could do it in python, but frankly, it's too much work lol.

[eronoobos]

https://github.com/EvolutionRTS/Evolution-RTS/pull/26 the important thing i totally forgot to tell you that you need: https://github.com/EvolutionRTS/Evolution-RTS/pull/26/commits/a5fee4578f4fd4aec522de60ca9d846922a5fbb8

[ForbodingAngel]

Dude it works really well! Thank you! I'm going to do a bunch of testing tonight, I'll let you know what I come across :-)

[eronoobos]

i moved it into the Shard API, the latest pointcapturerbehaviour and controlpointhandler use it

[ForbodingAngel]

Ok excellent! Thanks for all that you've done! :-)

I haven't posted on the forums or made a big deal about it yet because the scoreboard doesn't display bot teams atm. With the way that colors work and how the scoreboard is handled between players on the same team, it's a bit complicated so I'm trying to get someone to help me with it. For regular players it's fine, but playing vs a bot isn't so awesome when you can't see the bot's score lol :-)

Once that is up and going I'll "release" it on the forums. If you want to see it in action beforehand, you can ofc grab the latest git of evo or use rapid evo:test to get the latest commit and take it for a spin.