UGX-Mods

Call of Duty 5: World at War => Tutorial Desk => Scripting => Topic started by: SparkyMcSparks on May 23, 2014, 11:07:13 pm

Title: [Tutorial] Debugging Scripts
Post by: SparkyMcSparks on May 23, 2014, 11:07:13 pm
Looking at the WaW Scripting Support forum section, it seems like a lot of problems can be solved quite easily without much help if doing some debugging. This tutorial is easy enough that you don't need much scripting knowledge, if anything, it'll let you post valuable information when seeking help for people to better assist you.

I'll try to keep this thing updated over time (and cross-posted between UGX and ZM forums) if I see more common issues arise in the support section or someone has a specific debugging question or technique they want to know about.

Running The Game In Developer Mode

First off, you want to run some dvars when working on your map / mod. These are the ones I recommend ALWAYS using when developing your content:

set developer 2  set developer_script 1  set thereisacow "1337"  set logfile 2  devmap <mapname>

Zombies Debugging

In addition to running the game in developer mode, you can use for zombie related development tools:

set zombie_cheat <1-5>

1     Start all players with 100000 points
2     Start all players with 100000 points   don’t spawn any zombies
3     Start all players with 100000 points   turn on the power after 5 seconds
4     Points   no zombies   power after 5 seconds
5     Same as 4   the ability to re-buy the same perk over and over. Useful for testing animations, sounds, etc.

Checking Logfile

Everything that is printed to the console is printed to the console.log file which goes in the main folder by default. If you're running a mod, the console.log will be in your mod folder within the installation directory.

If you're posting an error on the forum or for someone to fix, it's generally a good idea to attach this file since it'll contain all the console information of what went wrong like a callstack.

Script Runtime Errors

When running your map in developer mode, if you encounter a Script Runtime Error (SRE) the game will end the map if it's fatal or bring up a pop-up window if it's non-fatal.

If you have a SRE you should ALWAYS address them to get a proper fix in -- don't assume since people playing your map won't be running developer mode the issue goes away. It is still happening in the background and can cause really bad issues like hitching, unexpected script results, or even crashing your map.

