T2dSceneGraph::onLevelLoaded problem

#1 @Marc, are you specifically telling it what level to load when you play-test it from the editor?

in your startGame (or gameStart?) function where it calls "loadLevel()" ... you have to tell it what level to load, otherwise, it doesn't know -- the runWithEditors flag tells the main.cs to pass along down the 'chain' the current ly loaded level in the level editor, if this is not being passed, then a level must be explicitly passed at some point ...

#2 Yes I replaced the preexisting line with the explicit level to load, as the comment mentions that this needs to be replaced with a "game specific" call.
This specific level loads correctly in the editor and the onLevelLoaded is called as the breakpoint and Echo show.
But in the editor free version the onLevelLoaded Callback is never fired on the scenegraph

#3 @Marc, I ran a quick test, and put the following:

function t2dSceneGraph::onLevelLoaded(%this)
{
  error("Level Loaded ...");
}

Into a project, that uses 'runWithEditors = true' ... then did the same with a 'runWithEditors = false', as follows:

main.cs

$runWithEditors = [b]false[/b];
$defaultGame = [b]"LadyBugRun"[/b];
$startupProject = "";
$defaultMods = "";
$editorMod = "tools";

game.cs

%level = "LadyBugRun/data/levels/level1.t2d";
   if( isFile( %level ) || isFile( %level @ ".dso"))
      sceneWindow2D.loadLevel(%level);

And everything worked fine -- note, I made an update to the main.cs in the TGB.EXE directory and changed the 'defaultGame' to point to the one i wanted to load ... and I updated my 'startGame' and passed in an explicit level value --

When you run your game, does the level load and you can play the level ... or are you left with a black screen?

You say "everything gets executed as desired", so I assume the level loads and your able to play --

are you executing the script that contains your onLevelLoaded callback before you load the level?

#4 Cool, that helped.

I found the problem on my end:
There was one difference to yours.
I used ~/data/... instead of /data/... as there was no where pointed out that this is editor dependant (at least I think I've nowhere seen that pointed out)
(default game was set to the projects path etc)

That made the difference and now it works :-)
Thank you very much.

#5 It's not editor dependant, but for some reason the loadLevel method does not know how to translate relative path names -- also, keep in mind, relative path names are rooted at the script they are called in -- so for example:

~/data/levels/level.t2d is relative to the main.cs for the mod
~mod/data/levels/level.t2d is relative to the main.cs where tgb.exe is
./file.cs is relative to the file executing it, ie; called in game.cs, would be relative to 'mod/gameScripts/'

etc, etc, etc ...

When in doubt, always give full path names rooted from the TGB.EXE location --

#6 Yes I know of the relative paths and their usage.
But I didn't think of the possibility that the loadLevel might work differently than the editors load functionality (as it does not make that much sense to me to implement the same feature twice, once working, once "broken" in the same circumstance but I'm sure there is some reason the editor loads the data differently).

But it is just another thing on the list of the "good to know"s after the "special" switch behavior and the ++ operator behavior

#7 Funny switch behaviour? and the ++ behavior? Do tell, what were your issues with them?

And, as for the Level Builder, there is quite a bit that it does "behind the scenes" to simplify the process of prototyping and play-testing, but when it comes time to packaging and polishing up ... or adding nice Main Menu screens that do all the 'work' for you (that is usually left up to the Level Builder when prototyping) ... lots of things change ...

as for the relative paths, I honestly don't know why they left that out of the loadLevel function ... seems quite strange to me, and I've run into this problem before ... there's quite a few threads discussing this odd behaviour.

#8 Hmm. I searched for onLevelLoaded and only found threads and TDN article on that callback on t2dSceneObjects to do single object initialisation stuff. Didn't think that loadLevel was the cause for the problem, so I didn't search for that.

Switch: it reavluates the value you want to switch for each case, so don't use any dynamic stuff like random numbers (there is a thread on that) in the switch statement.
++: even though the page mentions the similarity of torque script to C, it actually breaks that by execute this operator before evaluating the functionality it is used in (its handled as ++a instead of a++ which you write)

Both no issues and I didn't struggle over them but I write such things on my "language specifics" list because I've to work with some strange languages in my study and holding such language specific stuff in my head for all languages is simply impossible :)

Thank you for your help David.

#9 @Marc, yeah ... I've heard about those issues here and there ... was just curious if you had other oddities ;)

You should publish your 'list' on the TDN for the rest of us ... I'm sure it would be fairly useful for quite a few people, especially those of us coming from different development backgrounds.

#10 I'm not sure if I am experienced enough to post such lists as they could lead to wrong assumptions due to too unprecise descriptions.
Another thing is that the whole torque script part is TAP, not TGB only, so it is a very "core documentation" part of Torque in general.

But a special thread on the TGB Scripting board might be an idea so new users have a place to start looking for potential causes of problems.


PS: during checking what of my list is documented *as some mentioned that such behavior is clearly documented* I found out that http://tdn.garagegames.com/wiki/TorqueScript_Quick_Reference ++ -- descriptions are wrong as they state that the increment / decrement happens after the use. But I'm not sure how this could be written in a better way so it clearly states that it works like this for loop incrementation but not for usage within a call that evaluates the value before usage. On the other hand, this is a question of definition of "use" as the function eval call will already use it and in that contect it behaves correctly ...

#11 Not all of TDN is specific to TGB or TGE ... there are shared articles ... and if you start an article, the Wiki aspect of TDN allows others with more experience to correct any misguided assumptions you may have made ... but your list would help lots who are having odd issues here and there ...

And, from reading your posts, you seem to have at least a good grasp of knowledge over what your talking about ... which would be very helpful to quite a few people.

#12 @Marc: I can only corroborate what David says in regards to your "language specifics" list. Please share it with us! We want to see it.

Maybe I'm just foolhardy, but I went ahead and edited the TorqueScript Quick Reference page to reflect the odd behavior of operator ++ and operator --. I also added a note to the TDN documentation for switch to the effect that it evaluates the expression in parentheses for each case statement.

I personally do not consider these to be non-issues: I want the documentation to be more helpful in steering users around the pitfalls.

I'm still trying to understand the issue surrounding t2dSceneGraph::loadLevel(), but it appears that it is a matter of best practices: the programmer should ensure that the path is expanded before calling the function. Otherwise you have to know what .cs file the function definition is in! (There's a console function for this: expandFilename().)

By the way, I altered the introduction of the TorqueScript Quick Reference to read:

Quote:TorqueScript is a typeless scripting language, with similarities in syntax to C/C++. In TorqueScript, you will find that most C/C++ operators work in the familiar way (with important exceptions, as noted here).

I hope I can encourage you to continue the discussion about these things: I want to ensure they're better documented.