Ending the game
by Anthony Ratcliffe · in Torque Game Builder · 03/17/2008 (12:26 pm) · 28 replies
Hello i've written a movement script based on an if loop(see below) at the end of the loop it should load a new scene in this case called end.t2d how ever tgb crashes when it reaches the end and i cannot work out why
function mo::onLevelLoaded(%this)
{
$level = "game/data/levels/end.t2d"; // looks for level end
$node= 0;
%this.setPositionTarget(49,-47, true, true);
%this.setLinearVelocityX(15);
$node++;
}
ECT ECT .......
else if ($node==35)
{
echo ("reached call36");
%this.setPositionTarget(-48,-11, true, true);
%this.setLinearVelocityX(0);
%this.setLinearVelocityY(2);
$node++;
}
else if ($node==36)
{
echo ("reached call36");
%this.setPositionTarget(48,-11, true, true);
%this.setLinearVelocityX(20);
%this.setLinearVelocityY(0);
$node++;
}
else if ($node==37)
{
sceneWindow2D.endLevel();
sceneWindow2D.loadLevel($level);
}
// ADD A ELSE IF TO TAKE IT TO A DIFFRENT LEVEL SAYING GAME OVER THEY REACHED THE CITY WALLS
}
function mo::onLevelLoaded(%this)
{
$level = "game/data/levels/end.t2d"; // looks for level end
$node= 0;
%this.setPositionTarget(49,-47, true, true);
%this.setLinearVelocityX(15);
$node++;
}
ECT ECT .......
else if ($node==35)
{
echo ("reached call36");
%this.setPositionTarget(-48,-11, true, true);
%this.setLinearVelocityX(0);
%this.setLinearVelocityY(2);
$node++;
}
else if ($node==36)
{
echo ("reached call36");
%this.setPositionTarget(48,-11, true, true);
%this.setLinearVelocityX(20);
%this.setLinearVelocityY(0);
$node++;
}
else if ($node==37)
{
sceneWindow2D.endLevel();
sceneWindow2D.loadLevel($level);
}
// ADD A ELSE IF TO TAKE IT TO A DIFFRENT LEVEL SAYING GAME OVER THEY REACHED THE CITY WALLS
}
About the author
#2
The first is that you are calling %this.safedelete(), meaning that you may be seeing the object which updates your counter become nothing before it ever gets to update the counter. Move that line to the end of the function.
Second, $this.hitcount is probably not the best idea for naming convention, in terms of a global variable. I think you may have confused what you were really trying to do there, and I'd suggest that you simply make a global variable named $hitCount instead.
Finally, you may want to initialize or re-set that variable elsewhere, rather than in the onLevelLoaded of your si class objects. That is, you really want that called just once when you've started the level. Potentially it could be called several times via the existence of multiple si objects in your level, as is.
Your code might look like this, once revised:
P.S. Is it possible that your $level variable points to an invalid or non-existent scene, regarding your crash related issue? Have you verified in the console that the value of $level is correct, or put an "echo("Loading level: " @ $level);" blurb in there to confirm it as such?
03/18/2008 (5:18 am)
Not sure on the former (as to the reason you are encountering a crash), but for the latter it looks like you may have two issues to correct.The first is that you are calling %this.safedelete(), meaning that you may be seeing the object which updates your counter become nothing before it ever gets to update the counter. Move that line to the end of the function.
Second, $this.hitcount is probably not the best idea for naming convention, in terms of a global variable. I think you may have confused what you were really trying to do there, and I'd suggest that you simply make a global variable named $hitCount instead.
Finally, you may want to initialize or re-set that variable elsewhere, rather than in the onLevelLoaded of your si class objects. That is, you really want that called just once when you've started the level. Potentially it could be called several times via the existence of multiple si objects in your level, as is.
Your code might look like this, once revised:
// this function is where ever you start your game play, such as load a specific level, etc.
function startLevel()
{
... // other code necessary to initialize your game play/level(s)
$hitCount = 0;
}
// this function is in your si.cs script, holding functions related to your space invader class
function si::explode(%this)
{
$hitCount++; // increment the hit counter
guiHit.text = $hitCount; // update the GUI to reflect the increased score
%this.safeDelete(); // have this invader safely remove itself from play
}P.S. Is it possible that your $level variable points to an invalid or non-existent scene, regarding your crash related issue? Have you verified in the console that the value of $level is correct, or put an "echo("Loading level: " @ $level);" blurb in there to confirm it as such?
#3
03/18/2008 (1:40 pm)
The score works perfectly now thanks, however i still cant sort the end game and of the 3 books i have torque 3d programming and the gpgtt i still cant figure how to end the level
#4
The reason I bring this up (untested by me, keep in mind) is that TGB may not fancy you having a scenewindow without an active scenegraph, particularly if you have code that might continue to do something involving the now deleted scenegraph!
Experimentally, try changing your code to this to see if it stops the crash, at least ...
Try that to see if it at least stops the crashing you've encountered. It is a little hard to say (or at least, nothing strikes me as the cause) without potentially seeing more of your code to understand what may be happening.
Finally, check your console.log file to see what errors may exist in it after the latest crash example--there very well may be something in there to tell you what happened to cause the crash (or what was happening at the time it did).
03/18/2008 (2:12 pm)
What are you looking to have happen, exactly? One thing to keep in mind is that when you use .endLevel() at the sceneWindow scope (as opposed to endLevel() on the scenegraph) is that the level is cleared and the scenegraph is deleted. When done to the scenegraph, it clears the scene but the scenegraph remains.The reason I bring this up (untested by me, keep in mind) is that TGB may not fancy you having a scenewindow without an active scenegraph, particularly if you have code that might continue to do something involving the now deleted scenegraph!
Experimentally, try changing your code to this to see if it stops the crash, at least ...
... // your other code from above
else if(node == 37)
{
// create a new scenegraph object named someScene
new t2dScenegraph(someScene) {};
// get a reference to the current scenegraph and store it in a local variable named %curScene
%curScene = sceneWindow2D.getScenegraph();
// we'll pause it just to stop any action going on there
%curScene.setScenePause(true);
// set the NEW scenegraph as the active scene in our scenewindow
sceneWindow2D.setScenegraph(someScene);
// now we'll deal with the previous scenegraph
// keep in mind that this will clear the scene/level of its goodies, but won't delete it
%curScene.endLevel();
// rather, we'll delete it on our own terms, instead of having sceneWindow2D do it for us ...
%curScene.safedelete();
// try running this with the above line "%curScene.safedelete()" remmed out as well
// if you get the crash, still, with the code here as is.
}
... // whatever code comes after ...Try that to see if it at least stops the crashing you've encountered. It is a little hard to say (or at least, nothing strikes me as the cause) without potentially seeing more of your code to understand what may be happening.
Finally, check your console.log file to see what errors may exist in it after the latest crash example--there very well may be something in there to tell you what happened to cause the crash (or what was happening at the time it did).
#5
Calling endlevel should always be done from outside an object in the level. One way to do this is to simply schedule the call for a tiny bit in the future instead of calling it directly. So something like
Greg
03/18/2008 (5:21 pm)
The objects in the scene are deleted when you end the level. Since the object that is calling the endlevel is deleting itself, this usually causes unstable results.Calling endlevel should always be done from outside an object in the level. One way to do this is to simply schedule the call for a tiny bit in the future instead of calling it directly. So something like
sceneWindow2D.schedule(100,0,"endLevel"); sceneWindow2D.schedule(500,0,"loadLevel",$level);in your case.
Greg
#6
03/18/2008 (6:18 pm)
Wow, good question and great answers - I learned several things in that discussion. Thanks!
#7
Maybe to help save you from headaches in the future, Anthony, let me throw out some code that you might find useful. The code is used for swapping between "modes" or "game modes" (as I refer to them). "Modes" are scenes/levels, or collections of scenes/levels, constituting some major functional area of your game.
In the blurb I'm providing here, there are three modes--(0) Startup mode, (1) Character creator mode, and (2) combat mode. The main function "changeMode()" is the gatekeeper, if you will, handling the passage of the player from one game mode to the next.
This could easily be adapted to swap between game play levels or anything other "mode" you devise. It should be easy to expand upon once you see how it works. In any case, here is the main function:
All that is really happening here is evaluations as to the current game mode, a call to a function handling the "wind-down" of that mode, and then an evaluation of the new mode we want to switch into, alongside the "wind-up" function that corresponds to that.
For example, lets say your game is just starting up and you want the player to go to your start screen and push out your start menus, etc. You'd call this function with the game mode argument set to 0, like:
When the function call comes in, two other functions get singled out--deactivateStartupMode() and activateStartupMode(). Here are those functions:
deactivateStartupMode() simply "pops" the start menu away (and in the first case, harmlessly so as it was never in view in the first place), and then checks to see if a scenegraph named $startupScene exists. If it does, it calls endLevel() on it, clearing it out and then deleting it. If it doesn't exist, well, nothing else happens.
activateStartupMode() does a lot of things! It creates a new scenegraph that is the primary scenegraph for that game mode. Next, it pushes the background and foreground GUIs, loads a level into the new scenegraph and then sets that as the active scenegraph in my sceneWindow object ($mainSceneWindow).
Note that I don't load my levels into the sceneWindow--I leave my sceneWindow 'as is' and create and alternate which scenegraph is active within it. Finally, ActivateStartupMode() adjusts camera settings to make sure all is proper in that respect.
The other activate and deactivate functions are very similar, pushing out their own GUIs, creating their own scenegraph(s), loading their own levels, etc.
This also makes it easy to jump around in my prototype, more or less ad hoc. At any time I can pull down the console and type "changeMode(x)," where x is the mode I want to flip into action.
Another advantage is that you can refrain from loading unnecessary resources until the player initiates a move to the mode that needs them. Take my version of the activateCreatorMode() function as example of this:
You might have noticed that early in this function I also "exec" a file called "creatorExecs.cs". This file contains references to GUIs and other resources that are only relevant if the player moves into Creator Mode. If not, those resources are never loaded. Why should they be, eh?
Handling it that way could be a real advantage if you have a lot of resources that might potentially be used, but only a fraction are ever really needed during any play session.
For example, if you have fifty different play levels for your space invaders game, chances are that a player might only reach the first five or ten, during his or her first game. When they come back, they might only access the next five or ten--and you would only exec files of relevance to the levels or "modes" the player actually engages during that play session.
(Note that even what I have there could be optimized a bit further. For example, we could store a boolean (true/false) value in a variable to see if the exec had already been called, avoiding it if it turns out to be the case when we come back to this mode again later.)
Anyhow, hopefully that will give you an insight as to one strategy you might use to handle your shifts from level to level, mode to mode, or what not. It can make it cleaner and easier to get a handle on transitioning your player around the game, all the while providing a central bit of code that you can refactor anytime you need to add in new game modes or levels.
Anyone have suggestions on how this might be improved? Constructive feedback or examples of your own methods of transitioning players about a game would be grand! :D
03/18/2008 (9:06 pm)
Good call Tetraweb; I should have picked up on that. :)Maybe to help save you from headaches in the future, Anthony, let me throw out some code that you might find useful. The code is used for swapping between "modes" or "game modes" (as I refer to them). "Modes" are scenes/levels, or collections of scenes/levels, constituting some major functional area of your game.
In the blurb I'm providing here, there are three modes--(0) Startup mode, (1) Character creator mode, and (2) combat mode. The main function "changeMode()" is the gatekeeper, if you will, handling the passage of the player from one game mode to the next.
This could easily be adapted to swap between game play levels or anything other "mode" you devise. It should be easy to expand upon once you see how it works. In any case, here is the main function:
// takes one argument, %newMode
function changeMode(%newMode)
{
// this part handles the unloading of the current game mode
switch($gameMode)
{
case 0: // startup mode
deactivateStartupMode();
case 1: // creator mode
deactivateCreatorMode();
case 2: // combat mode
deactivateCombatMode();
}
// this part handles the loading of the requested/new game mode
switch (%newMode)
{
case 0: // startup mode
activateStartupMode();
case 1: // creator mode
activateCreatorMode();
case 2: // combat mode
activateCombatMode();
}
$gameMode = %newMode; // we update our gameMode variable with the new state value
}All that is really happening here is evaluations as to the current game mode, a call to a function handling the "wind-down" of that mode, and then an evaluation of the new mode we want to switch into, alongside the "wind-up" function that corresponds to that.
For example, lets say your game is just starting up and you want the player to go to your start screen and push out your start menus, etc. You'd call this function with the game mode argument set to 0, like:
changeMode(0); //simple as that!
When the function call comes in, two other functions get singled out--deactivateStartupMode() and activateStartupMode(). Here are those functions:
function deactivateStartupMode()
{
Canvas.popDialog(StartMenu);
if(isObject($startupScene))
{
$startupScene.endLevel();
$startupScene.delete();
}
}
function activateStartupMode()
{
if(!isObject($startupScene))
{
$startupScene = new t2dScenegraph(startupScene) {};
}
// set the canvas with the black-backed startup screen GUI content
Canvas.setContent(startupScreen);
// push out the main game start menu
Canvas.pushDialog(StartMenu);
$startupScene.LoadLevel("game/data/levels/startup.t2d");
$mainSceneWindow.setScenegraph($startupScene);
// adjust the camera
$mainSceneWindow.setCurrentCameraArea(-400, -300, 400, 300);
$mainSceneWindow.setCurrentCameraPosition("0 0");
$mainSceneWindow.setViewLimitOn(-400, -300, 400, 300);
}deactivateStartupMode() simply "pops" the start menu away (and in the first case, harmlessly so as it was never in view in the first place), and then checks to see if a scenegraph named $startupScene exists. If it does, it calls endLevel() on it, clearing it out and then deleting it. If it doesn't exist, well, nothing else happens.
activateStartupMode() does a lot of things! It creates a new scenegraph that is the primary scenegraph for that game mode. Next, it pushes the background and foreground GUIs, loads a level into the new scenegraph and then sets that as the active scenegraph in my sceneWindow object ($mainSceneWindow).
Note that I don't load my levels into the sceneWindow--I leave my sceneWindow 'as is' and create and alternate which scenegraph is active within it. Finally, ActivateStartupMode() adjusts camera settings to make sure all is proper in that respect.
The other activate and deactivate functions are very similar, pushing out their own GUIs, creating their own scenegraph(s), loading their own levels, etc.
This also makes it easy to jump around in my prototype, more or less ad hoc. At any time I can pull down the console and type "changeMode(x)," where x is the mode I want to flip into action.
Another advantage is that you can refrain from loading unnecessary resources until the player initiates a move to the mode that needs them. Take my version of the activateCreatorMode() function as example of this:
function activateCreatorMode()
{
if(!isObject($creatorScene))
{
// handle necessary execs
exec("./gamescripts/creator/creatorExecs.cs");
$creatorScene = new t2dScenegraph(creatorScene) {};
}
$creatorScene.LoadLevel("game/data/levels/creator.t2d");
$mainSceneWindow.setScenegraph($creatorScene);
// both the combat and creator modes have a "manager" that handles
// pushing/popping internal GUIs, object cleanup and initializations, and the like
// For the creator, the manager object is called "creatorManager"-- surprised?
//
// Here, I'm telling the manager that the player is "starting" up in creator mode, and that it
// needs to take care of any business before we really get going.
creatorManager.startup();
}You might have noticed that early in this function I also "exec" a file called "creatorExecs.cs". This file contains references to GUIs and other resources that are only relevant if the player moves into Creator Mode. If not, those resources are never loaded. Why should they be, eh?
Handling it that way could be a real advantage if you have a lot of resources that might potentially be used, but only a fraction are ever really needed during any play session.
For example, if you have fifty different play levels for your space invaders game, chances are that a player might only reach the first five or ten, during his or her first game. When they come back, they might only access the next five or ten--and you would only exec files of relevance to the levels or "modes" the player actually engages during that play session.
(Note that even what I have there could be optimized a bit further. For example, we could store a boolean (true/false) value in a variable to see if the exec had already been called, avoiding it if it turns out to be the case when we come back to this mode again later.)
Anyhow, hopefully that will give you an insight as to one strategy you might use to handle your shifts from level to level, mode to mode, or what not. It can make it cleaner and easier to get a handle on transitioning your player around the game, all the while providing a central bit of code that you can refactor anytime you need to add in new game modes or levels.
Anyone have suggestions on how this might be improved? Constructive feedback or examples of your own methods of transitioning players about a game would be grand! :D
#8
Derelict - i added all you code you gave earlier and it really didnt like it, and refused to move to the positions at all before it even reached the load level
else if ($node==37)
{
new t2dScenegraph(end) ();
%curScene = sceneWindow2D.getScenegraph();
%curScene.setScenePause(true);
sceneWindow2D.setScenegraph(endScene);
%curScene.endLevel();
%curScene.safedelete();
}
some error context ## on side of error halt was the error.
sorry for the lack of understanding if i did somthing wrong, coding isnt my strong point
03/18/2008 (9:28 pm)
Ok having a quick over view with it being 4.11 am. I have a quick question to ask on top of what i'm reading.Derelict - i added all you code you gave earlier and it really didnt like it, and refused to move to the positions at all before it even reached the load level
else if ($node==37)
{
new t2dScenegraph(end) ();
%curScene = sceneWindow2D.getScenegraph();
%curScene.setScenePause(true);
sceneWindow2D.setScenegraph(endScene);
%curScene.endLevel();
%curScene.safedelete();
}
some error context ## on side of error halt was the error.
sorry for the lack of understanding if i did somthing wrong, coding isnt my strong point
#9
Both of those lines are in error. The first line should look exactly like (NOTE: those are brackets and not parenthesis):
or just
The second line of code is in error because there is no object named "endScene". We've named it merely "end". See that?
Regardless, Tetraweb hit the nail on the head with his (or her? sorry, no way to know!) earlier post. You might try fixing the errors in the code I gave you, just so you can experiment a little to see if it resolves your problem--before swapping in Tetra's code which is much more certain to work. :D
Anyhow, if you have a little time later, look over the more recent post I left for you as it details a method you might want to use to handle those sort of transitions in a bit cleaner manner, into the future.
P.S. No worries that you aren't an expert at scripting. If you were, likely I'd be asking YOU some questions. *grin*
03/18/2008 (9:36 pm)
Anthony: Ah, you've got an error in there ...new t2dScenegraph(end) (); ... sceneWindow2D.setScenegraph(endScene);
Both of those lines are in error. The first line should look exactly like (NOTE: those are brackets and not parenthesis):
new t2dScenegraph(end) {};or just
new t2dScenegraph(end);
The second line of code is in error because there is no object named "endScene". We've named it merely "end". See that?
Regardless, Tetraweb hit the nail on the head with his (or her? sorry, no way to know!) earlier post. You might try fixing the errors in the code I gave you, just so you can experiment a little to see if it resolves your problem--before swapping in Tetra's code which is much more certain to work. :D
Anyhow, if you have a little time later, look over the more recent post I left for you as it details a method you might want to use to handle those sort of transitions in a bit cleaner manner, into the future.
P.S. No worries that you aren't an expert at scripting. If you were, likely I'd be asking YOU some questions. *grin*
#10
ok i think we have progress , no script error, at node 37 it waits as the code instructs then crashes
i would try tetrawebs method however i dont fully understand it
if you have msn feel free to add me
anthonyratcliffe@hotmail.com
03/18/2008 (9:51 pm)
Wow a super quick response :) sorry another quick question how does the script new t2dScenegraph(end); know to look in the scene folder for a scene called end.t2d that what i'm failing to grasp lolok i think we have progress , no script error, at node 37 it waits as the code instructs then crashes
i would try tetrawebs method however i dont fully understand it
if you have msn feel free to add me
anthonyratcliffe@hotmail.com
#11
With the code blurb: "new t2dScenegraph(end)" what we are doing is making a new object instance, in this case of a Scenegraph object.
Think of it as a container that *can* hold levels, sort of like a DVD player (scenegraph object) to a DVD (level file), but doesn't necessarily have too. That make sense? To extend my metaphor, however weak it is, imagine that SceneWindow2D is the plasma TV you want to watch the DVD on.
Fortunately, in the world of T2D, we can conjure up a new DVD player on a whim which is what our "new t2dScenegraph(end)" is doing. The "end" part is just giving that particular DVD player a name, "end". It doesn't in any way reference a level file, or anything else but the new scenegraph. "end" is the name we've given it, in other words.
Later, when you want to do something with that specific scenegraph you can reference it by that given name. Such as "end.loadLevel($level);" or "end.endLevel();" or "sceneWindow2D.setScenegraph(end);". In the latter case, it is like plugging that specific DVD player into that specific plasma TV--even if no DVD is currently in that DVD player (you'd use end.loadLevel(%someLevel); to do that!).
Regardless, it doesn't really matter as my code example won't resolve the crash problem you are seeing. It is happening for precisely the reason that Tetraweb mentioned ... the scenegraph the code is executing from is effectively deleting itself, halting the ability to run any further code you have there and choking the program when it tries. Crash!
If you want to try Tetraweb's code (which I would suggest) it is easy! Just copy and paste the exact code you see below, replacing your existing blurb for the node:
That should solve it, but as Tetra mentioned, the ideal thing to do is call the code outside of the object that will be deleted in the process--in this case, the current scenegraph within sceneWindow2D.
03/18/2008 (10:39 pm)
There is no file named end.t2d--"end" doesn't care because it is just a scenegraph object. Does that make sense? I'm probably talking in jibberish at this time so let me try to make it clear.With the code blurb: "new t2dScenegraph(end)" what we are doing is making a new object instance, in this case of a Scenegraph object.
Think of it as a container that *can* hold levels, sort of like a DVD player (scenegraph object) to a DVD (level file), but doesn't necessarily have too. That make sense? To extend my metaphor, however weak it is, imagine that SceneWindow2D is the plasma TV you want to watch the DVD on.
Fortunately, in the world of T2D, we can conjure up a new DVD player on a whim which is what our "new t2dScenegraph(end)" is doing. The "end" part is just giving that particular DVD player a name, "end". It doesn't in any way reference a level file, or anything else but the new scenegraph. "end" is the name we've given it, in other words.
Later, when you want to do something with that specific scenegraph you can reference it by that given name. Such as "end.loadLevel($level);" or "end.endLevel();" or "sceneWindow2D.setScenegraph(end);". In the latter case, it is like plugging that specific DVD player into that specific plasma TV--even if no DVD is currently in that DVD player (you'd use end.loadLevel(%someLevel); to do that!).
Regardless, it doesn't really matter as my code example won't resolve the crash problem you are seeing. It is happening for precisely the reason that Tetraweb mentioned ... the scenegraph the code is executing from is effectively deleting itself, halting the ability to run any further code you have there and choking the program when it tries. Crash!
If you want to try Tetraweb's code (which I would suggest) it is easy! Just copy and paste the exact code you see below, replacing your existing blurb for the node:
else if ($node==37)
{
sceneWindow2D.schedule(100,0,"endLevel");
sceneWindow2D.schedule(500,0,"loadLevel",$level);
}That should solve it, but as Tetra mentioned, the ideal thing to do is call the code outside of the object that will be deleted in the process--in this case, the current scenegraph within sceneWindow2D.
#12
03/18/2008 (10:53 pm)
No script errors but no end.t2d loading either, this is strange
#13
Having said that, if it is no longer crashing the reason must be due to use of "safeDelete()" on the current scenegraph object--it lingers around long enough that it no longer kills itself before everything is done that needs to be done. That is a little surprising, still, but comprehensible enough to make sense as to why it works.
Try adding these lines of code immediately after the line "new t2dScenegraph(end);"
Run it and pull down your console. You should see the text from the echo trailed with the data stored in your $level variable. How does it read? Like this--
Level file about to be loaded:
or something like this (except the scene file is YOUR specific file)--
Level file about to be loaded: game/data/levels/yourLevel.t2d
If it looks like the former, well, your $level variable has nothing in it. If the latter, you should see that level load up in addition to the info in your console.
03/19/2008 (12:37 pm)
Actually, no ... that is exactly the behavior you should expect. There is no "end.t2d" level being loaded, only an empty scenegraph object named "end". Huge difference! Re-read my last post in this thread to understand what I mean.Having said that, if it is no longer crashing the reason must be due to use of "safeDelete()" on the current scenegraph object--it lingers around long enough that it no longer kills itself before everything is done that needs to be done. That is a little surprising, still, but comprehensible enough to make sense as to why it works.
Try adding these lines of code immediately after the line "new t2dScenegraph(end);"
echo("Level file about to be loaded: " @ $level);
end.LoadLevel($level);Run it and pull down your console. You should see the text from the echo trailed with the data stored in your $level variable. How does it read? Like this--
Level file about to be loaded:
or something like this (except the scene file is YOUR specific file)--
Level file about to be loaded: game/data/levels/yourLevel.t2d
If it looks like the former, well, your $level variable has nothing in it. If the latter, you should see that level load up in addition to the info in your console.
#14
sceneWindow2D.schedule(500,0,"loadLevel",$level);
echo("Level file about to be loaded: " @ $level);
end.LoadLevel($level);
i get a response stating it is going to load /data/levels/end.t2d
how ever i get cannot find scene end attempting to call loadlevel, i presume this is because in terras code end is not being declared
with the code
new t2dScenegraph(end);
%curScene = sceneWindow2D.getScenegraph();
%curScene.setScenePause(true);
sceneWindow2D.setScenegraph(end);
%curScene.endLevel();
echo("Level file about to be loaded: " @ $level);
end.LoadLevel($level);
the game once again crashes
03/19/2008 (9:52 pm)
SceneWindow2D.schedule(100,0,"endLevel");sceneWindow2D.schedule(500,0,"loadLevel",$level);
echo("Level file about to be loaded: " @ $level);
end.LoadLevel($level);
i get a response stating it is going to load /data/levels/end.t2d
how ever i get cannot find scene end attempting to call loadlevel, i presume this is because in terras code end is not being declared
with the code
new t2dScenegraph(end);
%curScene = sceneWindow2D.getScenegraph();
%curScene.setScenePause(true);
sceneWindow2D.setScenegraph(end);
%curScene.endLevel();
echo("Level file about to be loaded: " @ $level);
end.LoadLevel($level);
the game once again crashes
#15
echo("Level file about to be loaded: " @ $level);
end.LoadLevel($level);
%curScene = sceneWindow2D.getScenegraph();
%curScene.setScenePause(true);
sceneWindow2D.setScenegraph(end);
%curScene.endLevel();
sorry i ment that
03/19/2008 (9:56 pm)
New t2dScenegraph(end);echo("Level file about to be loaded: " @ $level);
end.LoadLevel($level);
%curScene = sceneWindow2D.getScenegraph();
%curScene.setScenePause(true);
sceneWindow2D.setScenegraph(end);
%curScene.endLevel();
sorry i ment that
#16
03/24/2008 (8:53 pm)
Sorry to bump this but i'm still a little stuck
#17
At this point, I'd suggest just ignoring the code I suggested from earlier. What you want is to implement TeraWeb's code using a level that you have and know to exist. You mention that the console returned "/data/levels/end.t2d" but unless you've actually made a scene/level by that name, it doesn't exist to be loaded!
What it boils down to is making sure that the $level variable points to an actual level file before the two lines of code provided by Tera are executed. So, presuming you have a level called "myLevel.t2d", you would want your actual code to set the $level variable to properly point to "myLevel.t2d", and then execute the schedule events. Otherwise, nothing is being loaded by the sceneWindow2D object (the Scene Window).
03/24/2008 (9:00 pm)
Sorry for the delay in getting back to you in this thread.At this point, I'd suggest just ignoring the code I suggested from earlier. What you want is to implement TeraWeb's code using a level that you have and know to exist. You mention that the console returned "/data/levels/end.t2d" but unless you've actually made a scene/level by that name, it doesn't exist to be loaded!
What it boils down to is making sure that the $level variable points to an actual level file before the two lines of code provided by Tera are executed. So, presuming you have a level called "myLevel.t2d", you would want your actual code to set the $level variable to properly point to "myLevel.t2d", and then execute the schedule events. Otherwise, nothing is being loaded by the sceneWindow2D object (the Scene Window).
#18
{
$level = "spaceinv\game\data\levels\end.t2d";
sceneWindow2D.schedule(100,0,"endLevel");
sceneWindow2D.schedule(500,0,"loadLevel",$level);
}
still not running and yet theres no console errors again, i've also tried deleting the .dso incase the script wasnt running
03/24/2008 (11:29 pm)
Else if ($node==37){
$level = "spaceinv\game\data\levels\end.t2d";
sceneWindow2D.schedule(100,0,"endLevel");
sceneWindow2D.schedule(500,0,"loadLevel",$level);
}
still not running and yet theres no console errors again, i've also tried deleting the .dso incase the script wasnt running
#19
Greg
03/25/2008 (3:34 am)
I don't know if that's an exact pasting of your code, but your slashes above are back instead of forward. Try this:else if ($node==37)
{
$level = expandFilename("~data/levels/end.t2d"); //assuming that the .t2d actually
// exists in this directory
sceneWindow2D.schedule(100,0,"endLevel");
sceneWindow2D.schedule(500,0,"loadLevel",$level);
}Greg
#20
http://www.sendspace.com/file/u7gd7k
so you can have a look i'm really stumped now and have no idea
03/25/2008 (11:48 am)
Ok still nothing i've decided to upload the code tohttp://www.sendspace.com/file/u7gd7k
so you can have a look i'm really stumped now and have no idea
Torque Owner Anthony Ratcliffe
function si::onLevelLoaded(%this)
{
$this.hitcount = 0;
}
function si::explode(%this)
{
%this.safedelete();
guihit.text = $this.hitcount++ ;
// ADD ONE TO THE COUNT FOR SCORE
}