io error

[pandaro]

in my attempt to use update the maphandler file in order to get more info, i noticed that you have commented the savemapdata and loadmapdata and all line that contain a io.open() callin. So i noticed there are a problem with this callin and ShardLuaAI, i report the error:

Error: LuaRules::RunCallIn: error = 2, UnitFinished, [Internal Lua error: Call failure] [string "luarules/gadgets/ai/BAR/maphandler.lua"]:443: attempt to index global 'io' (a nil value)

My questions is: You can think to fix this? or is lost forever?

[eronoobos]

Saving and loading could be recovered within Spring Lua, but it would have to communicate with unsynced. The thing is I don't think there's much point in doing so. It doesn't save much processing time because the map analysis doesn't take that long. The only other problem saving and loading solves is map analysis having false blocking from in-game units when reloading the AI in the middle of a game. And that should really only happen when we the developers are testing it out.

[pandaro]

It doesn't save much processing time because the map analysis doesn't take that long

i will enlarge the analysis a bit... i will use some sync calls like: Spring.TestMoveOrder() and other calls that can give to shard an idea on what is the better units to do in this map if you have idea about this, please give me! as an aside, the best way to get the mobility capability of a unit is to simulate (calculate a path) from a mobilitygrid to another for each the mobility grids. have you an idea on how do this?

[eronoobos]

what information do you want to get?

i've never tried out Spring.GetUnitEstimatedPath, and I'm a bit confused that it only takes a unitID as a parameter. Maybe it returns the path the unit is already on?

the best way to get the mobility capability of a unit is to simulate (calculate a path)

You made me realize I broke MapHandler:UnitCanGoHere for Spring Lua. Testing the move order doesn't really tell us if a unit can get there. The line that I've linked to should either be removed or replaced with a call to Spring's pathfinder (Spring.GetUnitEstimatedPath?)

[pandaro]

I loose 2 hour of my time yesterday in the attempt to run https://springrts.com/wiki/Lua_SyncedRead#PathFinding but bothing to do... but i have see this page, and i ask me... there is a way to use the luaScripts pathFinder subsystem inside shard luaAI?

what information do you want to get?

example if you use this inside maphandler you get a rank of the units that can go better from a cell of the grid to another... watch the code is more simple than explain and is only a example.

The main concept is: now we have a subset of wonderful callin (lua sync read) and i hope more and more(pathfind,unsyncread), lets use it! Spring.GetGroundInfo Spring.GetSmoothMeshHeight all the los system

[pandaro]

@eronoobos im near to find a nice way to get the real path 1 path = Spring.RequestPath() 2 path, detailpath = path:GetPathWayPoints() 3 path is the table of waypoints, maybe we need only #path, the number of waypoints

[eronoobos]

great!

yes, maybe the number of waypoints is 0 if there's no path? it would make things easier for us if so.

rather than getting paths from each cell to every other cell, i suggest getting paths from each metal/geo spot to each other metal/geo spot. for two reasons: 1) pathing all the cells to each other would be computationally very heavy, i think. 2) the middle point of each cell may not be significant in any way to gameplay.

[pandaro]

great! 1-i try several time to reduce the computational calculation, but to calculate from every path cel to each other i get always out of memory. 2 you reason more significant is from metal and geo to each other

[pandaro]

ok we have a problem we have 24 unitDef.moveDef.name and an analysis of a map like smallsupremebattlefield with 82 spot(geo, land, UW) have a 24 * 82 * 82 calls to requestpath(161376circa); after deleting all the useless or double(from 1 to 2 is the same like from 2 to 1) remain circa 79000 calls that ruin my memory and cause a large amount of errors due to memory. other idea?

[eronoobos]

One idea to simplify the pathfinder-based metric: Navigate the metal/geo spots, as if driving though all of them. Each iteration just pathfinds from the last used spot to the nearest spot not yet used. In your example, that would result in only 24 * 82 = 1968 calls.

I'm not sure all 24 moveDef names need to be tested. Certainly it's more flexible, if this is to be used for any other game. But I think the categories veh bot amp shp sub air, are mostly enough. I suppose another category for all-terrain spiders might be added?

[pandaro]

But I think the categories veh bot amp shp sub air, are mostly enough

this is not the categories, the categories is this, with the relative units:

moveclasses

Navigate the metal/geo spots, as if driving though all of them

No good idea for me. I search the way to reduce the use of memory, but the problem is that i don' have good handling with this type of problem. for now i paste a raw of my function if you want test it paste it inside maphandler: function

[pandaro]

i will suggest we fix the io.open() problem cause we are unable to use the shard debug visualizer inside the LuaAI environment. is hard to do?

[eronoobos]

Using a file as a way to communicate with the debug visualizer widget is itself a workaround. As a LuaAI, it can do this without the file. Implementing file I/O from within the LuaAI would require communicating with unsynced anyway, so unless there's some other reason to do file I/O, we may as well just send the data to the visualizer widget.

[eronoobos]

https://github.com/Tarendai/Shard/issues/98

[eronoobos]

https://github.com/eronoobos/ShardSpringLua/blob/f4b4dba6a949d8cc2cd84f74743d1a73742fe241/luarules/gadgets/ai/preload/spring_lua/map.lua#L163 i haven't converted any of the debug outputs of the BA/BAR config, but this is a better way to show information on the map, i think. C++ implementation of the same map API functions will come eventually