Change from TeapotWars_2010 Debug to TeapotWars_2010 Release Help

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Change from TeapotWars_2010 Debug to TeapotWars_2010 Release Help


      I need a little help from the experts please.

      I've managed to work through most difficulties in changing from the Debug version to Release version of TeapotWars_2010. It compiles and build without error. The one remaining bug I can't seem to figure out is related to a ScriptEvent during runtime. The ScriptEvent for EvtData_Set_Controlled_Actor::sk_EventType(0xbe5e3388) is appropriately registered. When the event is triggered by the script, the value 'passed in' for the Set Controlled Actor is 0xbe5e3400 which is close to registered GUID but not correct.

      Where does this value live in the script event trigger? If it lives in the code and is 'passed out to' the script, how is it getting mangled? Why does it happen in the conversion from Debug to Release? Has anyone seen this before?

      Suspecting that LuaPlus libraries were at fault I've tried both the Release and Debug versions of LuaPlus libraries with the same results.

      I've been able to repeat this using the code straight out of the repository and changing the build configuration to Release. PlayerOptions.xml sets graphics.renderer to Direct3D 9. Rebuild the 3rd party libraries as Release build configuration. The TeapotWars_2010 Release configuration property page has an error in the Configuration Properties->Debugging in the working Directory field. Change it to "$(ProjectDir)..\..\..\Game".

      Additional information:
      Visual Studio 2010 Express
      Windows 7

      Thanks in advance for your help!
    • This looks suspiciously like the weird truncation issue I was getting with LuaPlus when trying to marshal actor id's. If you look at GetActorId() in BaseScriptComponent.cpp around like 233, you'll see my comment explaining the issue. My best guess is that really large numbers (like those with the most significant bit set) cause LuaPlus to be sad. I fixed it by marshaling a LuaObject rather than an unsigned int.

      The strangest part is that it didn't cause any problems in debug mode, it only manifested in release. It also doesn't manifest in all cases. I never tracked down the exact set of circumstances that causes this issue, but it's not fun.

      Anyway, I'm guessing something like that is happening here.

      EvtData_Set_Controlled_Actor is triggered in ActorManager.lua in the AddPlayer() function on line 132. When you look at EventType.EvtData_Set_Controlled_Actor, is the value correct? If not, the problem is likely when the event is getting registered with the script.

      Take a look at the RegisterEventTypeWithScript() function in ScriptEvent.cpp. The bottom of the function should look like this:

      Source Code

      1. // add the entry
      2. eventTypeTable.SetNumber(key, (double)type);

      Change it to this:

      Source Code

      1. // add the entry
      2. LuaPlus::LuaObject typeObj;
      3. typeObj.AssignInteger(LuaStateManager::Get()->GetLuaState(), type);
      4. eventTypeTable.SetObject(key, typeObj);

      Let me know if this works, along with any changes you might have had to make. If it works, I'll submit it to the repository. I can't directly test it because I no longer have access to VS 2010, so I'm waiting for Mike to get 2013 working.

    • You pointed me to the exact location of the bug. Look at SetNumber. The value passed as 'type' is a double which is appropriate for SetNumber. I believe what I am seeing is some kind of rounding problem. More appropriately would be SetInteger for the GUID:

      // add the entry
      eventTypeTable.SetInteger(key, type);

      This fixed the bug.

      But, as is par for the course in debugging, I fixed one bug and one or two appear. I now need to address a Direct3D REF count problem.

      Thanks for pointing me in the right direction!
    • Great, I'm glad it worked!

      The reason I asked you to do it with SetObject() is because I've had issues with SetInteger() causing similar truncation issues. I'm glad that wasn't the case here.