New C++ AI Interface

[hoijui]

cmake can generate VS project files.

[AF]

I have to use this stuff in an environment where cmake is not available

Hence the visual studio requirement.

edit: that and I dont know what commands I would use to generate the wrappers and visual studio projects anyway. I'm on my home machine atm though it shouldnt require jumping through hoops when the legacy wrapper and C API use the same generation mechanism but dont require all this. I've installed gawk but I dont know what to do with that either

[hoijui]

Neither the C Interface nor the C AI Interface plugin need/use AWK.
what relies on AWK:
* Java AI Interface (plugin)
* Java OO Wrapper
* (New) C++ Wrapper

on windows, awk.exe/gawk.exe should be in your PATH, or under mingwlibs/bin (at least for MinGW, but it should also work otherwise, for awk).

[AF]

Using the new C++ interface, Ive found if you pass in a unit type to closestbuildsite that si invalid it crashes the engine, whereas before the new C API it would not crash adn instead return UpVector.

How would one check for this? In the past one would merely do an if(unitdef){ docall} on the unitdef pointer.

[hoijui]

lets see how it works in pureint first.
its pretty far by now, only the Python AI Interface needs porting.

[AF]

hmmm, how would I check beforehand though? I'd rather avoid the cost of any overhead and keep as much of my AI in Shard land for debugging purposes than to be hopping here there back and forth over the dll boundry

( That and the pureint branch would require a new spring release, whereas my need is here and now )

[hoijui]

with unittype, you mean unitdef?
this is called inside springai::Map::FindClosestBuildSite():

Code: Select all

unitDef.GetUnitDefId()

i don't know how you end up with an invalid UnitDef, but i can't debug this.
if the problem is inside the engine, then it would also need a new release.

[AF]

Indeed, until then I can check beforehand and never call the engine if I have invalid parameters to pass.

Namely whenever someone misspells a unitname in Shard, then attempts to find a location to build it, the engine crashes inside closestbuildsite. The only logical explanation is an invalid unitdef structure caused by attempting to retrieve a unitdef for a unitname that has been misspelt.

[gajop]

Namely whenever someone misspells a unitname in Shard, then attempts to find a location to build it, the engine crashes inside closestbuildsite. The only logical explanation is an invalid unitdef structure caused by attempting to retrieve a unitdef for a unitname that has been misspelt.

I'm just guessing here, since I didn't bother to look at your code, but you probably have some mapping of std::string -> UnitDef or similar. It could be that since someone misspelled the name of the UnitDef you aren't getting a valid UnitDef? Are you checking to see whether the spelled unit exists in your mapping?

[AF]

Code: Select all

IUnitType* CSpringGame::GetTypeByName(std::string typeName){
	std::map<std::string,CSpringUnitType*>::iterator i = definitions.find(typeName);
	if(i != definitions.end()){
		return i->second;
	}else{
		return 0;
	}
}

When I ask the engine for a unitdef providing a unitname string, it returns a unitdef object that is invalid. Is it safe to assume that the returned spring::unitdef pointer is a null pointer?

[gajop]

i glanced over your code from git, and from what i understand you never check to see whether it's a null pointer, eventually ending up sending it as a null pointer to lua
is that what you intended to do? i have no idea how swig handles c++ -> lua transitions of null pointers, does c/c++ null become nil in lua?
further, on a quick inspection, i'm not sure whether you're checking for nuill on all places, f.e:
http://github.com/Tarendai/Shard/blob/m ... ur.lua#L28
http://github.com/Tarendai/Shard/blob/m ... ur.lua#L46
(there are more examples, but you got the idea)
i'm assuming that one of those lua Build() or CanBuild() functions is asking for a misspelled unitDef causing an engine to receive a null pointer and crash, but i could be wrong ;p

[AF]

closestbuildsite is where all the crash reports sent to me have been, and my local copy has checks I havent pushed to github yet

Eitherway those are lua files, and Shards lua doesn't have access to the unitdef internals of those objects

In the meantime, there is error detection in the form of:

http://github.com/Tarendai/Shard/blob/m ... ur.lua#L87

Which should have caught it, but Ill have to look at how null is transferred across swig as you said

edit:

One final note: if a function returns a NULL pointer, this is not encoded as a userdata, but as a Lua nil.

Code: Select all

> f=example.fopen("not there","r") -- this will return a NULL in C
> print(f)
nil

http://www.swig.org/Doc1.3/Lua.html

[gajop]

Well the two parts I mentioned are just string literals so that isn't getting checked anywhere before it's called, which might cause a problem.
But anyhow, it would be great if you could show some error logs you were sent to better pinpoint the source of the problem.
oh and btw, this is also one case:
http://github.com/Tarendai/Shard/blob/m ... ur.lua#L29
Other than that, I can't be of much help, all other references to unittype seem to be checking to see if it's nil, maybe whoever is complaining is running an older version?

[AF]

There are checks already within Shards C++ portion meaning s would return false, and it is assumed that the string is good to go anyway because it is game specific