Unable to view source files
nbonfiglio
Join Date: 2007-10-16 Member: 62658Members
in Decoda
<div class="IPBDescription">All loaded lua files are named something like "@UntitledX"</div>First off, thanks for the amazing lua debugger...before this problem started occurring (pre 1.08) Decoda worked really well and has been amazingly useful.
Our project had a little snafu whereby the version of the game client that used Lua as a DLL stopped building. Once the Visual Studio project was repaired, version 1.08 of Decoda will start the project, but does not load any source.
The Project Explorer displays all file names as something like "@Untitled#.lua" and when the file is opened it displays a relative path to a Lua source file.
So, for example, the Project Explorer might display @Untitled15.lua, which, when double-clicked, will open a source file with the line Interface/Default/SomeDirectory/SomeFileRealName.lua
The relative path is correct. I also believe the project settings are correct, because the game client starts properly from Decoda. Is there an additional directory required in the project settings aside from "Command" and "Working Directory"? Should the "Working Directory" contain our version of the Lua dll?
The whole problem could be resulting from the way that our Lua dll is built, or the way that our game client links its import library. Is there any documentation on how to use Decoda when the Lua VM is statically linked into the game client? Since we're building our own client, we have all the necessary PDB files...do I simply need to fill out the "Symbols Directory" in Project Settings?
Any tips are much appreciated since our eval copies worked great, and now we've actually purchased licenses for the product.
As a side note, when I paste the license key into the "Trial expired..." dialog, Decoda only remembers the license for one session. After closing Decoda, I must re-paste the license if I want to run it again.
Thanks,
Nathan
Our project had a little snafu whereby the version of the game client that used Lua as a DLL stopped building. Once the Visual Studio project was repaired, version 1.08 of Decoda will start the project, but does not load any source.
The Project Explorer displays all file names as something like "@Untitled#.lua" and when the file is opened it displays a relative path to a Lua source file.
So, for example, the Project Explorer might display @Untitled15.lua, which, when double-clicked, will open a source file with the line Interface/Default/SomeDirectory/SomeFileRealName.lua
The relative path is correct. I also believe the project settings are correct, because the game client starts properly from Decoda. Is there an additional directory required in the project settings aside from "Command" and "Working Directory"? Should the "Working Directory" contain our version of the Lua dll?
The whole problem could be resulting from the way that our Lua dll is built, or the way that our game client links its import library. Is there any documentation on how to use Decoda when the Lua VM is statically linked into the game client? Since we're building our own client, we have all the necessary PDB files...do I simply need to fill out the "Symbols Directory" in Project Settings?
Any tips are much appreciated since our eval copies worked great, and now we've actually purchased licenses for the product.
As a side note, when I paste the license key into the "Trial expired..." dialog, Decoda only remembers the license for one session. After closing Decoda, I must re-paste the license if I want to run it again.
Thanks,
Nathan
Comments
If you load your file using your own methods, do not use luaL_dostring or luaL_loadstring, instead use luaL_loadbuffer and the 4th argument should be the file path.
Interesting...apparently we were already using luaL_loadbuffer to load our lua scripts, however our paths are relative. This fact applies regardless of whether or not we're running raw files or from our own '.pak' file format.
I wonder if the relative paths are throwing Decoda (or LuaInject.dll) off and preventing the actual path from being found. This looks like the case because the relative path is actually displayed as the contents of the "@UntitledX.lua" file.
I'll do some more experimentation to see if prefixing the name parameter with a hardcoded path will work.
Thanks for the tip,
Nathan
...after some quick experimentation, that hack didn't allow me to view source code, however, it did change the file path that was displayed in Decoda (as a result of opening the "@UntitledX.lua" file in the Decoda editor.)
Maybe this is a step in the right direction, but so far the problem still exists. I'll keep messing around with our calls to luaL_loadbuffer. Thanks again.
luaL_loadbuffer ( lua_State, buffer, bufferSize, "myfile.lua") ;
You want
luaL_loadbuffer ( lua_State, buffer, bufferSize, "@myfile.lua") ;
~ Christopher.
That is the most random thing ever...but it appears to help. When I start the debug process from Decoda all the file names are displayed in the Project Explorer as they load...unfortunately, when I double click them to open then in the Editor, I receive this message:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->The source code for this script is not available. To view script source code,
the script file must be added to the current project, or the debugger must be
attached when the client loads the file.<!--c2--></div><!--ec2-->
So...I went and added a bunch of existing source files to the project. Then I could see their source code. Joy. And then I set some breakpoints, which proceeded to not be hit because the debugger wasn't attached...or so it would seem.
Everything in the Decoda interface looks nominal...my Output window displays that the debugger is attached, that a VM is created, and I have the address of the VM that's running.
Maybe if I add every file to the project and save it, then restart Decoda so that it knows where the files are supposed to be I will have more luck...giving that a shot.
Thanks for all the suggestions, and the tip about '@', Christopher...I have no idea how you came up with that one, but it definitely appears to be a step in the right direction.
-Nathan
Lua adds the @ sign in front of the file name when you call luaL_loadfile to create the name passed into luaL_loadbuffer, so that's why Decoda uses it to determine if the name is a file name.
I'm not sure why you are having those other problems, but I'll look into it.
[Update #1]
I've done the following:
- changed my script so that it is in the same directory as my application
- added the script to my lua project
- changed the calling convention for the script to call it by fully qualified path name
So now when I debug the script it still soft adds a second copy of the script to my lua project. The copy and the original show up with the exact same path and file names, but the copy only contains the "unavailable" error message.
Not sure that this helps, but its as far as I've been able to get with this problem.
[Update #2]
After tweaking with the my application a bit more, I've found that if I load the script manually and use luaL_loadbuffer then I can debug just fine. The only problem is that if I include other files using "require" then they cannot be debugged.
I would really like to use this product for our team, but it just cannot load files. Is this a problem with linking against the LuaBinaries distribution? Or possibly with version 5.1.4?
[Update #3 - Solved]
OK. I finally got everything working, so I figured I would post the solution here for anyone else who has similar problems. My solution is more of a work around, but it DOES work. First I converted all my load commands in C++ to use luaL_loadbuffer, then I had to write a replacement method for Lua's "require" in C++ and expose it to Lua. After changing all my scripts to include files in this way Decoda works perfectly.
Thanks to the Unknown Worlds developers for this awesome tool. I'm looking forward to purchasing multiple copies for my team now <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" />