Chalks
Level: Master Delver

Rank Points: 267
Registered: 04-17-2005
IP: Logged

speech "Well, after asking a question about variables...I got my answer: We can't use em!"
x=0

label "variables please"
if...goto "hooray"
x=5

x="number of people who agree"

speech "I would LOVE to have variables in my scripts. It would make loops far easier to manage. Besides, aren't variables the basic building block of any program? That's what the scripting feature is... a simple programming language."

goto "variables please"


label "hooray"
speech "Hooray!"
end

---

[Last edited by Chalks at 01-19-2006 08:19 PM]

Schik
Level: Legendary Smitemaster

Rank Points: 5383
Registered: 02-04-2003
IP: Logged

So you will only celebrate if exactly 5 people agree?

____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

Swivel
Level: Master Delver

Rank Points: 236
Registered: 09-14-2005
IP: Logged

This is something I’ve always sorted wanted, but if you think about it, it must be extraordinarily hard to program a scripting language. In JtRH, you have a dialogue box that chooses what line you should put in. Otherwise, with type-in entries, you would have to program something that sorts and deals with errors. This can take up most of the scripting program.

Variables can also be programmed conspicuously, like a character who advances one space every turn. If the character is in a specific space, he might be “less than,” “greater than,” or “equal to” a greater area.

For example, a character might advance one square every time you teeter (I’ve always thought that to be a funny word) over a pit or awaken an eye. If a character reaches a place after stepping 5 times (quince), then something bad happens. This seems to be the closest we can get.

For waiting for a number of events, you should code:

Wait for Schik to throw away banana
Wait 1 Turn(s)
Wait for Schik to throw away banana
Wait 1 Turn(s)
Wait for Schik to throw away banana
Wait 1 Turn(s)
Speech mrimer “Schik, you’ve thrown away 3 bananas!”

Chalks
Level: Master Delver

Rank Points: 267
Registered: 04-17-2005
IP: Logged

Swivel wrote:
This is something I’ve always sorted wanted, but if you think about it, it must be extraordinarily hard to program a scripting language.....

.....For waiting for a number of events, you should code:

Wait for Schik to throw away banana
Wait 1 Turn(s)
Wait for Schik to throw away banana
Wait 1 Turn(s)
Wait for Schik to throw away banana
Wait 1 Turn(s)
Speech mrimer “Schik, you’ve thrown away 3 bananas!”

True, it probably would be difficult. Maybe just add a looping command that says, perform loop for x number of turns?

The second thing you said actually is exactly what I was trying to do. I didn't even think of making Schik throw bananas...that helps me a ton! Thanks!

Seriously...that really does help.

RoboBob3000
Level: Smitemaster

Rank Points: 1978
Registered: 10-23-2003
IP: Logged

x++;

Even though there is a workaround, I still support the addition of variables simply with my experience of trying to incorporate them into the scripting in my hold not dr0d. The password rooms each have five characters, with 26 loops for each letter. And the only way I could get characters to speak what letter they represented in a different room in the hold was to incorporate the functionality, that's right, 26 different times.

I would have killed for a speech "variable" command at that time.

____________________________
http://beepsandbloops.wordpress.com/

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

Swivel wrote:
This is something I’ve always sorted wanted, but if you think about it, it must be extraordinarily hard to program a scripting language.

Errr... no?

Adding a few statements for manipulating variables (Assign, Increment, Decrement, Add, Subtract, Multiply, Divide; not a full expression parser, even though that's not that much work, either) and another if-condition isn't really that hard.

And storing them as name/value pairs in some appropriate data structure is easy.

Even writing a compiler isn't that hard - the hard part starts when you want to optimize the resulting code for speed...

(Okay, so maybe I'm biased - I'm currently marking exercises in compiler construction as a second job... )

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

AlefBet
Level: Smitemaster
Rank Points: 979
Registered: 07-16-2003
IP: Logged

One of the nice things about not having variables is that right now the scripting engine is effectively equivalent to a finite state machine, and FSMs have a lot of simple guarantees about them. For example, it is very easy to determine whether a finite state machine (with epsilon transitions) is looping infinitely without consuming input, which makes it easy to tell if a character script is incorrectly written. By adding variables, you get close to Turing completeness, and it is literally impossible to detect (in general) an infinite loop in a Turing-complete model. This means a mistake in a script could cause the game engine to hang while it loops forever. Naturally, the game engine won't want to allow that, so it has to resort to some ad-hoc way of guessing if a script is looping forever and aborting it.

There's not a nice clean answer for that, so when do you give up on a script? The common approach is to wait until after it runs for a certain number of instructions without waiting for input from the player. So, let's say after 1000 instructions the script automatically aborts. What if the script would have completed on instruction 1017? So, you're tempted to say 1000 is too low and want to put it up around, say, 5000. Now, we're starting to run into a noticeable delay on slow computers. And whatever you set that number at, it's stuck forever (even if all the computers do get faster), because if you change it, old holds will start to act differently when "broken" scripts start to run properly under the new constraints (except they've never been tested...).

I'm not saying variables will never be put into DROD scripting. I just want people to know that what they're asking for has more issues than simply throwing it into the engine.

____________________________
I was charged with conspiracy to commit jay-walking, and accessory to changing lanes without signaling after the fact .

++Adam H. Peterson

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

AlefBet wrote:
This means a mistake in a script could cause the game engine to hang while it loops forever. Naturally, the game engine won't want to allow that, so it has to resort to some ad-hoc way of guessing if a script is looping forever and aborting it.

Nitpick: I said it wasn't hard to *program* a scripting language.

*Using* them to do The Right Thing(TM) is another matter...

And actually, what causes an endless loop are, well, loops - not variables alone. Just having boolean or integer variables to flag or calculate stuff and being able to use them as parameter to some other script functions would probably be very useful - I haven't designed a single room yet, so MMMOV (my mileage may obviously vary).

np: Flanger - Hope To Hear Back Soon, Honey (Spirituals)

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

stigant
Level: Smitemaster

Rank Points: 1182
Registered: 08-19-2004
IP: Logged

The common approach is to wait until after it runs for a certain number of instructions without waiting for input from the player. So, let's say after 1000 instructions the script automatically aborts.

I was under the impression that this is actually what DROD is doing currently. Although, the limit is not hardcoded. I believe its something like "if the script executes more instructions in a row than there are in the entire script without giving control back to the game/user, then its probably stuck."

____________________________
Progress Quest Progress

AlefBet
Level: Smitemaster
Rank Points: 979
Registered: 07-16-2003
IP: Logged

stigant wrote:

The common approach is to wait until after it runs for a certain number of instructions without waiting for input from the player. So, let's say after 1000 instructions the script automatically aborts.

I was under the impression that this is actually what DROD is doing currently. Although, the limit is not hardcoded. I believe its something like "if the script executes more instructions in a row than there are in the entire script without giving control back to the game/user, then its probably stuck."

Yes, and the beauty of the current system is that this reliably works for detecting infinite loops. Once you start to execute the same instruction on the same room state, you have gone into an infinite loop, so if you execute more instructions than can be in the script, you must have repeated one and are in an infinite loop.

However, it won't work if variables are added in. Once you have variables, you can execute just about every instruction in the script, but after the tenth time through, you can terminate, and this would be correct behavior. So, how does the game engine tell when a script is looping forever, or just taking a few/several cycles to figure something out?

____________________________
I was charged with conspiracy to commit jay-walking, and accessory to changing lanes without signaling after the fact .

++Adam H. Peterson

stigant
Level: Smitemaster

Rank Points: 1182
Registered: 08-19-2004
IP: Logged

Well, since the number of instructions that the game will allow a script to execute is proportional to the number of instructions in the script, and the key point here is for a script to have enough oportunity to do what it needs to do, two things could happen:
1. The developers could increase the constant of proportionality (ie a script can execute 10x the number of instructions in the script before we decide its in an infinite loop)
2. If that is still too low for a particular script, the architect can add additional dummy lines of code to the script to increase his ceiling.

Its not a perfect hack, but I think most things that people will want to use this feature for can be accomodated.

____________________________
Progress Quest Progress

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Another way to fix it could be to simply keep track of variable state for every script line, or (better) only keep it for those lines that reads a variable. If a line is executed twice with the same variable state, we've got an infinite loop. This would of course slow down scripting (got to compare state and save new) and require obscene amounts of memory for executing large scripts, as every variable used in the script would in effect be stored once for every variable-reading script line ..

It also wouldn't catch alternating states (x = 1, label loop: x = -x, if x != 0 goto loop).

- Gerry

---

[Last edited by trick at 01-20-2006 05:48 PM]

eytanz
Level: Smitemaster

Rank Points: 2708
Registered: 02-05-2003
IP: Logged

That will eliminate one kind of infinite loop. But if you have variables, other kinds are possible. For example, you won't have any way of telling the two loops apart:

Finite loop:

x = 0
label "loop"
if x = 10 goto "exit"
x = x + 1
goto "loop"
label "exit"

Inifinite loop:

x = 0
label "loop"
if x = 10 goto "exit"
x = x - 1
goto "loop"
label "exit"

(Oh, I see that while I was writing you edited your post. Oh well, I'll leave mine up)

____________________________
I got my avatar back! Yay!

---

[Last edited by eytanz at 01-20-2006 05:49 PM]

eytanz
Level: Smitemaster

Rank Points: 2708
Registered: 02-05-2003
IP: Logged

By the way, I should say that the "variables allow infinite loops" argument, while true, is a pretty bad argument against variables. Sure, if you use them, you need to be careful - more careful than systems without them. But in reality, if there's a hold with infinite loops in it, they will either A - be caught in playtesting, or B - be evidence that the hold didn't go through playtesting and people won't play it (there's a third option C - they will only arise in very rare circumstances and thus have escaped notice. But if that's the case, then it's easy to just avoid them. This is a game, after all, not some sort of mission-critical application, and if there are some minor bugs in user-created content, so be it).

I think the main question about variables in the conceptual one. Variables will add a lot of power to scripters. The question is - do we, (either "we the community" or "we the dev team" would be applicable here, at least as far as I am concerned), want scripters to have that power? The problem isn't when they'll misuse this power to cause infinite loops and bugs. The problem is when they'll use the power for the exact sort of thing it was meant for - more robust scripts, generally ones that interact with gameplay elements. Is that a good thing, or a bad thing? I'm leaning towards "good", at the moment, because there are already enough ways to create bad puzzles with scripts that it doesn't really matter if we add a new one, but there are never enough ways to add good puzzles. But I think that this is where the interesting debate lies - at least as far variables in DROD go - rather than in the tradeoffs of computer program engineering.

____________________________
I got my avatar back! Yay!

AlefBet
Level: Smitemaster
Rank Points: 979
Registered: 07-16-2003
IP: Logged

trick wrote:
Another way to fix it could be to simply keep track of variable state for every script line, or (better) only keep it for those lines that reads a variable.

That would go some way towards detecting such loops, and while it does involve some extra computational power, it is certainly doable. There are a lot of infinite loops that it just wouldn't catch, though. For example:

    set i=1
loop:
    increment i
    if i!=0 goto loop
    speech Beethro "I'm done now!"

Adding variables is starting to get pretty close to Turing complete, and I think that all we'd need to get Turing-completeness is the ability to create an arbitrary number of variables on the fly in a script. Once that happens, it's provably impossible to detect a runaway script.

If it's really a worthwhile addition to the game and enhances the ability to make good holds, we might want to add it anyway. But at that point, we have to face the decision of whether we want the potential for broken scripts to freeze the game engine or the potential for working scripts to fail because of breakage detection.

____________________________
I was charged with conspiracy to commit jay-walking, and accessory to changing lanes without signaling after the fact .

++Adam H. Peterson

eytanz
Level: Smitemaster

Rank Points: 2708
Registered: 02-05-2003
IP: Logged

AlefBet wrote:
If it's really a worthwhile addition to the game and enhances the ability to make good holds, we might want to add it anyway. But at that point, we have to face the decision of whether we want the potential for broken scripts to freeze the game engine or the potential for working scripts to fail because of breakage detection.

I know you were writing this while I was writing my post, but I should like to stress again that I think that's exactly the kind of decision that really isn't very important in this case.

____________________________
I got my avatar back! Yay!

Mikko
Level: Master Delver
Rank Points: 276
Registered: 02-04-2003
IP: Logged

I think the infinite loop problem can be avoided by simply restricting the possible values for variables. 0-99 or 0-255 should be a big enough range for most situation and when it isn't, multiple variables can be scripted to behave as one with a bigger range. The special case when variables need to allow arbitrarily high values (e.g. to check if Beethro has killed more mud or tar babies) could not be implemented, but I don't think it really matters. In the example above, three variable combined to one should suffice as nobody is likely to kill millions of mud/tar babies.

coppro
Level: Smitemaster
Rank Points: 1308
Registered: 11-24-2005
IP: Logged

x= 5;

loop while (x=5)


The End.

Chaco
Level: Smitemaster
Rank Points: 3630
Registered: 10-06-2005
IP: Logged

We haven't implemented loops yet, just variables for "if mudbabies <= 5" cases.

____________________________
Quick links to my stuff (in case you forgot where it was):

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

Chaco wrote:
We haven't implemented loops yet, just variables for "if mudbabies <= 5" cases.

Ummm...

"If ..." and "Label" and "Goto" together a good loop make.

You could even drop "while" and "for" from C/C++ and still make loops with "if"s, labels and "goto"s. Yes, kids, it's probably a little-known fact, but both C and C++ still allow goto statements.

All those fancy-shmancy loop statements are just syntactic sugar, after all...

(Or you could just deprecate goto in hope of more readable code, or just use Intercal for the opposite... )

np: Future Sound Of London - Path 4 (Lifeforms EP)

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

---

[Last edited by Briareos at 01-21-2006 10:56 AM]

Chaco
Level: Smitemaster
Rank Points: 3630
Registered: 10-06-2005
IP: Logged