They usually look like this:
Quote
******* script runtime error *******
undefined is not an array, string, or vector: (file 'maps/mp/_load.gsc', line 113)
if (!isdefined(level._effect["lantern_light"]))
*
called from:
(file 'maps/mp/_load.gsc', line 12)
lanterns thread lanterns();
*
called from:
(file 'maps/mp/mp_houses22.gsc', line 2)
mapsmp\_load::main();
*
started from:
(file 'maps/mp/mp_houses22.gsc', line 1)
main() {
*
************************************

The way it's displayed is the bottom is the origin of the script routine, and the very top is where the SRE was encountered.

In the above example, the map main() function calls the _load.gsc main() function which calls the _load.gsc lanterns() function which has an error on line 113 with the lantern FX.

Note: The formatting is off in how the forum shows this, but the asterisk (*) will always be under the variable / function with the error. It'll display properly in-game to give you a better idea what part of the line is problematic.

Assertions

Asserts are a development feature that check if a condition is true and if not, stops the game. This is useful for when you as a designer want to validate your assumptions about what the state of the game should be whenever possible.

Example:
Code Snippet
Plaintext
AssertEx( IsDefined( ai_maxis), "Maxis AI did not spawn." );

These have no impact in non-developer mode, so people playing your map will never trigger them... but they may run into a SRE. In that case, you should avoid defensive coding to get around the issue and instead fix the issue; if something shouldn't happen, then an assertion is the right thing to use.

Here are the various Assert API you have at your disposal:
Assert( <value> );     Assert that the given statement is correct. The function will throw a script error if this is false.
AssertEx( <value>, <message> );     Assert that the given statement is correct. The function will throw a script error if this is false, with the given message.
AssertMsg( <message> );     Throws a script error with the given message.

Dev Blocks

If you want certain script snippets to only execute when in developer mode, you can wrap in /#    #/

This is useful if you want to kick off developer functions or do prints to the screen of information you want to see from script. People playing your map won't see these.

Example:
Code Snippet
Plaintext
	while ( true )
{
trig waittill( "trigger", who );
{
/#
IPrintLnBold( "Player who purchased perk: "   who.playername );
#/
}
}

Common SREs

Quote
could not find script <script_name_here>
You don't have the script in a FastFile or IWD that is being loaded by the map.

Quote
   must be applied to an int (applied to undefined)
You'tr trying to do a mathematical operation on a variable that isn't defined before the operation. You can't initiate a variable while doing the mathematical operation, you need to define it earlier even if it's just a zero.

Quote
undefined is not an array, string, or vector
Variable you're trying to reference is empty.

Quote
cannot set field of removed entity
Entity has left / deleted from the game or the entity variable it was stored in has been reset / undefined.

Quote
cannot cast undefined to <variable_type_here>
You're trying to reference a variable that is empty.

Quote
potential infinite loop in script
Your while or for loop doesn't have a wait in it. Every loop needs a wait, whether it be a timed wait of 0.05 seconds or waiting for a notify.
Title: Re: [Tutorial] Debugging Scripts
Post by: SajeOne on May 23, 2014, 11:09:36 pm
Great tutorial sparky, glad you're sharing your knowledge with the community. We actually have a section specifically for scripting tutorials so I have moved this topic there.
Title: Re: [Tutorial] Debugging Scripts
Post by: DidUknowiPwn on May 23, 2014, 11:12:16 pm
+rep
:3
Title: Re: [Tutorial] Debugging Scripts
Post by: RamboBadass on May 23, 2014, 11:13:57 pm
amazing!
Title: Re: [Tutorial] Debugging Scripts
Post by: daedra descent on May 23, 2014, 11:14:23 pm
Amazing tutorial dude! +1
Title: Re: [Tutorial] Debugging Scripts
Post by: Dust on May 23, 2014, 11:17:32 pm
nice! this will come in handy
Title: Re: [Tutorial] Debugging Scripts
Post by: treminaor on May 24, 2014, 02:48:49 am
Use all of this daily already, but this saves me the time of writing it up in a wiki guide :D Nice formatting, lots of good info, +1. Stickied.
Title: Re: [Tutorial] Debugging Scripts
Post by: DeletedUser on May 24, 2014, 06:30:43 am
Holy shet, never thought dev's lives could be that easier!
Title: Re: [Tutorial] Debugging Scripts
Post by: treminaor on May 24, 2014, 06:45:37 am
Bear in mind the developer 1/2 command and developer_script do not have full effect unless you turn them on BEFORE you boot your map. Meaning if you cant  boot your map with those turned on, you need to fix all of the errors. I did this for UGX Mod v1.1 and also for the UGX Modtools Patch already.
Title: Re: [Tutorial] Debugging Scripts
Post by: RamboBadass on May 24, 2014, 11:23:37 am
Hello SparkyMcSparks,
I don't have this issue anymore thanks to Trem and DualVII, but Im curious to know if there's a way to locate were a potential infinite loop is in the script...or even say way script?
There's a @13275 after the SRE but I am unsure if this is even related to the error.
(http://i.imgur.com/AvuoUHp.png)
Title: Re: [Tutorial] Debugging Scripts
Post by: InFInIX on May 24, 2014, 11:34:39 am
Never thought treyarch shares stuff for a 6 year old game :O
Title: Re: [Tutorial] Debugging Scripts
Post by: SparkyMcSparks on May 24, 2014, 06:22:41 pm
Hello SparkyMcSparks,
I don't have this issue anymore thanks to Trem and DualVII, but Im curious to know if there's a way to locate were a potential infinite loop is in the script...or even say way script?
There's a @13275 after the SRE but I am unsure if this is even related to the error.
(http://i.imgur.com/AvuoUHp.png)

No, at least not with the public EXEs of the game. Just have to hope that it's a result of SREs that you can trace back, or that you remember any for / while loops you made that might be missing a wait.

Someone had similar infinite loop at the beginning of the map and every time he threw a grenade, ended up being he didn't have the special coop characters setup so the voice overs were bugging out creating an infinite loop.
Title: Re: [Tutorial] Debugging Scripts
Post by: RamboBadass on May 24, 2014, 07:07:15 pm
Thanks for the reply
+1 for you  ;)
Title: Re: [Tutorial] Debugging Scripts
Post by: Delta on May 25, 2014, 02:27:31 am
And whats the magic line to make the console actually useable?

You know... get rid of the **** spam in the log file.


I also wish there would have been a better dev mode introduced with more info ( especially zones ) - but seems like it's up to a scripter again to make it right :(

Oh and any better insights into fx / image loading would by highly appreciated by anyone here <3 <3 <3


// hope we can put this on the wiki if you are OK with it
Title: Re: [Tutorial] Debugging Scripts
Post by: SparkyMcSparks on May 25, 2014, 06:37:44 am
And whats the magic line to make the console actually useable?

You know... get rid of the **** spam in the log file.
What do you mean, certain console information you don't want to see like audio errors?

You can hide/show console channels using the CMDs con_showchannel, con_hidechannel, con_visiblechannellist, and con_channellist

It's pretty intuitive but if you think that would be helpful to have a tutorial mention on I can quickly write it up.

I also wish there would have been a better dev mode introduced with more info ( especially zones ) - but seems like it's up to a scripter again to make it right :(
There is, at least introduced in Black Ops 1 I believe (definitely in Black Ops 2). You can just get a hold of the BO1 or BO2 scripts and port the functionality over, search for zombiemode_debug_zones. I started porting BO2 scripts into WaW but gave up since it was more of a headache despite all the new useful features such as zone debug or only using one zombie spawner for the whole map, working on another zombie mod with less stress.

When you enable it, on top left it should list all the zones and their states. It takes up too many HUD elements though and they all won't show (it uses NewDebugHudElem() which is unlimited but not available in public EXE, can switch it to normal hud element). I suppose someone can just think of a smart way to merge the hud elements but still somehow convey the info.

(http://i.imgur.com/gmYpqQp.png)
Title: Re: [Tutorial] Debugging Scripts
Post by: treminaor on May 25, 2014, 07:02:34 am
What do you mean, certain console information you don't want to see like audio errors?

You can hide/show console channels using the CMDs con_showchannel, con_hidechannel, con_visiblechannellist, and con_channellist
Yes but I'm pretty sure there isn't a way to filter everything, only certain things that arent the biggest spam offenders (like fiends list check spam, dvar set info)

When you enable it, on top left it should list all the zones and their states. It takes up too many HUD elements though and they all won't show (it uses NewDebugHudElem() which is unlimited but not available in public EXE, can switch it to normal hud element). I suppose someone can just think of a smart way to merge the hud elements but still somehow convey the info.
Yeah since WaW is ridiculously limited on hudelems we just used menufiles + dvars whenever possible for UGX Mod. Otherwise as an example we would not have even been able to display 10 perks onscreen reliably with the default 3arc points update hud that creates a new hudelem every time someone earns 10 points ??? I assume using dvars + menufile would be the easiest way to display the zone debug info as well, although println()'s in console got the job done for me recently.

I saw in the dev comments of the code that debughudelem is unlimited but as you said this is one of the many nice things we were not graced with :(
Title: Re: [Tutorial] Debugging Scripts
Post by: SparkyMcSparks on May 25, 2014, 07:42:31 am
Would this be useful?

https://www.youtube.com/watch?v=0H1y28GgjOs (https://www.youtube.com/watch?v=0H1y28GgjOs)

I got rid of all the strings except the zone name and just change color.

RED = Zone offline.
BLUE = Zone active (adjacent to occupied, so zombies will spawn from here too).
GREEN = Zone occupied.
WHITE = Zone online but not active or occupied.
Title: Re: [Tutorial] Debugging Scripts
Post by: Delta on May 25, 2014, 07:48:42 am
Ah damn I totally forgot the different log channels.
What would be the channel to get rid of the davar set spam.
I don't get why this wasn't set to default.

I mean
Code Snippet
Plaintext
...
      dvar set cl_network_warning 0
      dvar set sv_paused 1
      dvar set cl_network_warning 0
      dvar set sv_paused 1
...

Is not very useful... :(

It's been a while since I took a look at cod^^
There is, at least introduced in Black Ops 1 I believe (definitely in Black Ops 2). You can just get a hold of the BO1 or BO2 scripts and port the functionality over, search for zombiemode_debug_zones. I started porting BO2 scripts into WaW but gave up since it was more of a headache despite all the new useful features such as zone debug or only using one zombie spawner for the whole map, working on another zombie mod with less stress.

When you enable it, on top left it should list all the zones and their states. It takes up too many HUD elements though and they all won't show (it uses NewDebugHudElem() which is unlimited but not available in public EXE, can switch it to normal hud element). I suppose someone can just think of a smart way to merge the hud elements but still somehow convey the info.

Well I don't quite get why we have such limit in it at all - but you can use menu files a lot^^

Anyway, I agree, porting all the advanced stuff to waw is just a painfull process and in the end you get a thankfull limit error and you just hate yourself that you wasted your time for this.
It's just a limited tiny sandbox and outdated :( - So sad that there are no BO1 / 2 mod tools.
Would be worth to buy the pc version then. ( You should tell this your project lead / manager, increased sales, more money - sounds good??? )

Would this be useful?

https://www.youtube.com/watch?v=0H1y28GgjOs (https://www.youtube.com/watch?v=0H1y28GgjOs)

I got rid of all the strings except the zone name and just change color.

RED = Zone offline.
BLUE = Zone active (adjacent to occupied, so zombies will spawn from here too).
GREEN = Zone occupied.
WHITE = Zone online but not active or occupied.

Better than nothing hu? ^^ - I never had issues with zones ( I removed the anyway, wasn't flexible enough for what I wanted to do ) but many beginners don't understand the system quite well.
Would be a great additon to our UGX Dev GUI.
But I would also include the checks for the doors and how they are related to each other ( lines )
Usually, beginners name the spawner / target door wrong.
Title: Re: [Tutorial] Debugging Scripts
Post by: KDXDARK on May 25, 2014, 08:24:03 am

It's just a limited tiny sandbox and outdated :( - So sad that there are no BO1 / 2 mod tools.
Would be worth to buy the pc version then. ( You should tell this your project lead / manager, increased sales, more money - sounds good??? )


off-topic: they dont going to release the mod tools,  i read a long time ago about lot of changes on the way of made them, for that they dont release them, but i think they should give us a chance. :)
Title: Re: [Tutorial] Debugging Scripts
Post by: ProGamerzFTW on May 26, 2014, 01:54:54 am
You can just get a hold of the BO1 or BO2 scripts and port the functionality over, search for zombiemode_debug_zones.

Isn't the Black Ops 2 scripts encrypted in some way? :P
Title: Re: [Tutorial] Debugging Scripts
Post by: daedra descent on May 26, 2014, 01:56:15 am
Isn't the Black Ops 2 scripts encrypted in some way? :P

I thought it was in an entirely different scripting language.  :P
Title: Re: [Tutorial] Debugging Scripts
Post by: treminaor on May 26, 2014, 01:58:37 am
I thought it was in an entirely different scripting language.  :P
No... what gave you that idea?

They encrypted them to prevent people from ripping them, along with all of the other assets.
Title: Re: [Tutorial] Debugging Scripts
Post by: daedra descent on May 26, 2014, 02:12:51 am
No... what gave you that idea?

They encrypted them to prevent people from ripping them, along with all of the other assets.

I don't know. I just remember it looking funky when i had seen the code somewhere a long time ago. Just assumed it was another language.
Title: Re: [Tutorial] Debugging Scripts
Post by: RamboBadass on May 26, 2014, 02:29:59 am
Id give damn near anything for BO2 modtools and BO1 Radiant(or the current version)
i just am curious to why the steam community never got radiant for bo1, i would have thought they loved to see what the custom community could do.
Title: Re: [Tutorial] Debugging Scripts
Post by: treminaor on May 26, 2014, 02:36:07 am
Id give damn near anything for BO2 modtools and BO1 Radiant(or the current version)
i just am curious to why the steam community never got radiant for bo1, i would have thought they loved to see what the custom community could do.
Pretty sure its a licensing issue with Activision, and I doubt they want DLC competition with the custom community.
Title: Re: [Tutorial] Debugging Scripts
Post by: zNiiC on May 26, 2014, 03:45:38 am
Back on topic, Sparky this was me:

Quote
Someone had similar infinite loop at the beginning of the map and every time he threw a grenade, ended up being he didn't have the special coop characters setup so the voice overs were bugging out creating an infinite loop.

I'm using a custom _loadout.gsc and I never touched the coop characters setup. What could be the fix?
Title: Re: [Tutorial] Debugging Scripts
Post by: daedra descent on May 26, 2014, 03:47:19 am
Back on topic, Sparky this was me:

I'm using a custom _loadout.gsc and I never touched the coop characters setup. What could be the fix?

Use one that isn't broken.  :gusta:
Title: Re: [Tutorial] Debugging Scripts
Post by: SparkyMcSparks on May 26, 2014, 04:05:39 am
Back on topic, Sparky this was me:

I'm using a custom _loadout.gsc and I never touched the coop characters setup. What could be the fix?

There is a couple checks if level.script equals various zombie maps to use the coop characters. The easiest things to do is a sub-string check like this so it works for all zombie maps:

(http://i.imgur.com/dPrpa9W.png)

(http://i.imgur.com/JOuZUp5.png)
Title: Re: [Tutorial] Debugging Scripts
Post by: treminaor on May 26, 2014, 04:15:40 am
Except not everyone uses nazi_zombie_ as a prefix anymore :D

imo the thing to do is just remove code from _loadout that is for SP and leave the code for zombies - then remove the mapname checks. Since youre editing your own copy of the loadout that only gets packaged with the single zombie map there's no reason to leave the SP level code in there as it's unusued and overcomplicates the file.
Title: Re: [Tutorial] Debugging Scripts
Post by: zNiiC on May 26, 2014, 04:37:38 am
So I got it to work, but my hands were messed up as I am using a gun mod (all attachments were on). So, I got the original loadout and replaced these two instances (http://i.imgur.com/0OCsJyv.png (http://i.imgur.com/0OCsJyv.png)), but the error still happens.