Send playercommands through Lua

Bug #1801722 reported by Benedikt Straub
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Won't Fix
Wishlist
Benedikt Straub

Bug Description

There are situations when a scenario may want to take action on a player´s behalf. The options are currently quite limited there. It should be possible to create and send all PlayerCommands from Lua scripts.

Tags: lua
Revision history for this message
GunChleoc (gunchleoc) wrote :

Please make a list of the commands that you'd like to use so that we can start with those.

Revision history for this message
Benedikt Straub (nordfriese) wrote :

The features I´m missing most are:
· Attacking an enemy militarysite
· Dismantling a building
· Changing InputQueue capacities and priorities
· Changing SoldierControl capacity
· Sending individual soldiers away
· Kicking out a worker from a building
· Militarysite prefers heroes/rookies
And might be nice in the future
· Sending a geologist to a flag

The reason why I´d like this is that the AI absolutely has to meet certain expectations in fri03 and it´s not behaving at all as I want it to, so I´m thinking of using an empty AI and implementing my own micro-AI tailored especially for that scenario as a lua coroutine…

Revision history for this message
Benedikt Straub (nordfriese) wrote :

Forgot to mention:
· Start/Stop building
· Enhance building
And for the future:
· All actions that can be applied to an expedition ship (change direction, build port, etc)

Revision history for this message
Benedikt Straub (nordfriese) wrote :

Since I want to continue scripting fri03 soon, I´ll just start implementing what I need

Changed in widelands:
assignee: nobody → Benedikt Straub (nordfriese)
status: New → In Progress
Revision history for this message
hessenfarmer (stephan-lutz) wrote :

Hi Nordfriese,

great idea to have more options in lua. I could use some of this stuff for empire 05 as well.

But implementing AI in lua isn't a very good idea I think cause in my experience lua is consuming a lot of performance especially if you wan't to check a lot of nodes in loops. I had this issue already in empire 04 by just checking the map for enemies presence. So as long as we still support low res to be able to run on netbooks we should be very careful about performance.

Just out of curiosity what is the desired behaviour that isn't delivered by AI currently. Perhaps we could tune the AI in the direction you need and help it from time to time in special occasions by using lua commands. Perhaps we could even improve the AI Algorithms with your Micro AI inventions

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

by the way the playercommands branch is empty due to a Launchpad bug probably. Perhaps uploading a new revision could solve this, if you would be so kind.

Revision history for this message
Benedikt Straub (nordfriese) wrote :

Uploaded a new revision to fix the LP bug.
In my first attempt of creating a basic luaAI, it started to consume 8GB of RAM within one minute… Now I run the garbage collector after every run of the main loop, which is slower but fixes that problem. The main slowdown now is caused only by the necessity to search the entire map for road optimizing, but I already have an idea how to fix this. This will make my AI very fragile regarding human or script interfering, but as it´s only for this scenario, so well. I guess my micro-AI won´t be much worse than a long game on a huge map when it´s ready.
The reason why the default-AI *shouldn´t* be trained to behave properly in fri03 is:
· It should be super-aggressive, reckless though not to the point of foolishness
· Lots of normally important buildings are obsolete, therefore basic economy and mining is impossible
· It´s in "cheating mode" by getting free wares and soldiers
· The permanent nearness of unguarded enemy borders confuses it
· …
I´ll do my best to keep the performance up (e.g. by inserting short sleep statements into long loops, that makes the AI a bit slower but the game much faster), then the normal AI won´t be needed here…

Revision history for this message
Benedikt Straub (nordfriese) wrote :

I pushed a fix now that makes the AI much much faster. The game runs fluently (with only one out of two AIs enabled, and slowed down to 300x slower for testing purpose…), and the garbage collector isn´t needed that often anymore. Performance will not be an issue :)

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

Thanks for the explanation.
Some quick thoughts:
1. aggressiveness - current AI is already much more "triggerhappy" than the old(b19) one. In my opinion your design goal is exactly what we should aim for the normal AI, as it is easier to relive this for easy AI.
2. What about giving your scenario players the necessary buildings (as described in your scenario basic economy tables) by player command at start up. (placing the constructionsites probably) and afterwards declare basic economy reached by lua command. After that the AI will build according the normal neededness. Not needed buildings could forbidden for this player.
3. cheating could be done by scripting at regular intervals.
4. Last point I don't really understand. But again we should aim for the normal AI handling this situation better.

Anyhow I am only mentioning this to possibly help you avoiding a lot of work. But feel free to continue I am very interested in your developments and would offer myself for testing. Your scenarios have been a lot of fun so far.

Revision history for this message
Benedikt Straub (nordfriese) wrote :

1) It´s *much* more triggerhappy than in b19, which I frequently discover to my disadvantage in normal games :D But even so, it´s a bit reluctant at times and prefers to wait until it is almost certain of victory (or really desperate). But my AI player can afford to take chances, as he cannot be defeated (thanks to a "guardian angle" script that saves it from too-good players ;) )
2) It´ll be a waste of resources if they get a whole mining infrastructure for no purpose. Worst of all, no mines can be built on the whole map, which will necessarily make the AI very unhappy…
3) The AI already does get some nice cheats – if I give it more, there´s little difference to scripting my own ;)
4) Yep, it should definitely handle that better. Current situation is that it builds no militarysites whatsoever…

