but i'm unsure if this works, it sounds a bit like you'll get the same result with all files replaced, as there was never something like an endless-loop in shard if i remember right.
if you still get the error, please post infolog.txt (at least some parts of it).
Other than deleting the lua files Shard uses and replacing them with those in git master there's not much I can advise you to do at the moment. An Infolog may help but it's unlikely
Since you're using an unsupported build from a build mechanism I have no copy of locally, I can only speculate. It's like buying a Honda from a dodgy dealer made of play dough that's identical in every way except the material, then asking Honda what's wrong when something happens.
The message being described should not be on its own, a message declaring Shard is made by AF and being played with evo on map XYZ, not to mention the other modules being loaded, should be reported, but it hasn't
There is no lua based mechanism for this to recur
There is no C++ based mechanism for this to recur as the call is simply passed on from the AI interface
Therefore, one of the following conclusions must be true
Shard is misconfigured Possible, but I'm unsure how this could result in the issue being described. As the creator and maintainer, the only means of doing this would be to manually edit the shard files ones self. Most misconfiguration issues should simply result in a lua stack trace.
C++ AI Interface There have been quirks noted, such as the unitdestroyed event on units blown up sinking into the ground or spiralling to their deaths, but never an Init call every frame. As such this is very very unlikely. Your best way of testing this is by using other AIs. This issue would not just affect Shard and is a grossly disastrous error, one I'm sure others would have reported
A bug in the new engine logging This could be possible, however it is unlikely, the code appears to have been tested and any issues are already known by the engine devs. It also fails to explain why this particular message was repeated every frame, as it is not the usual sort of issue I would expect from a logging framework. As such this is a highly unlikely cause
Miscompilation I build Shard under Visual Studio for windows, and OSX/Linux have the well tested and maintained linux toolchain to work with. I've never tested or attempted mingw32 compilation with Shard, nor have I ever had the urge to ( the nightmares, make them stop noo NOOOOO N...).
As such it is far more likely that Shard is not built correctly, and since I have previous little knowledge on the subject of mingw32, I cannot help you there
Without further information no progress on this can be made. A 53MB log file should be no barrier, there are plenty of tools available, and not all programs will read the file in its entirety to open it. I've opened far bigger files to read the first few hundred lines in my time, and it's far from uncommon. As a linux user it should be especially easy for you
it looks a bit like the swig-generated code fails here... iterating over class() (class() is generated by swig) with ipairs causes the endless loop, but i've no idea why it works on linux and not crosscompiled...
Users browsing this forum: No registered users and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum