URT script Engine bug
can't have ; or " after //
#1
Posted 27 June 2011 - 08:09 AM
If you have a long script like I do. You will get occasionally mysterious bullet jams (I believe u need more than XXX lines before noticing any jams.. I would never get jams on very short scripts)..
->tip: "in_mouse -1" (dunno if it can be mousedriver related but my system is Windows 7 x64) << This may not necessarily work for you.. but in my case it was 100% the solution. (There are more script engine errors with URT... you can't have " or ; after //)
These are some commands you might find very helpful..
Found out about this zoom wrap couple days ago... currently not really needing it but someone out there might find it useful..
->"cg_zoomWrap 1" ... instead of sr-8 or psg1 going into reset.. the last zoomin depth would be in freeze.. If you do use this, be sure to use "ut_zoomreset" somewhere .. I tend to use a generalFallback button which does: zoom_reset and re-apply sprint.. and as lazy as I am I also tend to turn off any minimap I have on the screen from the same generalFallback button.. (shouldn't there be a gui option for this?)
->Toggling the map
I also tend to throw this in my generalFallback button->set cg_maptoggle 0 , which turns it off.. it's just as easy as binding a toggle to a key like this..
"toggle cg_maptoggle"
eg: bind z "toggle cg_maptoggle"
^ using toggle sets something to 1 or 0 meaning on or off..
Another example is the same thing is accomplished but requiring two keys.. one to turn it on, the other off..
note: using->" set cg_maptoggle 1" is a one-1way toggle.. so u'll have to find a way to turn it back off if you want to.. "toggle cg_maptoggle" cycles the map on and off from the same key..
I tend to sort the map not too big or small.. The default settings for the map is not very good..
You can experiment with numbers if you want to use minimap properties that work well for you..
I tend to use this as an example:
set cg_mapsize 270
set cg_maparrowscale 12
set cg_mappos 5 (5 represents bottom of screen)
set cg_maptoggle 0 //starts game without map.. you'll need "toggle cg_maptoggle" or "set cg_maptoggle 1" to a bind key somewhere to turn it back on
set cg_maparrowscale 1.4
if you dont want to spend time retrying your modified script you can bind exec to your script..
eg: "bind TAB exec autoexec.cfg" so when you hit the TAB button, you don't need to restart URT application
Here's some other things I found out.. in console of course
/bind TAB<ENTER> will show what the TAB key is binded to ("exec autoexec.cfg" will be printed out)
--other examples.. /bind MOUSE1 (would show +attack), /bind MOUSE2, /bind SPACE...
note: when I said "TAB" you type TAB.. if I say <TAB>, you do not type the word TAB..
/<vstr name> will show the var value string..
/cvarlist will show all your variables defined
/unbind if you happen to play around with new bind keys commands, don't forget to unbind your old ones (they'll get stored in q3config.cfg.. the unbind command clears binds from this file)(In the past I decided to buy a new keyboard and did a whole new bind all over the place.. simply use->unbindall, then exec autoexec.cfg)
.. If you suspect that your keyboard is not emitting more than 3 keys if you're holding down 4. (I have 2-3 keyboard keys mapped to my mouse driver settings).. then test it out some keyscan software.. Turned out in my case i just had to use that in_mouse command
.. If you have keys you would like to use and no documentation clearly tells you for those strange keys..
/bind <TAB> ... will show ALL the names representing keys than you can apply to the bind command.
.. To probe on specific/near-match cvar names..
/cvarlist a<ENTER> for eg; will show anything that start with "a" from your script, and any buitins cvars starting with a
/cvarlist bot<ENTER> shows interesting builtin bot cvars
^ With the above command toolset it is easy to debug.. If you suspect a bind is not working.. simply do a /bind <key><Enter> and it's cvar will be mentioned.. Here are command mistakes people make..
"/bind z callthis" //wrong
"/bind z vstr callthis" //right
OF COURSE in the autoexec.cfg you don't use "/".. in front of the command
This one is not posted anywhere.. say this is in your autoexec.cfg
//Commenting out;ut_echo a;ut_echo b;Commands on this line are still fired
The dumb script engine still prints out a and b.. so if you're debugging and need to comment out the line without ; and "
//Commenting out //ut_echo a // ut_echo b
If you'd like to reapply, simply remove // and place ; at the appropriate places
This too gives problems
//"Comment"
^URT script engine chokes and tries to follow quotes..
#2
Posted 27 June 2011 - 08:56 AM
thebastard, on 27 June 2011 - 08:09 AM, said:
You were undoubtedly trying something in an incorrect manner.
I have never noticed that long script lines are the source of 'bullet jams'. In fact, there is a limit on how long a line can be in Q3 engine. What is known to cause problem is using "wait" commands, which forces the engine to complete the command before accepting new input, such as pressing your MOUSE1 to fire.
This is the longest script line i have in my config and has never caused 'bullet jams' for me:
set gear_set2c1 "gear GaAAVWR; ut_echo ^0|^2DE AK103^0:^1laser ^7helmet vest^0|^5 Tier-1 Spetsnaz; set cf.crosshud.sidearm vstr cf.crosshud.de; set cf.crosshud.assault vstr cf.crosshud.ak103v; vstr cf.handspri_on; vstr cf.weap_base; set gear_set2 vstr gear_set2c2; set cf.crosshud.second vstr cf.crosshud.assault; set cf.zoom.spc vstr null"
thebastard, on 27 June 2011 - 08:09 AM, said:
Changes to in_mouse required in_restart to have it's changes take effect. But this effectively also changes which API is accessed for input: Windows API input or DirectX-Input. Which has different input latency (on Windows). Also MOUSE5(using clients based on more recent ioQ3 branch, where ioUrbanTerror that comes with 4.1 is considered based on an old ioQ3 branch - Pre-SDL) is not recognized for all mouse input devices when using in_mouse -1 (which is the case for me).
thebastard, on 27 June 2011 - 08:09 AM, said:
cg_zoomWrap is by default on 1. There is also a GUI option for it: Options > Gun Settings
thebastard, on 27 June 2011 - 08:09 AM, said:
so when you hit the TAB button, you don't need to restart URT application
Actually that statement is incorrect. Depend on the settings modified. You might still end up needing to restart the client or at least restart the component (vid_restart, in_restart). Depending on what was changed in the config you loaded.
thebastard, on 27 June 2011 - 08:09 AM, said:
<snip>
TAB completion is a feature inherited from ioQuake3. Players using the original Q3 binary will not have this feature.
thebastard, on 27 June 2011 - 08:09 AM, said:
The dumb script engine still prints out a and b.. so if you're debugging and need to comment out the line without ; and "
//Commenting out //ut_echo a // ut_echo b
If you'd like to reapply, simply remove // and place ; at the appropriate places
This too gives problems
; is a command delimiter. Obviously it should not be used lightly.
thebastard, on 27 June 2011 - 08:09 AM, said:
^URT script engine chokes and tries to follow quotes..
I have plenty of lines in comments in my configs which does have "double-quotes" in a comment. Which has never caused any problems. Just a few samples:
////| rgb - red green blue value in either int or float, use spaces or |
////| comma as seperator, e.g.: "1,0.4,0" or "255 102 0" |
seta cl_recordfontsize "5" //?Font for "recording" [int]
seta cl_consoleKeys "~ ` 0x7e 0x60" //!Space delimited list of key names or characters that toggle the console [str|def="~ ` 0x7e 0x60"]
#4
Posted 27 June 2011 - 04:56 PM
Quote
#5
Posted 28 June 2011 - 12:12 AM
Let's all stick to URBAN TERROR shall we? I don't care about "other" builds. All I care about is URBAN TERROR, capish?
1. "You were undoubtedly trying something in an incorrect manner."
"What is known to cause problem is using "wait" commands, ..."
No. That is not my problem.
2.
Changes to in_mouse required in_restart to have it's changes take effect. ......API is accessed for input: Windows API input or DirectX-Input. Which has different input latency (on Windows). ... ioQ3 branch, where ioUrbanTerror that comes with 4.1 is considered based on an old ioQ3 branch - Pre-SDL) is not recognized for all mouse input devices when using in_mouse -1 (which is the case for me).. blah blah blah
No. Again I don't care about other ioBranches.. who cares.. This is an urban terror forum. And using in_mouse -1 fixed my problem. << Needlessly to know as to why that is not my problem either. It is not logical as to why it prevents ANY JAM LOCK. It has nothing to do with any wait statements. (and yes I know about the +vstr issues.. and will try that new build I saw posted that supposedly fixes this, but this isn't my concern right now)
3. cg_zoomWrap is by default on 1. There is also a GUI option for it: Options > Gun Settings
First. cg_zoomWrap is a feature I use.. I use "cg_zoomWrap 0".. kill me for typing 1 instead of 0. And NO.
There's no option for it in Options/Gun Settings. None whatsoever.
4. "Actually that statement is incorrect. Depend on the settings modified. You might still end.. "
^ However most for scripting I'm not overly concerned about changing video settings.. but I'm only talking about bind strings/cvars to the binds. IF ONE APPLIES A BIND COMMAND, YOU DON'T NEED TO RESTART URT. IT'S TAKEN EFFECT IMMEDIATELY. Also as I said most of the *time it works for debugging/easing on reloading scripting changes-- bind TAB autoexec.cfg is safe/effective and I'd say 99% has never been an issue such that I'd have to restart URT at all whatsoever..
5."TAB completion is a feature inherited from ioQuake3. Players using the original Q3 binary will not have this feature."
On Windows build 4.1.1 URBAN TERROR.
"Forums > URBAN TERROR 4.1 TECHNICAL SUPPORT > 4.1 Bug Reports & Suggestions > URT cript Engine bug "
What I provide above are tips that I use that have helped me to debug my scripting. It's for others to use. If you don't have access to it, then post your tips on that forum of the io3branch build. I know this feature is on 4.1.1. I have no idea if its on 4.1.
6. " ; is a command delimiter. Obviously it should not be used lightly. "
Obviously you don't know what you're talking about. Of all the points you've been saying you're way off. ; <<< Should not be interpreted after " // " in a scripting line which in fact the SCRIPTING PARSER PICKS IT UP. IT'S A BUG AND A REASON WHY I NAMED THIS ARTICLE. IF YOU'RE NOT USING URBAN TERROR BUILD (EVEN 4.1 HAS THIS ISSUE)
My POINT IS THIS FOR ANYONE SCRIPTING ON URBANTERROR.. IF YOU WANT TO COMMENT OUT A LINE WITH ;.. REPLACE THE ; WITH ANOTHER CHARACTER BECAUSE LINES WITH ;
EVEN
EVEN
EVEN
AFTER THE // AND ON THE SAME LINE.. THE COMMAND WILL BE INTERPRETED.. THIS A BUG IN THE SCRIPTING ENGINE. BUT SOME NUISSANCE NEWBIE IS USING ANOTHER BUILD AND ONLY QUOTING EXAMPLES WITHOUT IT.
IT'S A BUG.
#6
#7
Posted 28 June 2011 - 01:34 AM
This post has been edited by Slackin: 28 June 2011 - 01:34 AM
/*----------------------------------------------------------------------
All normal mapped(bump mapped) and specular mapped .|^|.
Just a few of many, and more to come.
----------------------------------------------------------------------*/
#8
Posted 28 June 2011 - 02:04 AM
90% sure things in quotes "" are considered to be commands or variables by the engine when it reads in a config, so encasing a comment in quotes does the same thing, also when you use ; and " in a config you have to be careful about how you do it, I assume that'd be a q3 issue anyway, not really "scripting in Urban Terror"
if I wrote
bind x say hello;ut_echo hello
it would echo hello when I run the config but not when I press the key (which is what you would want to happen?)
if I commented that out
//bind x say hello;ut_echo hello
it would say hello when the config is run, because ; takes precedence over //
but if I had it like this
bind x say "hello;ut_echo hello"
it would echo hello when I press the key
and then commented that out
//bind x say "hello;ut_echo hello"
nothing happens at all, the quotes fix things
cyrus: "Camping" is a non-issue for a player that uses his/her head.
#9
Posted 28 June 2011 - 03:06 AM
"In violation of our forum guidelines you have been banned in accordance with them. The duration of your ban is 3 months, after which point your account will be reinstated."
What i WANT to say...
Get the F**K out of our forum, community and go find some other way to spend your time you ignorant, immature unpleasant human being. Oh and by the way, that from me, not my team!
#10
Posted 28 June 2011 - 08:12 AM
RaideR, on 28 June 2011 - 03:06 AM, said:
Get the F**K out of our forum, community and go find some other way to spend your time you ignorant, immature unpleasant human being. Oh and by the way, that from me, not my team!
This post has been edited by H3NRY: 28 June 2011 - 08:12 AM
Hacker?, GTFO! we don't care who you are if you hack.
sadly no servers at the moment