I hereby declare that I do not know what I am talking about.

____________________________
Quick links to my stuff (in case you forgot where it was):

Swivel
Level: Master Delver

Rank Points: 236
Registered: 09-14-2005
IP: Logged

Chaco wrote:
We haven't implemented loops yet, just variables for "if mudbabies <= 5" cases.

No, no, I get you. You count the number of monsters in a room and make quantitative scripting judgements. DROD Scripting doesn't really have an object-oriented base (with individual objects having full awareness of eachother's variables). This isn't a complaint, it just doesn't.

____________________________
"Write a wise saying and your name will live forever."
-Anonymous

Mikko
Level: Master Delver
Rank Points: 276
Registered: 02-04-2003
IP: Logged

If the loop thing is a big problem, then here is one way to avoid it:

Only adjust variables when an action is performed. When a variable is given a new value (e.g. t=8 or t=t+1), the script stores it in a temporary variable and then gives this value to the proper variable when an action is performed.

This can cause some confusion. E.g. if t=5 at the start and it is then adjusted by t=8 followed by t=t+1, then the end result is t=6. As far as I can see, though, no important functionality is lost. At most, some additional if statements need to be included in the script. I think that is a fair price to pay for completely avoiding the infinite loop problem.

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

Mikko wrote:
If the loop thing is a big problem, then here is one way to avoid it:

Only adjust variables when an action is performed. When a variable is given a new value (e.g. t=8 or t=t+1), the script stores it in a temporary variable and then gives this value to the proper variable when an action is performed.

So you want a loop that counts down from 10 to 0 to loop endlessly right from the start, since the value never changes within the loop?

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

eytanz
Level: Smitemaster

Rank Points: 2708
Registered: 02-05-2003
IP: Logged

Briareos wrote:

Mikko wrote:
If the loop thing is a big problem, then here is one way to avoid it:

Only adjust variables when an action is performed. When a variable is given a new value (e.g. t=8 or t=t+1), the script stores it in a temporary variable and then gives this value to the proper variable when an action is performed.

So you want a loop that counts down from 10 to 0 to loop endlessly right from the start, since the value never changes within the loop?

That's not a problem - as mentioned earlier, it's easy to check if nothing changed. The problem is that when something changes, it's difficult/impossible to check whether that will eventually lead to the end of the loop.

Bah. If you saw my second paragraph earlier, forget it. It was wrong.

____________________________
I got my avatar back! Yay!

---

[Last edited by eytanz at 01-23-2006 02:15 PM]

geomatrx
Level: Smiter

Rank Points: 339
Registered: 08-31-2004
IP: Logged

I was working on a scripted room that sort of acts as a calulator to determine how many secrets/cash/bananas you have collected.

Basically, It involves a visible scripte at each entrance. When you appear at this entracnem the script will end, and another script will appear and make its way down a narrow corridor (like a marble down a tube). There will be another scipt that checks this position and displays "ONE".

When appear at another entrance in the room, another script will activate as above, and move down the corridor. This time though, the script will get stuck because there will be another NPC in front of it. The display script will consider this and display "TWO" instead of one.

The script can be modified so instead of simply displaying "TWO", it could move to a location, strike an orb, whatever.

g

____________________________
Get my holds:
MetDROiD AE
MetDROiD Prime
MetDROiD Echoes
Deadly Gold Mine of Death (Architecture)

cheese obsessive
Level: Master Delver

Rank Points: 219
Registered: 10-10-2004
IP: Logged

geomatrx wrote:
I was working on a scripted room that sort of acts as a calulator to determine how many secrets/cash/bananas you have collected.

Basically, It involves a visible scripte at each entrance. When you appear at this entracnem the script will end, and another script will appear and make its way down a narrow corridor (like a marble down a tube). There will be another scipt that checks this position and displays "ONE".

When appear at another entrance in the room, another script will activate as above, and move down the corridor. This time though, the script will get stuck because there will be another NPC in front of it. The display script will consider this and display "TWO" instead of one.

The script can be modified so instead of simply displaying "TWO", it could move to a location, strike an orb, whatever.

g

You make me sick.


And just incase we need another vote, I would totally support variables, because I tried to do something in my hold that required it. But I couldn't get it to work, because of the lack of variables. I would also support a 'float' command, which lets NPC's float over pits, insteading of programming "Dissappear, Appear, Wait." I would also also like relative scripting. It would make my wubba raft so much easier to make...and probably a bunch of other things.

Ezlo
Level: Smitemaster

Rank Points: 1214
Registered: 01-08-2006
IP: Logged

I have several ideas that would need variables to use as well.

Chalks
Level: Master Delver

Rank Points: 267
Registered: 04-17-2005
IP: Logged

I think I missed the point at which I should have said this, but....


HOORAY!