And it´s not really that much extra work – on the contrary, I´m enjoying it! My AI is shaping up nicely, it already works pretty well: it can build (and upgrade) a defined set of basic buildings, expand with militarysites, launch attacks (untested), and design a pretty good road network. I´ll next teach it to finetune it´s economy, and then some military strategies.
Performance is not an issue anymore, the gc has to run more often than normal but not very noticeably.

Testing would be very much appreciated – this is 99% untested, as I never got further than the first objective so far because it then depends on the AI behaving as I want it to. (I don´t know yet whether it already behaves as it should now.) You´ll need to compile the lua_playercommands branch and run the scenario (fri03 branch) from there using --datadir …
By the way – fri04 (in the fri03 branch) is already complete :)

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

Ok first of all if it is fun for you I didn't want to take this away from you.
Anyhow it might be the case you got me wrong. I just wanted to show you a way to achieve your goals with the normal AI if this might have worked for you.
So for the aggressiveness I think we agree about current Ai state. My thought was it shouldn't be far from your expectation.
for the economy I clearly see your problem my solution for current AI would have been to avoid unnecessary / unbuildable buildings by forbiddinng them. Script all basic buildings for this scenario (the ones the Ai does really need to survive and build other buildings) and set the Ai manually to basic economy reached mode. In this mode the Ai should theoretically only build the allowed buildings based on economical / military needs (of course with the current limitations). So mising mines should be no problem with this setup.
necessary cheating for the AI player coud be easily controlled via script in this modus. which leaves the weird military behaviour at unguarded borders as a real problem, and it is definitly one of my most important goals for b21 to improve that.

But this just for explanation what where my thoughts how this could probably be achieved without having your own AI. However if your AI is developping a nice road network we should have a look if we can't implement this to the normal AI. From a quick look into your code I got the impression you are using the routing algorithm for wares to find a suitable road. If this is the case that is what I had already in mind for the AI cause the wares routing uses an A* algorithm while AI roadbuilding doesn't. if it won't bother you could you attach a screenshot of the developed road network to this bug? Unfortunately my c++ knowledge is very basic (just enoiugh to understand what is going on in the code) so I am afraid I couldn't implement it myself. Maybe I could point you to the relevant code block If you might consider risking a quick look?

Revision history for this message
Benedikt Straub (nordfriese) wrote :

The main difference between the C++-AI´s roadbuilding logic and mine is the way candidates for new roads are found. I´m not sure what the c++ AI does, but I check for flags that are physically close to each other but far apart for routing purposes. Other than that, the algorithms are similar (I think).

This screenshot is an example what this looks like for the barbarian AI. Not very much better than the c++ AI in a normal game yet, but not worse either, at least in the beginning. I especially like the super-fast decision-making, because this resembles my own gameplay ;)
The greatest problems now are that space-consumers (reed yards, farms) are not taken into account (yet), and that useful but suboptimally placed roads aren´t removed.

I´m completely unfamiliar with the AI code. I looked at it once and found it super-complicated. Here´s the reason why I want to avoid interfering with the defaultAI from lua by e.g. pretending that the basic economy is complete when it´s actually not. That would make the scripting very fragile for future AI changes. A scenario shouldn´t rely unconditionally on the hardcoded AI displaying a particular behaviour…
If my (memory-hungry!) algorithms do perform significantly better than the C++ AI, then they could be integrated into C++, but that would be a job for devs who really know that code. And let´s wait until everything is complete before judging whether it really is that good :)

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

Just saw you went on for implemtning this in c++ now. I will try to get the Normal AI tricked to work on this map tonight. I'll report back my experiences. I still think with the playercommands the normal AI should be capable doing what you want.

Revision history for this message
Benedikt Straub (nordfriese) wrote :

I´m now writing this as a standalone C++ AI designed to closely interact with scenarios by providing a scripting interface. This gives better performance (I hope) and much higher flexibility for other scenarios, as my Lua AI was designed specifically for this one scenario.

My branch still contains a bunch of lua methods for playercommands though, which will certainly also come in handy sometime, though perhaps not for fri03…

Since this map has some very special conditions, it is not playable without scripting (no minable terrain and no rocks), so there´s no point training the normal AI with it IMHO.

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

I wasn't talking about training. From All I saw what has been implemented in fri03 so far, I believe the normal Ai should be able to handle the scenario well if brought out of basic economy mode which I believe I can manage by scripting.
If I will be successful with this you could evaluate the result and decide what to use.

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

Ok I did some tests now running your scenario with the normal AI.

First of all I saw your problem ;-) The Ai is not expanding into territory completely owned by an enemy (even if not guarded). This is a definitly bug! (will prepare a bugreport after this post)

I did a quick and dirty fix (needs definitly to be polished) and with this fix the AI did expand properly. Only thing left is basic economy problem but I have a solution in mind for this as well.

for testing purposes I took the forbidden buildings out of basic economy manually. And the Ai was doing properly.

One observation was that the barbarian Ai did not get supplied with either grout or even better coal so it will stall due to no grout available see screenshot

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

ok the coal should be manged by building charcoal kiln probably, but by this the AI gets slowed down.

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

At least this nis good for finding bugs in the AI. found a new bug regarding the economy. with that cured I really get close to the Ai working for this scenario.

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

Hi Nordfriese,
branch with my AI changes is now under review I would like your opinion on this changes whether they could help you so you could try to test fri03 in this branch (AI-fixes), if your time allows. We won't add fri03 with this branch I just added it there to evaluate my changes. Therefore I would wait for your feedback before merging this to give you the chance to test before deleting all the stuff.

Revision history for this message
GunChleoc (gunchleoc) wrote :
Changed in widelands:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.