Why is scripting evil?

(Mean Mr. Mustard) #21

Don’t forget the all important command (at least for me…)

/map_restart

Once you map is successfully loaded, you can then edit your script and load the changes with the above console command (without having to reload the map! - what a time saver)

When I started scripting, I placed a lot of:

wm_announce "I'm here xx"

commands in the script so I could tell where and when things were executing.

The first thing I learned to script was a “constructible”. I copied the script from fueldump (for the bridge), commented out most of it until I figured out what was going on. So, I’d suggest some tutorial like that. Where you start with a constructible, have a bare minimal script and explain that. Then start adding more scripting pieces and explain each. You could start just with “built final”, then add “death”, then add “buildstart final” …

(sock) #22

Yep that is very true that the ET/RTCW language is unique and strange in its syntax but scripting languages are becoming a corner stone in modern 3D engines and mappers can longer ignore them.

Adding a new script language to ET at this stage would be mad. ET was originally suppose to work with RTCW, hence way it uses RTCW scripting as a base. Yes alot of coding structures are missing and its version of routines/functions is different but its what people have to work with.

Hopefully with more informed scripting documentation and tutorials ET mappers should not see scripting with dread and more as something that that opens up new possibilities for creativity and inventiveness.

Sock
:moo:

EDIT: tpyos!

(chavo_one) #23

The things that make scripting less than desirable for me are the undocumented parts. Others have said this already, so let me give some examples.

The biggest thing that’s needed is an explanation of how procedural this scripting language is. When I call a function in C, C++, C#, or even perl, there is a procedure of how I get back to my original function. It’s stack based so it’s predictible. But with scripting, I never know if I will get returned to my calling function or not. djbob went over this a little bit in his explanation of resetscript, but I’m not sure he completely explained the issue. This problem is the biggest hindrance for me when trying to do original scripting.

The other thing that’s needed is a full explanation of scripting commands and their arguments. Case in point, the followspline command. We know very little about all of the abilites of this command (and I know you are already aware of this particular example sock. :slight_smile: )

(Hewster) #24

Just wanted to remind peeps of the fabulous crimson text editor
http://www.crimsoneditor.com/

Those of you who have beem scripting in notepad, will be surprised
at how nice it is to work on a script when all the different keywords
are hightlighted in a different colours…

I think it needs to have its .script definition file updating with the new ET
commands, since it currenty only supports RtCW… a little project for
someone there :slight_smile:

Hewster

(blushing_bride) #25

:clap: im really looking forward to the new LDR, the list of stuff in the index looks great. Im sure scripting is something that anyone can understand so long as its explained properly. I would like to express my thanks to SD for contiuning to support ET even though they are all busy making DoomIV Return to Castle Enemy Territorystien 2. :clap:

(Ifurita) #26

I personally really like the scripting, even though it made me bang my head against the wall many times. Then again, I am a self proclaimed script (config) monkey.

I really like how I can make fairly significant changes to the map via scripts without making any modifications to the .map file. There are great opportunities to make random objectives or even change victory conditions mid-game

For me, given that I am new to both mapping and scripting, it’s a way of bringing some neat features into a map that would have taken just as long had I learned to do this via entity chaining.

Also, with scripts, it seems like there is the possibility that a mapper can build a more open ended map and allow the users to edit scripts (or include multiple scripts) to fundamentally change the map. You could include both returnable and destructible objectives and turn one or the other off via the script.

Just a couple of ideas

(sock) #27

Yep, very cool commands but “g_scriptdebug 1” is even better as it shows every command/routine/function execution to the console log file. I will add both points to the documentation.

Yep hands up for the followspline system I have a good example in mind which I need to finish. I will add it to the list of things to do. This caused me no end of trouble when I was doing the fueldump scripts until djbob kicked me in the right direction, so I understand what you mean.

Will add it to the list. Got TextPad and UltraEdit at the moment. If someone does the syntax highlight file that would be helpful to know.

Certainly would be cool idea and something no one has done much with so far. I’m sure there will be someone who will moan about the random factor but personally I think it is a nice change to static maps.

Sock
:moo:

(Milbo) #28

I didnt read all above because I have to say (after the first post of Sock),… that I love scripting and it is the most interesting part of mapping,… but my problem is that I dont understand the Entities,…I need a description how they work (yeah in the ent.def but I know this now hehe but before it was try and error),…I try to explain. If u blow up an entity it calls the function death. I didnt know that and tried many things until I saw that, NOW it is very usefull, because I can trigger anything I want if something is blown away.
Or another Example is the Flag. After I realised how the Entity works (that the flag is switching the SpawnEntities and I dont have to switch it by script. and so on,… a better reference for the entities than the ent.def would be very nice. If I script for q3-eng it is like programming a microcontroller without reference and only some textfiles of working progs. :slight_smile:

(Mean Mr. Mustard) #29

sock,

Can we have a tutorial/example of how to get a vehivle (truck or tank) to go up a hill and come down one? (ie. correct placement of spline points and control points - is there a limit to the amount of slope one make a vehicle turn up or down?)

It seems like I can only get one set of wheels correct. If the back wheels follow the terrain, then the front wheels float in the air. If I get the fornt wheels correct, then the back wheels plow into the ground. I’ve looked at goldrush, but it looks so easy. If I try to mimic it, it doesn’t work.

May be I just need an explanation how the vehicle follows the spline. Does the origin of the model follow the spline path as shown with bobtoolz? And then, how is the angle of the vehicle determined?

Thanks

(ZoSo) #30

OK, I’m totally new to the whole mapping thing. I have no experience in any type of coding, and thanks to the very helpful people here, things are starting to click. But getting to that point is the frustrating part(and I still have a long way to go yet), I think for most of us that is the biggest problem. Also the way things are explained on how they work or what they do, are over many peoples heads, even though it might sound very simple to the people trying to explain it.
Look at this little tutorial by MadMaximus (scroll down, you can’t miss it)
http://www.splashdamage.com/forums/viewtopic.php?t=5142
You don’t know HOW MUCH that helped me, and I’m sure it helped many others too. It might look like kids stuff to the more advanced mappers out there, but it worked great for me! I think more tutorials or explanation of things should be like that or very similar. It’s basic, it shows you step-by-step, and most important, it doesn’t overwhelm you with so much technical lingo that you get lost in it and almost forget what you where trying to do, to begin with!
Well, thats my opinion :wink:

Thanks,
ZoSo

(Erik-Ftn) #31

Hi I’ve done some programming when younger and have a fairly good hang of scripting by now.

What I’ve understood from reading at simland “nuts and bolts” article and by trying it out myself this is some of the features of scripting.

  • A routine can have several functions simultanously running, but:

  • If any function in a routine contains a “timebased” command, like wait, gotomarker w wait (and resetscript) , etc it will interrupt and quit all other functions in that routine from running.

  • A trigger command in a function will hold the further execution of that function if its triggering within its own routine but not wait if its triggering a function in another routine. (the latter will actually start another execution thread, so to speak)

Im sorry to say this but to have this poorly documented, is just to invite frustration into your livingroom and start bringing in the starters. There is really no consistent logic to it.

The question is : what is the basic underlying logic of this thing?

Also, if you have to script something you’re doing a (mental) detour. Mapping in Radiant is one (cognitive) sphere and scripting is another. When switching btw two such spheres it takes at least 30 mins for the brain to adapt to the new basic underlying logic and I guess the fact that scripting logic is 1. different, 2. not documented and 3. sometimes strange (see above) together will make that change really awkward many times. (hehe as in both for many ppl and many times :slight_smile: )

I would like to see Appendix A in the LDR complete, more elaborate (ideally, exhaustive) on different use of each command (eg u kan use “kill” to kill off one construction stage, attachtotag won’t work on shooters), and incuding all standard functions and their entities.

standard functions that I know of

brushes w health:
pain
death (also in trigger_flagonly_multiple)

some triggers and func_invis_user:
activate
activate allies
activate axis

TOI:s
dynamited

targeted by TOI:
defused

team_CTF_checkpoint
captured allies
captured axis

team_CTF_*flag
trigger stolen
trigger dropped
trigger returned
trigger captured

func_constructible
buildstart <>
decayed <>
built <>
destroyed <>
death

also the fact that func_explosive does not call its death function if its not targeted by a TOI and set to constructible_weponclass 3 is really really annoying :slight_smile: (as in no consistent logic)

Finally I would like to say that in my experience I think people not accustomed to programming or hands on experience of ie machines easily miss the fact that you will have to keep track of every single thing when programming/ scripting. In mapping the nice GUI actually does things for you while in scripting you will have to do it yourself (I mean information-wise, if you understand what I mean.)

cheers

Erik

(Lanz) #32

I’ve never seen the ET script as complicated, I took a look at it, understood the principles and started to work with it. I havent mastered it, and there’s things I dont know but overall it’s really basic. One of the reasons for this is that I’ve been programing for a very long time. The thing that might make it feel strange might also be the fact that it’s supposed to be executed quickly, not hang up the process for any longer periods of time and just generally being created for doing some basic, trivial things. It does it’s job, the syntax is a bit strange but that goes hand in hand with it’s simplicity imo. The guy/guys that did it knew what was needed and didnt do more than neccessary with the language in itself (Variables will not be used that much, accums will work fine, no complicated if statements, etc etc…).

(Milbo) #33

Absolut right,… this tutorial was the breakthrough for me.

(Oxygen - o2) #34

SCRIPTING WAS INVENTED BY SOMEONE WHO HATED MAPPERS!!!

(Ifurita) #35

Great attitude for a guy who plans to make a total conversion mod

(hummer) #36

I <3 Scripting. :smiley:

Only thing pissing me off atm is getting movers (specifically the truck) to move over hills and look decent… but Mean Mr. Mustard is helping me out with that…

(leifhv) #37

Ok, just had to comment on this…execution speed has nothing to do with the problems that exists in the ET scripting language. The scripts are (hopefully) parsed to a more compact internal format anyway.

Also, the statment ‘Variables will not be used much’ does not make much sense. Variables would be used everywhere where accums are used today, and every other programming language I’ve ever seen have them. So I think we can say that variables is commonly accepted as a good idea when it comes to designing programming languages.

No, we don’t have ‘complex if statements’…instead we have to fake if/else constructs using trigger and abort statmens which leads to much more complexity than a better if statement would ever have.

Don’t want be too negative here…ET and it’s mapping tools is great gift the us all, but the scripting language is IMO clearly the weak spot of the tools we have access to when doing ET mapping.

lh03

(Mean Mr. Mustard) #38

Scripting is great - what possibilities you can do with it… :smiley:

hummer - ah, you might want to use your original truck path once you see the mess I’ve made of it :smiley:

(leifhv) #39

This discussion finally motivated me to create some C/C++ macros to help me when doing scripting for ET.

This is the top of my script file now:


#if defined DEBUG_BUILD
#define DebugMessage(msg) print msg
#else
#define DebugMessage(msg) 
#endif

#define false 0
#define true 1

#define AbortIfTrue(variable) variable abort_if_equal 1
#define AbortIfFalse(variable) variable abort_if_equal 0

//Defines specific to this script
#define BoxThatHaveDecoder accum 1
#define HaveDecoder accum 2

This allows me to do this further down:


////////////////////////////////////
// Box stuff
////////////////////////////////////
boxA
{
	spawn
	{
		HaveDecoder set false
		wait 200
		constructible_class 3

	}

	trigger dontHaveDecoder
	{
		HaveDecoder set false
		DebugMessage("DBG: BoxA dont have decoder")
	}

	trigger haveDecoder
	{
		HaveDecoder set true
		DebugMessage("DBG: BoxA have decoder")
	}

	death
	{
		wm_announce "Allies have blown up box A!"
		AbortIfFalse(HaveDecoder)
		wm_setwinner 1
		wm_endround
	}
}

Note that I now use an informative ‘HaveDecoder’ for variable name instead of the obscure ‘accum 1’

So this kind of fixed my bigges complaint; the lack of variable names.

I’ve added the following line at the top of my compile.bat:


cl /DDEBUG_BUILD /EP maps\decoder-p1.script > maps\decoder.script

This produces the script that ET loads and executes.

Here I use the Microsoft Visual C++ compiler…but any other compiler should also work. If you use Linux you allready have GCC installed and can use that.

I’m not saying that everyone should do this…you probably should not! =)
It might cause more problems for you than it fixes. Also, I’ve just made this and have not been using it for long…might discover some problems with this apporach later on.

lh03

(Lanz) #40

Accums are not used that much, I know it’s more complicated than being able to use variables, but it’s easier to create a scripting language using accums than variables. It does the same thing and since you dont use that many of them it works just fine.

Doesnt matter if it’s “parsed to a more compact internal format anyway” if you use loops it takes more time (yeah you wont notice it mostely), it might hang the game if used wrong and the purpose to have any is more or less none.

If statements even if you fake them to something more complex is still very simple, not as in a more “proper” program.

When I look at the scripting language I see a programmer that didnt want to spend a whole lot of time to make it complex even if it meant it would have an unfamiliar syntax.

It’s hell of a lot easier to make a scripting language like this:
accum 1 abort_if_not_equal 1

Rather than this:
if (motorRunning != 1) exit