TGB Editor Enhancements

#1 1) very good suggestion, though I'd go a step further and suggest we add more tools for the collision poly editor, like snapping, alignment, etc.

2) The problem you are mentioning is't that it's removing the lines, it's that when you save your level the level file is completely re-saved out which the end result is removing commented lines since the file is completely resaved.

Thanks for your suggestions :)

#2 2) Maybe the editor auto-saves on test but I will occasionally comment out a line in a text editor, load up TGB and immediately test the level. Once I do that the line in the level file disappears, even though I didn't explicitly tell it to save.

Not sure if this is different for other platforms but I get it on OSX. :)

#3 2) You can't edit the .t2d file in a text editor while TGB is running. The level is loaded in memory and is dumped from memory each time you run it or exit TGB. This means the changes you make in a text editor are never used when TGB is actually running. It also means if you change the .t2d file directly while TGB is not running, then run it and load and run the level, it will load the level into memory, then dump the memory back out to the file just before running it. Since comments are not loaded into memory they disappear when this save happens. It's the same on all platforms. I wish I could offer you some workaround but there really isn't one. The same is true for gui files if you're going to edit them in the gui editor. The coments inside the auto-saved gui object are going to be lost. If there is something you want to comment out of a .t2d file you'll have to save that code elsewhere and paste it back in later. Think of the .t2d level files as never having been meant to be edited by casual users. It's really supposed to be read and written by the editor. You have the freedom to edit it yourself but you have to take extra care. I've often wished it wasn't so, but I've learned to accept it ;)

#4 I, too, have noticed the difference between TGB's handling of .gui and .t2d files.

In the former, your own code can be placed outside of the delimiters

//--- OBJECT WRITE BEGIN ---
new GuiChunkedBitmapCtrl(mainScreenGui) {
...};
//--- OBJECT WRITE END ---

and Gui Editor will preserve it. Not so with Level Editor and its .t2d file.

My suggestion would be to change Level Editor to work like Gui Editor with respect to these OBJECT WRITE delimiters. One could well ask, "Why do one and not the other?"

#5 .t2d levels are never expected to be written to manually, which the original "best practice" in core Torque was to allow you to do so in .gui files (mostly for code organization--you would create your gui's in the gui editor, and then script them in the same file so your gui handling scripts were easily locatable).

Note that .gui files are simply exec'ed, while .t2d files are more simple data files that are used as part of loadLevel.

It's just a change of "best practice", and the proper comparison would be to compare .t2d files to .mis files in core Torque--which do not expect to be written to manually either (although I admit you can get away with it iirc).

#6 I wrote:

Quote:One could well ask, "Why do one and not the other?"

Stephen Zepp wrote:

Quote:
.t2d levels are never expected to be written to manually...
.mis files in core Torque...do not expect to be written to manually either

This answers my question with the answer "because that's the way we designed it". Stephen writes further:

Quote:mostly for code organization--you would create your gui's in the gui editor, and then script them in the same file so your gui handling scripts were easily locatable

Indeed, yes. And how nicely it works.

Now, let's suppose that my level file (.t2d) has an object in it that uses the "class" member field.

class = "MySceneObject"

Would it not make sense for me to want to put the definitions of methods of that namespace in the same file, for the sake of "code organization...so your (scene object) handling scripts were easily locatable"?

I have looked at the code that loads the level, in ./common/gameScripts/levelManagement.cs:

function t2dSceneGraph::addToLevel(%scenegraph, %levelFile)
{
...
   // Load up the level.
   exec(%levelFile);
...
}

I'm just not seeing the difference from main.cs's exec("~/gui/mainScreen.gui"). Help me here, what am I missing?

I am thinking that the real reason for the difference has to do with the very beginning of the .t2d file:

%levelContent = new t2dSceneGraph() {
   canSaveDynamicFields = "1";
...

I'll bet that a .gui file is saved to disk using SimObject::save(), whereas a .t2d file is written using other means: loading a level is difficult without that %levelContent local variable to horse around with. By the way, this could be fixed if exec(); would return a value-the value of the last statement in the file being exec'ed.

#7 The overwriting probably takes place in the saving, not the loading. Though I can understand why you might want to put scripts inside the level file, to me it makes a lot more sense to keep those in your game scripts and keeping your game levels on there own. GUIs to me are the exception, since those can be fragmented much smaller I would rather write scripts in them, though considering how big level files get it wouldn't make much sense to attach more data to that one file.

[quote]which do not expect to be written to manually either (although I admit you can get away with it iirc).[quote]

Stephen is correct, though you can manually write to t2d level files, you just can only write to the level contents, not attach scripts beyond the level file, like GUI files.

#8 Maybe the best practice is to never hand-edit files that TGB edits. This means .gui files as well.

When writing code, I prefer to follow the "one class per file/file name = class name" rule. It's so much more tidy.

One thing is for sure: it's dangerous to not understand what TGB is doing. ;-)

#9 @Arthur: I understand why you might want to have scripts in your level files but I suggest placing a normal script file with the same name into the level folder for your scripts and load it manually when you load the level. Level files can get VERY big and making small changes to your scripts in such a huge file can be a pain in the ass. If you search the forums though, you can find a code change which lets you edit level files like GUI files but this is very old stuff...