Shard 0.4/dev
Moderators: hoijui, Moderators
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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).
So something like unit:IsDetectedByTeam(teamNumber, detectorType = "los") can work (detector type can also be radar or sonar).
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
What about radar blips? How would you prefer to grab those?
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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 likeyuritch wrote: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.
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?
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 wrote:What about radar blips? How would you prefer to grab those?
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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
As a side note, NTai scouted metal extractor spots using units with weapons. This had the bonus effect of basic raiding and harassment
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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?
yeah, that makes senseAF wrote: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
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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
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
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
good idea!AF wrote: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.
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
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
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
hmmm I have a theory, std::vector objects etc not being cleaned up after use, will need to investigate
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
Found anything? Are std::vector objects used for things other than executing custom commands?
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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.
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.
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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?
barring that, basically i should be using Forget() liberally?
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
Forget and Forgotten don't do anything. I'm inclined to remove them.
Instead I think I should do the following:
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
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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)?
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)?
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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.
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.
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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.
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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.AF wrote:Potentially floating point difference, purely a guess, is the accuracy going to cause problems?
and so it does. this was helpful for debugging some issues I had.AF wrote: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.
excellent.AF wrote: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.
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
How big are your extraction radii? Spot locations tend to be the top left coordinate of the spot, not its centre
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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.
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
here are a couple screenshots of the wacky metal spots
- Attachments
-
- screen00122.png
- two false spots
- (1.18 MiB) Not downloaded yet
-
- screen00124.png
- all false spots
- (1.5 MiB) Not downloaded yet
Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey
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
The ones that are positioned to the upper left of a metal spot are following the behavior I described earlier though