Shard 0.4/dev

[yuritch]

As I understand it, all that's really needed is a function that detects if unit A is in LoS of team B or not. Actual LoS coverage information is not needed for that (but may be useful for other things). Same for radar/sonar coverage.

So something like unit:IsDetectedByTeam(teamNumber, detectorType = "los") can work (detector type can also be radar or sonar).

[AF]

What about radar blips? How would you prefer to grab those?

[zoggop]

As I understand it, all that's really needed is a function that detects if unit A is in LoS of team B or not. Actual LoS coverage information is not needed for that (but may be useful for other things). Same for radar/sonar coverage.

Coverage would useful in that an AI whose vision is limited needs to know where it can't see so that it can scout. (In my current simulation of LOS/Radar for instance, scouts go off of how long ago metal spots were within coverage.) Something like
map:DetectionHere(position) that returns the "highest" detectorType (if los overlaps with radar, it should return "los"). I can't really see why an AI would need to know another team's LOS coverage?

What about radar blips? How would you prefer to grab those?

As a note, Shard seems to return the location of radar blips with unit:GetPosition()? I've noticed it has radar-blippy innaccuracy against targets not in sight. I guess the question is wether Shard should handle ghosting or not.

[AF]

I'd prefer it didn't handle ghosting as someone may have a different idea of how to implement that so it integrates with other things

As a side note, NTai scouted metal extractor spots using units with weapons. This had the bonus effect of basic raiding and harassment

[zoggop]

My config creates a memory leak in Spring--it takes about 20 minutes to get up to 1.5gb, and soon enough that will go up to the 32bit memory limit of 3.5gb. It's definitely a problem with my lua code, because of course the normal Shard dev doesn't have this problem. However, using gcinfo() tells me Lua is only using at most 8mb at any given time. Is there a particular API call I might be using that you think would cause Spring to store tons of data in memory?

I'd prefer it didn't handle ghosting as someone may have a different idea of how to implement that so it integrates with other things

yeah, that makes sense

[AF]

Not that comes to mind but this certainly requires more investigation. Have you tried a process of elimination?

It may be useful to add tracking code to the engine wrapper tables in preload.lua to count API calls and write the stats to a file. It would slow down the API but you could then compare your version to the standard vanilla Shard lua

ps: good news everybody, windows 8.1 overwrote my bootloader, forcing me to setup Ubuntu again, I may soon have a *nix build environment that doesn't crap itself at every opportunity

[zoggop]

It may be useful to add tracking code to the engine wrapper tables in preload.lua to count API calls and write the stats to a file.

good idea!

vanilla after 9 minutes of gameplay:

Code: Select all

5 game:SendToConsole
1 map:GetMetalSpots
4 game:GetEnemies
1 map:MapName
92 game:GetTeamID
85839 game:Frame
25 map:SpotCount
4 map:MapDimensions
94 game:TypeByName
234 map:CanBuildHere
1 game:GameName

my config after 9 minutes:

Code: Select all

28 game:SendToConsole
4979 game:GetEnemies
2 map:MapName
701 game:GetTeamID
2770 game:GetFriendlies
345461 game:Frame
22 map:FindClosestBuildSite
368 map:CanBuildHere
7108 game:GetResourceByName
1 map:MapDimensions
177 map:SpotCount
4131 game:TypeByName
3251 map:GetMapFeatures
1 game:GameName

my hunch is it's the large amounts of GetEnemies and/or GetFriendlies. of course, not counted are all the functions called on units and features.

[AF]

hmmm I have a theory, std::vector objects etc not being cleaned up after use, will need to investigate

[zoggop]

Found anything? Are std::vector objects used for things other than executing custom commands?

[AF]

hmmm, stuff like this:

https://github.com/Tarendai/Shard/blob/ ... e.cpp#L152

Those unit objects are never cleaned up, the main issue being that say unit 5 is created, and gets stored in a lua table, then gets destroyed on UnitDeath, what happens if lua code tries to use that object? It's an object from the C world not the lua world, and an access would result in a crash.

[zoggop]

ah. so there may be no clean way to deal with this. is there some way of adding a prophylactic to Lua's access to C objects, so that it would just return a nil unit rather than crash on the C side?

barring that, basically i should be using Forget() liberally?

[AF]

Forget and Forgotten don't do anything. I'm inclined to remove them.

Instead I think I should do the following:

• Add a map container for unit IDs and unit objects
• Add an API for the creation of new unit objects given an ID
• Add a lua wrapper table that contains the ID and the C object

The last item should facilitate anybody trying to use the gadget API to implement the Shard API.

[zoggop]

I don't entirely understand what you're proposing, but if it fixes the memory leak and/or prevents game crashing from bad unit object accesses, great. Would this change the way the lua code needs to be written (with regard to api)?

On another note, the strangest problem I've been having is metal spots stored in a lua table moving around. This may be entirely a lua problem, but I've noticed that positions (api.Position()) have some inaccuracy in the far right decimal points. 6.12345 becomes 6.1234498023987. I could work around this by storing the positions as tables of integers instead, but maybe this reflects a problem with Shard's std::vectors (assuming that's what positions are)?

[AF]

Potentially floating point difference, purely a guess, is the accuracy going to cause problems? Shard runs unsynced so a desync shouldn't be possible.

The main difference the unit change would cause is that if unit 50 dies in frame 600, and you don't clean up after yourself, bad things could happen, e.g. a crash.

The wrapper I proposed would enable the Shard AI as a framework to handle crash prevention by hooking into and cleaning up C objects and adding a valid or invalid callback so you can check.

[AF]

As a side note, I tried setting stuff up on OS X but as of yet I don't have a build environment. While a lot of the callbacks requested should be simple, without a copy of the generated C++ API Wrapper my commits could fail to compile for such trivial reasons as incorrect capitalisation.

[zoggop]

Potentially floating point difference, purely a guess, is the accuracy going to cause problems?

Decimal-level accuracy shouldn't matter at all as far as metal spots are concerned, I just thought it might give a some clue as to why the position numbers in my metal spot tables are shifting. EDIT: to clarify, I mean they shift so far that any metal extractors built on these supposed spots won't extract any metal at all.

The main difference the unit change would cause is that if unit 50 dies in frame 600, and you don't clean up after yourself, bad things could happen, e.g. a crash.

and so it does. this was helpful for debugging some issues I had.

The wrapper I proposed would enable the Shard AI as a framework to handle crash prevention by hooking into and cleaning up C objects and adding a valid or invalid callback so you can check.

excellent.

[AF]

How big are your extraction radii? Spot locations tend to be the top left coordinate of the spot, not its centre

[zoggop]

right, but these are off where the extraction radius won't catch anything, and not seemingly in any predictable direction either. i'll take a screenshot next time it happens. anyway, it may have nothing to do with shard, just my lua code.

[zoggop]

here are a couple screenshots of the wacky metal spots

[AF]

Some of those look as if they're nowhere near metal spots at all, rather than displaced weirdly.

The ones that are positioned to the upper left of a metal spot are following the behavior I described earlier though