AF wrote:The ones that are positioned to the upper left of a metal spot are following the behavior I described earlier though
yes, I understand that (correct) behaviour. the second screenshot was meant show the two extractors that are not on metal spots: i.e., the config generates normal spots as well as bad ones.
AF wrote:Some of those look as if they're nowhere near metal spots at all, rather than displaced weirdly.
that's a good point, i'm probably getting the positions from somewhere else somehow.
I had no problems of this kind with NOTA, so c++ part is supposedly working fine. Both static and mobile builders always place mexes where there is metal.
this is partly because i have a feeling my git etiquette isn't very good--my commits and pull requests are awfully freqeuent
i know you're drowning in feature requests, AF, but would it break the engine-agnosticness for shard to provide the metal and energy values of features? a decent guess if a feature has any metal comes to mind (if the name contains the strings "heap", "wreck", or "rock"), but actually knowing would of course be preferable.
It seems I'm already cleaning up after myself with regards to unit events for friendly units. There is an aliveUnits container that's tracked and filled and then unfilled as units are built and die. My initial hunch was wrong
I believe the true source of the problem lies in the get friendly units APIs. These APIs return engine unit objects that I've not wrapped. I need to wrap these to send them to the Lua AI, but they aren't tracked after that. I don't know if the engine API manufactures these objects on the fly or if they're a part of a persistent list. It's difficult to know when you don't have a set of API headers to reference
CSpringunit now attempts to delete the engine unit in its destructor
New items:
A get unit by ID call was added to the game object, e.g.:
Next engine build may have an enemy created, damaged, and dead event
Blockers and things needed:
I need the vagrant environment fixing, I still can't do a full build of the spring engine with it, though it does start the build process. I simply don't know what I'm doing now, and I need help from someone who has gotten spring building under Ubuntu succesfully
Trying to build under OS X Mavericks with the GCC issues was nightmarish last I tried.
Documentation on the CMake commands or a pointer to where I can find them. It's frustrating that there's a command to build the AI headers but the only way I know how is by building the entire engine. I would rather not have to go on a great wild goose chase googling and hunting through forums and wiki to find it every 4 months
AI API documentation. Even if it's an uncommented list of objects and their methods, this would be a vast help. It means i don't need to pull up a dev environment to answer a question or check something, I could do it on my phone. A basic doxygen or Github repo that holds the build output of the AI headers somewhere that can be read would be invaluable
AF wrote:Documentation on the CMake commands or a pointer to where I can find them. It's frustrating that there's a command to build the AI headers but the only way I know how is by building the entire engine. I would rather not have to go on a great wild goose chase googling and hunting through forums and wiki to find it every 4 months
~/dev/git/spring git::master
❯ make help
The following are some of the valid targets for this Makefile:
... all (the default if no target is provided)
... clean
... depend
... edit_cache
... rebuild_cache
AF wrote:I believe the true source of the problem lies in the get friendly units APIs.
what about get enemy units? you just added the handling of enemy unit deaths, i see. before you made those changes, did the enemy unit objects ever get deleted?
The event and the request for friendly/enemy units aren't the same, I need to investigate further if the API creates new unit objects, or if it has a store of them somewhere
You've added a lot of new behaviors, though they're not using the behaviour system I implemented and are directly in the unit handlers etc, and instead of implementing the Shard API using Spring APIs, you've sidestepped that out entirely by using the Spring API directly. The build placement file could be backported into native vanilla Shard with a little work, I'm not sure how Zoggops work differs exactlyas i've not been through it for comparison
looks like raaar's build plan checking is more efficient, but only checks for overlapping build plans of the same unitname. also buildsitehandler is intimately linked with turtlehandler, which keeps track of where to put defenses.
anyway, all this work you've done, raaar, makes me tempted to convert the BA config into a lua ai, too.
Intending to play a bit with shard on an ai for Evolution RTS.
Got the game going (from SpringLobby 0.182), loading bots (twice shard), and running in spectate mode.
However, no movement happens in-game.
This seems (to my currently very limited understanding) to be the case on maps with metal spots.
Could get full blown behaviour only on map "Trololo" so far - soon not much fun anymore :D - which accepts metal extractor building on its whole surface).
Alernatively some movement by bot controlled units can be triggered by initially loading the game including one human player, then briefly attack bot controlled idle unit which then will start building some defense and more. Still, I think, proceeding this way, no metal extractor get built by bot controlled units at any point.
Diving into lua files (as opposed to the C++ ones) so far, I got to the point that:
in ...\Shard\dev\ai\taskqueuebehaviour.lua
function TaskQueueBehaviour:ProgressQueue()
success = self.unit:Internal():Build(utype,p)
does get called attempting to build a unit of type "emetalextractor" at a valid position according to the function MetalSpotHandler:ClosestFreeSpot(unittype,position)
in ...\Shard\dev\ai\spothandler.lua
So that Build(utype,p) returns True, nonetheless nothing happens in-game.
Anybody can or cannot reproduce this (my test map is AlienDesert), and/or possibly set me on an improved track about it?
I'm not sure the metal placement algorithm that the engine provides is going to run well on metal maps, I would advise against it unless you put in special measures to detect such scenarios, but I don't think that's possible short of maintaining a list of metal maps or analysing and picking up the borked engine spots
