Spring RTS Engine

Without a working development environment I cannot debug this. All Shard builds until then are provided 'as is'.

As for the issue, nobody under Linux or OS X has thus reported this issue, and they appear to be far past that stage

@Forboding Angel:

how did you "install" the ai? maybe you've left some outdated lua-files for the ai?

i guess the lua-files for evo-rts are broken... do other games work with shard?

can you please post infolog.txt to pastebin.com?

Abma, there is no working winbloze dll. And no, nothing outdated. Just normal ballsey + new dll.

if it doesn't work, please answer my questions please...


and if you just updated the dll then this was the first mistake... you've to update the lua-files, too.

on linux shard works fine...

point me to a buildbot for 84 pls?

Forboding Angel wrote:point me to a buildbot for 84 pls?

why? i thought you already picked up a build from there.

http://springrts.com/dl/buildbot/default/master/84.0/ + 84.0_Shard.7z

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).

I posted the relevant bit last time. The infolog hit 8mb in 10 seconds. I'll test with the 84 build and see what happens (last one was 83).

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

Complete replace, within 5 seconds infolog became 53+ mb.

Relevant bits:

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.

This is where that is printed out:
https://github.com/Tarendai/Shard/blob/ ... /ai/ai.lua

From this we can surmise:

• This should only happen once, as it's in Init
• 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

this work with de new spring yet?

No

Currently blocked by:

http://springrts.com/mantis/view.php?id=2747
http://springrts.com/mantis/view.php?id=2826

I need an AI. Or Betatesters

@AF:

i investigated the endless-loop a bit:

the endless-loop in https://github.com/Tarendai/Shard/blob/ ... ai.lua#L12 can be reproduced by simplification the function to
modules is defined here: https://github.com/Tarendai/Shard/blob/ ... les.lua#L6

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...

SWIG should have nothing to do with it, because class is defined here:

https://github.com/Tarendai/Shard/blob/ ... /class.lua

If what your saying is correct then horrible horrible things should be happening at runtime, which they haven't in the past.

Modules is defined here:

https://github.com/Tarendai/Shard/blob/ ... odules.lua

Just encase, I'll change the name of that to say, shard_class.

In other news further progress has been made by myself kloot and hoijui with regards to the last issue blocking Shard compiling.

AF wrote:SWIG should have nothing to do with it, because class is defined here:

https://github.com/Tarendai/Shard/blob/ ... /class.lua

damn, i don't know how i could think this is defined by swig...

We could test it by probing the 'class' identifier while the include statement is commented out =p

Super hyper mega uber ultra experimental dll:

AF wrote:Super hyper mega uber ultra experimental dll:

... you released from your phone, right?
good luck!