Board ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
scott d. miller // User Search
scott d. miller // User Searchirc-like cmnd line interfaceOct 28, 1998, 2:04am
[View Quote]
What I observed one day at AW GZ was a tourist named "Dr Bob" who was being such
an extreme pest that most people muted him. After several name changes (and remaining muted the whole time) this person left and came back after about a minute (with yet a different nickname), not muted this time. They acted a little better, but they had a peculiar style of moving their avatar around that made us suspect that it was the original person. After awhile it became obvious it was them and many of us muted him again. This makes it seem as if IP address (even if dynamic) is the way a tourist is muted, and that "Dr Bob" must have dropped his connection to his ISP and signed on again to become unmuted. Perhaps we could do some experiments to confirm this. Another test is that tourist can have *exactly* the same name; mute one, are the rest muted too? I suspect that IP address is how it is done, and not nickname. ScottyDM -- Scott D. Miller General Manager & Principal Consultant Arête, Ltd. Please use the return e-mail address of: scottydm at codenet.net irc-like cmnd line interfaceOct 29, 1998, 6:25am
[View Quote]
Sounds like a reasonable speculation Paul. If we really wanted to know we should
go on AW and test it out. ScottyDM -- Scott D. Miller General Manager & Principal Consultant Arête, Ltd. Please use the return e-mail address of: scottydm at codenet.net Idea: if-then-else through obj. actions (server-side variables, etc.)Nov 5, 1998, 11:31am
Basically, this is a great idea. But there are a few holes and some dents
in what you suggest. Such as eliminating the cell size limits; heck, C is verbose, just simplify it. Even throwing out the comments, your example is super verbose (but ok for C). Example of reworked code follows. Place this code on the close door trigger: bump var doorcontrol 0 // or perhaps activate in place of bump Place this code on the open door trigger: bump var doorcontrol 1 On the door itself place (the test doorcontrol==1 is implied): create if doorcontrol (solid off, visible off) (solid on, visible on) This last one assumes "if #1 #2 #3" with spaces as delimiters; where #1 is the variable to be tested, #2 is the true command(s), and #3 is the false command(s). The first time the server encounters a variable name it would place it into its hash table along with a value (0 if not otherwise specified), such as when building. Note that Excel and 123 use an if/then/else structure of "if(#1,#2,#3)" but comas are already used to separate commands and the outer brackets are redundant and not really needed. Another thing I'd really love to see (which would cut the size of the action box commands) are simplified action codes, such as: create = crt activate = act bump = bmp animate = anm solid = sld visible = vsb sound = snd noise = nos name = nam sign = sgn picture = pct warp = wrp teleport = tlp color = clr bcolor = bcl nomask = nms This would reduce the example above to the following. Place this code on the close door trigger: bmp var doorcontrol 0 Place this code on the open door trigger: bmp var doorcontrol 1 On the door itself place (the test doorcontrol == 1 is implied): crt if doorcontrol (sld off, vsb off) (sld on, vsb on) Not a lot of savings, but every little bit adds up. Second, at one point you suggested that the variable name *and* the builder number be stored on the server; later you suggest that as someone is building, the variable name be compared with all variable names on the server to prevent duplication. Wouldn't be easier to simply append the builder number to the variable name? I'm sure more than one person will try to use "foo" as a name. Also forget the text file. Use a hash table instead, much quicker to find stuff. Another possibility is to break off a copy and sort the copy, then temporally lock out access to the variable table and change file names. If the variable table were sorted, finding stuff would radically speed up. Hmmm, there were a few other things too, but I am too sleepy to continue. Goodnight. ScottyDM -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart Idea: if-then-else through obj. actions (server-side variables, etc.)Nov 11, 1998, 1:15am
[View Quote]
--snip--
> The cell size limits need to be eliminated not just for something like this. > Cell size is just too damn annoying. At least include the option "unlimited" > along with normal, large, and huge. Free choice or something like that, > y'know? :) The other limit that would need to go is max characters in an > ACTION field. It's somewhere in the range of 256 characters if I remember > right. Not that your ideas below are bad... in fact they're good. I just think > the server should at least have the OPTION of killing the cell limit. You have > no idea how quickly I filled up every portion of my world even on huge.... Cell size was not dreamt up just to annoy us, it has several purposes: 1st, it keeps frame rates reasonable because some people would jam 1000 objects into a single cell if the server would let them; and the hapless victim who stumbles within visual range of such a mess would suddenly see their frame rate drop to about 0.2 or something. 2nd, it keeps building bots and inept builders from trashing the database with 1000 copies of walk029h laid down on top of each other. 3rd, it helps control the amount of storage required on the server. 4th, (and this is a speculation) the database on the server may have fixed field sizes for each cell; so as soon as a cell is used at all, it takes up its fully allotted limit. --snip-- > I think there is one matter we need to cover, though. Create var variablename > 4, for example, is only activated ONCE, and never again. This creates a > variable variablename, sets it to 4, and WILL NOT I repeat WILL NOT reset it > to 4 everytime you leave the area and come back. If you want something to do > that, you'd use create set variablename 4. This one is activated whenever it's > rendered on someone's screen. This one IS NOT activated whenever the variable > variablename is changed. If it worked that way, it would never change long > enough to do anything, since the create scripts are rerun everytime one or > more of the involved variables changes. Just a couple things the program needs > to check. "var" commands only activated ONCE for the world (unless the > variable is somehow removed from the world's list), and "create set" commands > only run through again when someone leaves range and reenters, or someone new > enters range. Other "create" commands involving vars ("create if" for example) > are rerun everytime an involved var changes (because the server gives out that > info immediately). Here I strongly disagree. There is no way to limit the execution of a "line of code" in the action box to only once. Nor is there any way to control the order that objects are encountered in (which controls the order that the code is executed in). The only reason that create is used in modern programming languages is because it is the "modern" thing to do; that is it leads to easier to maintain code because it offers easy answers to niggling little questions like, "What is that!? <confused programmer points to a user defined name in some source code>". So in this instance "var" is not the same as a C/C++ "var" it simply tells what ever is executing the code that the next word is a variable, the = 0 is implied. And yes, every single time someone bumps the object, the variable is set back to 0. Although, scan down a little further to see another idea on how to parse variables. The actual creation of variables is quite simple actually, it happens automatically the first time you type that variable name into the action box of an object and then "drop" the object. Which brings up the problem of the hash table becoming hopelessly cluttered up with orphan variable names (they currently do not appear in any action boxes on any instances of any objects in the world). Perhaps some kind of on-line garbage collection could be used to periodically clean the hash table. --snip-- > And if true or false isn't what we want, it's a simple matter of making if > doorcontrol into if (doorcontrol==4783). So we can make everything just as > before, but it's shorter. Also don't forget "activate for" and "bump while," > both using the concept above. Still, I'm gonna lead that protest for an > "unlimited" option on the server and an object's action field! =D > > for loop ex. (we assume the var zort already exists from somewhere): Of course zort exists, you just named it in the following statement! I know your professors/boss/whoever will have a cow because there is no explicit declaration of variables. Too bad, real programmers know what they are doing without all this "touchie-feelie new-age programming clap-trap" (especially when it breaks the paradigm). > activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) Is it "activate zort = 0,..." or "activate set zort = 0,..." Actually, since AW is not case sensitive there is no easy method to make variable names stand out from the other stuff in the action box. May I suggest appending a special character to the beginning of the name, e.g. %zort. If the system (server or browser) sees something like "%zort=0" it knows that it needs to do a "set zort=0" (not that "%" means "set", it does not, "=" means "set"). Without a special character, then the "language" must have a key word preceding the variable name to be able to make sense of stuff (and "activate" does not count since it can be followed by almost anything). In this example the use of the "zort<4" is unnecessary and the code could be rewritten: activate %zort = -4, for %zort (warp +0 +0 +1a, ++%zort) In "old style" code (my first post) it would be: activate var zort -4, for zort (warp +0 +0 +1a, ++zort) As long as zort (or %zort) is not zero, the loop continues. I know that having a test other than a simple true/false test is convenient, but believe you can get a heck of a lot done without it. This "for" command is interesting, but I'm not really convinced that it is all that hot (without additional controls, like how often it increments (ms of delay)). This behavior can be emulated by other techniques. However if the loop is decoupled from the object displaying the action, then interesting things happen (which is why the need for the delay command, like in animate). --snip-- > activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) (visible off, solid > off) Hmmmm, I don't get it. Are you changing the syntax? How about if I retype it: activate begin set zort = 0; // or does zort = 0; work better? for (zort < 4) begin warp +0 +0 +1a; ++ zort; // sorry, is this correct C syntax for increment? end visible off; solid off; end If this is what you had in mind then the correct syntax for the visible off etc. would be: activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort), visible off, solid off > And in this case once the loop is over the thing becomes invisible. Of course > this one only affects you, and we here at the AW realism group don't like > that! =D Quite true. To prevent confusion I will use "var" to mean that the word following var is a variable to be set to a new value. Thus the correct code would be: activate var zort -4, for zort (warp +0 +0 +1a, var zort ++); create if zort (visible off, solid off) (visible on, solid on) This is of course if you want the clicked object to turn invisible while the person is being squirted up into the air (note the semicolon at the end of the first line). The ++zort has been bugging me, it just does not seem consistent with the way the other stuff works so I changed it just a little. Wow, this must really be getting muddled up and confused for most readers, we have a "system" <I laugh at that term> of syntax that is wildly inconsistent at this point. --snip-- > What I'd really like to find out is if my variable distribution method is even > possible (server immediately sends the var update out to anyone within X cells > of an object using the variable), since I'm not totally sure the server even > keeps track of the client's position. In fact, I'm pretty darn sure it > doesn't. This could create a little problem. So I ask you all out there... HOW > can we get the server to do variable updates to everyone near an object using > a variable that has changed? I offer the following: This is done now of course. How do you think the system knows what stuff to download to you? Plus, for security purposes, all chat is funneled through the server. It should be a simple matter to: #1 update all variables when the user first wanders into visibility range. #2 keep track of the user's ability to see an object and send the user updates on a variable's value if it should change (kind of like chat dialog, but in this case between the server and the browser). --snip-- ScottyDM -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart Idea: if-then-else through obj. actions (server-side variables, etc.)Nov 11, 1998, 1:19am
[View Quote]
--snip--
> The cell size limits need to be eliminated not just for something like this. > Cell size is just too damn annoying. At least include the option "unlimited" > along with normal, large, and huge. Free choice or something like that, > y'know? :) The other limit that would need to go is max characters in an > ACTION field. It's somewhere in the range of 256 characters if I remember > right. Not that your ideas below are bad... in fact they're good. I just think > the server should at least have the OPTION of killing the cell limit. You have > no idea how quickly I filled up every portion of my world even on huge.... Cell size was not dreamt up just to annoy us, it has several purposes: 1st, it keeps frame rates reasonable because some people would jam 1000 objects into a single cell if the server would let them; and the hapless victim who stumbles within visual range of such a mess would suddenly see their frame rate drop to about 0.2 or something. 2nd, it keeps building bots and inept builders from trashing the database with 1000 copies of walk029h laid down on top of each other. 3rd, it helps control the amount of storage required on the server. 4th, (and this is a speculation) the database on the server may have fixed field sizes for each cell; so as soon as a cell is used at all, it takes up its fully allotted limit. --snip-- > I think there is one matter we need to cover, though. Create var variablename > 4, for example, is only activated ONCE, and never again. This creates a > variable variablename, sets it to 4, and WILL NOT I repeat WILL NOT reset it > to 4 everytime you leave the area and come back. If you want something to do > that, you'd use create set variablename 4. This one is activated whenever it's > rendered on someone's screen. This one IS NOT activated whenever the variable > variablename is changed. If it worked that way, it would never change long > enough to do anything, since the create scripts are rerun everytime one or > more of the involved variables changes. Just a couple things the program needs > to check. "var" commands only activated ONCE for the world (unless the > variable is somehow removed from the world's list), and "create set" commands > only run through again when someone leaves range and reenters, or someone new > enters range. Other "create" commands involving vars ("create if" for example) > are rerun everytime an involved var changes (because the server gives out that > info immediately). Here I strongly disagree. There is no way to limit the execution of a "line of code" in the action box to only once. Nor is there any way to control the order that objects are encountered in (which controls the order that the code is executed in). The only reason that create is used in modern programming languages is because it is the "modern" thing to do; that is it leads to easier to maintain code because it offers easy answers to niggling little questions like, "What is that!? <confused programmer points to a user defined name in some source code>". So in this instance "var" is not the same as a C/C++ "var" it simply tells what ever is executing the code that the next word is a variable, the = 0 is implied. And yes, every single time someone bumps the object, the variable is set back to 0. Although, scan down a little further to see another idea on how to parse variables. The actual creation of variables is quite simple actually, it happens automatically the first time you type that variable name into the action box of an object and then "drop" the object. Which brings up the problem of the hash table becoming hopelessly cluttered up with orphan variable names (they currently do not appear in any action boxes on any instances of any objects in the world). Perhaps some kind of on-line garbage collection could be used to periodically clean the hash table. --snip-- > And if true or false isn't what we want, it's a simple matter of making if > doorcontrol into if (doorcontrol==4783). So we can make everything just as > before, but it's shorter. Also don't forget "activate for" and "bump while," > both using the concept above. Still, I'm gonna lead that protest for an > "unlimited" option on the server and an object's action field! =D > > for loop ex. (we assume the var zort already exists from somewhere): Of course zort exists, you just named it in the following statement! I know your professors/boss/whoever will have a cow because there is no explicit declaration of variables. Too bad, real programmers know what they are doing without all this "touchie-feelie new-age programming clap-trap" (especially when it breaks the paradigm). > activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) Is it "activate zort = 0,..." or "activate set zort = 0,..." Actually, since AW is not case sensitive there is no easy method to make variable names stand out from the other stuff in the action box. May I suggest appending a special character to the beginning of the name, e.g. %zort. If the system (server or browser) sees something like "%zort=0" it knows that it needs to do a "set zort=0" (not that "%" means "set", it does not, "=" means "set"). Without a special character, then the "language" must have a key word preceding the variable name to be able to make sense of stuff (and "activate" does not count since it can be followed by almost anything). In this example the use of the "zort<4" is unnecessary and the code could be rewritten: activate %zort = -4, for %zort (warp +0 +0 +1a, ++%zort) In "old style" code (my first post) it would be: activate var zort -4, for zort (warp +0 +0 +1a, ++zort) As long as zort (or %zort) is not zero, the loop continues. I know that having a test other than a simple true/false test is convenient, but believe you can get a heck of a lot done without it. This "for" command is interesting, but I'm not really convinced that it is all that hot (without additional controls, like how often it increments (ms of delay)). This behavior can be emulated by other techniques. However if the loop is decoupled from the object displaying the action, then interesting things happen (which is why the need for the delay command, like in animate). --snip-- > activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) (visible off, solid > off) Hmmmm, I don't get it. Are you changing the syntax? How about if I retype it: activate begin set zort = 0; // or does zort = 0; work better? for (zort < 4) begin warp +0 +0 +1a; ++ zort; // sorry, is this correct C syntax for increment? end visible off; solid off; end If this is what you had in mind then the correct syntax for the visible off etc. would be: activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort), visible off, solid off > And in this case once the loop is over the thing becomes invisible. Of course > this one only affects you, and we here at the AW realism group don't like > that! =D Quite true. To prevent confusion I will use "var" to mean that the word following var is a variable to be set to a new value. Thus the correct code would be: activate var zort -4, for zort (warp +0 +0 +1a, var zort ++); create if zort (visible off, solid off) (visible on, solid on) This is of course if you want the clicked object to turn invisible while the person is being squirted up into the air (note the semicolon at the end of the first line). The ++zort has been bugging me, it just does not seem consistent with the way the other stuff works so I changed it just a little. Wow, this must really be getting muddled up and confused for most readers, we have a "system" <I laugh at that term> of syntax that is wildly inconsistent at this point. --snip-- > What I'd really like to find out is if my variable distribution method is even > possible (server immediately sends the var update out to anyone within X cells > of an object using the variable), since I'm not totally sure the server even > keeps track of the client's position. In fact, I'm pretty darn sure it > doesn't. This could create a little problem. So I ask you all out there... HOW > can we get the server to do variable updates to everyone near an object using > a variable that has changed? I offer the following: This is done now of course. How do you think the system knows what stuff to download to you? Plus, for security purposes, all chat is funneled through the server. It should be a simple matter to: #1 update all variables when the user first wanders into visibility range. #2 keep track of the user's ability to see an object and send the user updates on a variable's value if it should change (kind of like chat dialog, but in this case between the server and the browser). --snip-- ScottyDM -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart Idea: if-then-else through obj. actions (server-side variables, etc.)Nov 11, 1998, 8:08am
Ok, how about this:
VARIABLE TYPES, CREATION, AND MANAGEMENT For the sake of simplicity, a simple 16 bit signed integer could go a long way, however making it a signed 32 bit integer really does not "cost" much extra. At this time I cannot see other types, such as floating point, strings, or characters. Whether 16 bit or 32 bit, we should just pick one and stick with it. At this time I believe that the 32 bit signed integer is the better choice. Variable creation will happen the first moment the server finds out about a variable. Typically, this is the first time a variable is named in the action field of an object and the object is "dropped". Variable management can be facilitated by a command in the browser to list all variables owned by the user in this world. The list would be dumped to the chat window as a comma delimited list. The list is not broadcast but only sent to the screen of the person who owns the variables (or has inherited their privileges). Two commands would be recognized: A dump command, and a command to delete variables (using wild cards). The simplest and most extensible way to implement the commands is to type them to the chat window. A special escape sequence starting in the first character position on the input line would let the server know not to broadcast the message to all in the area, it is a server command. Something like: \\ dumpvar (dump all variables to the chat window) \\ delvar dooropen (delete the variable "dooropen") \\ delvar foo* (delete variables "foo", "foobar", and "foofight") \\ delvar * (delete all variables) If you happen to delete a variable that is in use somewhere, then the next time someone comes into visual range of the object that variable is associated with, it is placed back in the hash table with the default value 0 (unless the action field of that object happens to set the value of the variable). NAMING THE VARIABLE, CONVENTIONS TO USE -- I can see two possibilities: #1 The variable can be any reasonable alphanumeric string. By reasonable, I mean it starts with an alpha (upper or lower) and subsequent characters in the name are alpha (upper or lower), numeric, or underscore character. The system knows it is a variable name because it follows a keyword that requires a variable name. #2 The variable name MUST start with a restricted character, such as "%" (I will use "%" in all the following examples, although this could be any special character, e.g. #, $, *, etc. Note that only one special character can be used for this function, we just need to pick one). The rest of the characters in the name can be any alpha (upper or lower), numeric, or underscore character. As the system is parsing the command line in the action box, it will see the "%", realize that the attached string is a variable name, and use it as such. The simplest and most consistent thing is to ALWAYS force the use of the "%" character. Using this convention will allow the use of variables in other places, such as in an animate command: create animate me stone 15 1 0 %foo Where %foo selects WHICH stone texture to use (from 1 through 15). It could also be used in the color command to make sign colors pulse and change. It could even be used in a warp or teleport command as part of the coordinates! Even though the variables are integers, in the case of a teleport/warp coordinate, a decimal point could be assumed at the first digit so that teleporting/warping could be to the nearest meter. Picture this: A Star Trek like transporter device with buttons on a control panel. People stand on the platform and someone pushes a button to select the destination, then another button to "engage". You get the cool sound and end up at your destination! Now that I think about it, forcing the use of a special character as the first character of every variable name makes a lot of sense. All further examples will assume the use of the character "%". SETTING THE VALUE OF THE VARIABLE -- I see a couple of possibilities here: #1 The use of a keyword, such as "var" or "set": var <NAME> <VALUE> set <NAME> <VALUE> The spaces are required delimiters and are the way the systems knows which are the various parts of the command. Examples: set %BamBam 5 // set "BamBam" = 5 set %foo (BamBam + 3) // set "foo" = 8 (assume "BamBam" is still 5) set %foo BamBam+3 // legal because extra spaces are left out #2 Use of an "=" sign to tell the system that you are setting the variable (this works only with the use of a special character as the first character of the variable name: <NAME>=<VALUE> <NAME> = <VALUE> Where the extra spaces around the "=" sign are optional. Examples: %BamBam = 5 // set "BamBam" = 5 %BamBam=5 // extra spaces are optional %foo=(BamBam + 3) // set "foo" = 8 (assume "BamBam" is still 5) %foo = BamBam+3 // set "foo" = 8 (assume "BamBam" is still 5) Personally, I feel that #1 is more consistent with the existing way of doing things: a keyword followed by a space delimited list of parameters. OPERATORS TO USE FOR SETTING THE VARIABLE VALUE -- The following list of operators may be useful: Math operators: + addition - subtraction * multiplication / division, throw away the remainder \ modulo, this is the remainder, throw away the quotient Another pair of desirable operations might be the increment/decrement pair, perhaps using "++" and "--". Increment/decrement kind of becomes a special case of operator. Examples: set %foo ++ // increments "foo" set %foo %foo+1 // also increments "foo" set %foo %fight++ // error, does not load "fight" +1 into "foo" set %foo %fight+1 // is the correct way to do it (IMO) This means that "++" and "--" must stand alone on the right hand side of the equation. Logic operators: ~ binary inversion $ transform into true/false flag & AND | OR ^ XOR The question to ask is whether we want logic operations to be performed across the variable bit-by-bit, or whether we want to reduce the variable to true/false and perform the operation on that basis. Perhaps we could have both if we have a "convert from integer to flag" operation, say using "$". Any non-zero value would be converted to -1 (true), while a zero is simply a zero (false). Examples: set %ewcord 13440&$%flag3 // ok, it is a little jammed up set %ewcord (13440 & $ %flag3) // easier to read? let me explain: if "flag3" is true it gets turned into a -1 by the "$" operator (which has precedence over the other operators). The "&" ANDs this true/false version of "flag3" now controls the value of "ewcord". If "flag3" is true (-1, or #FFFFFFFF) the the 13440 passes passes through the "&" operation and ends up in "ewcord", but if "flag3" is false (0) then the "&" operator blocks the 13440 and "ewcord" gets the value of 0. Special operators: # means interpret the attached number as hexadecimal Examples: set %cows #F5 // this sets "cows" to 245 set %cows #F5+10 // "cows" = 255 as the "10" is decimal set %cows #F5+#10 // "cows" = 261 as the "#10" is hex Note that "#" always touches the number it is associated with. The following examples are legal syntax (IMO): set %cows (#F5 + 10) set %cows (#F5 + #10) ------ WELL, ALL THIS IS WONDERFUL, BUT WE NEED TO DO SOMETHING MORE WITH THESE GREAT VARIABLES THE IF/THEN/ELSE COMMAND Using the model of keyword followed by a space delimited list of parameters, the "else_action" is optional: if <TEST> <THEN_ACTION> <ELSE_ACTION> Before giving concrete examples, it will be necessary to decide what to do with the "<TEST>" parameter. The simplest and most powerful, is to simply allow any equation, then reduce to a simple true/false (non-zero/zero) test. Now the examples: if %flag2 (solid off,visible off) (solid on,visible on) // if "flag2" is true open door if %touchd (noise eagle.wav) () // note the empty "else" if %foo-3 () (noise scream.wav,set %foo 0) // something is incrementing "foo" This is wonderful, except there is no greater-than or lesser-than tests, only this equal to zero (test for false). The following is a way to test for a negative value, which is the foundation of greater-than and lesser-than testing: if $(%index4 & #80000000) <NEGATIVE_ACTION> <POSITIVE_ACTION> if ~$(%index4 & #80000000) <POSITIVE_ACTION> <NEGATIVE_ACTION> Where positive and negative are the sign of the variable "index4" and all variables are 32 bit signed integers. It looks as if it might be a desirable thing to have a simple operator to do this for us... LOOPING CONTROL COMMAND Again the model is keyword followed by a space delimited list of parameters. There are a lot of ways to construct a loop command, for simplicity's sake we should just choose one. It seems slightly more useful to test first because it would allow loop exit without action in the case the test comes out false. The idea of "while" the test is true do "loop_action" seems to be an easily understandable construct. To be truly useful a third parameter of "delay" is added, where delay is in milliseconds (and is optional): while <TEST> <LOOP_ACTION> <DELAY> Examples: while %foo (warp +0 +0 +1a,%foo+1) 2000 This would keep someone bouncing up and down and eventually hitting +750a for a long, long time until "foo" hits 0. while %lights %lights+1 1000 Could simply be used to increment "lights" for awhile. This could be used in a tunnel entrance. On a floor piece at the tunnel entrance you could put: bump set %lights -9 Inside the tunnel you could have a button and a sign that says "lights on" with the following action on the button: activate while %lights %lights+1 1000 On the ceiling panels you could use a manhole1.rwx to look like a round light fixture and put the following code on the next 8 "light fixtures": create if ~$((%lights + 8) & #80000000) (animate me snow1. 1 1 0) create if ~$((%lights + 7) & #80000000) (animate me snow1. 1 1 0) create if ~$((%lights + 6) & #80000000) (animate me snow1. 1 1 0) create if ~$((%lights + 5) & #80000000) (animate me snow1. 1 1 0) create if ~$((%lights + 4) & #80000000) (animate me snow1. 1 1 0) create if ~$((%lights + 3) & #80000000) (animate me snow1. 1 1 0) create if ~$((%lights + 2) & #80000000) (animate me snow1. 1 1 0) create if ~$((%lights + 1) & #80000000) (animate me snow1. 1 1 0) Pushing the button then turns on the "light fixtures" in order at one second intervals. Everyone could then see the lights were on until someone again bumps that floor piece that sets "lights" back to -9. (dang, it looks as if a test for negative operator is really needed) ------ This has gotten kind of long and involved. There is a lot more that could be accomplished with server-side variable storage. I have left out some of the more esorteric things like a CASE statement. IF seems to be the most universally powerful thing (beyond just the existence of the server-side variables). WHILE is useful too, but it does seem a little less intuitive on how it could be used. The most important thing to realize is that instructions are executed in the order that the user finds them. So constructs that split case statements (for example) across multiple objects will exhibit wildly unpredictable behavior. Most of the processing would need to be done in the browser, the server only stores the variables (and displays/deletes them for the user on demand). The server and browser already have other mechinisms in place that could be used to insure that as variable values are updated in the server, all users see the changes almost instantly. ScottyDM -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart Idea: if-then-else through obj. actions (server-side variables, etc.)Nov 11, 1998, 8:13am
Oops, dang, how did this get posted twice.
Stop, ignore this thread and follow the other one. -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart Custom avs are here! - yippee!Nov 24, 1998, 11:54pm
[View Quote]
Right on Dean;
If you want to fight FIRE, you use WATER. What a concept, ehh? ScottyDM -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart This newsgroupNov 23, 1998, 11:47pm
[View Quote]
Oh? Are we going to start a real programmers thread now? As in real
programmers code in Fortran... ScottyDM -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart This newsgroupNov 23, 1998, 11:50pm
[View Quote]
Tyrell, you are a little wrinkled TROLL with pointy ears and big lips.
<waiting to see if Eep² is dumb enough to take the bait> ScottyDM -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart Re: Custom avs are here! - yippee!Nov 26, 1998, 7:50am
[View Quote]
Lame argument Fluxen;
The real world works exactly the way Dean suggested. Show up under dressed or over dressed just about anywhere in RL and you get censored. Show up in Saudi Arabia wearing the wrong thing and you get arrested. Show up at the beach in Rio (Brazil) wearing the wrong thing and you are viewed as a tourist, idiot, or prude. What is wrong with the idea of wanting to control the use (allow or disallow) of custom avatars in one's own world. Because different worlds have different "ratings", it may be possible to to tag an avatar with a rating as well. As long as the avatar's rating is lower or equal to the world's rating, it is allowed to be used there (if custom avatars are allowed in that world). The problem is that the rating of the avatars must be voluntary. Perhaps there needs to be a way to visually "mute" an offending avatar -- turn it into a "tourist" avatar. ScottyDM -- Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to scottydm at cwia.com Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net ___ /////\\ Digitally Enhanced Portrait of: {|-0-0-|} Scott D. Miller, | % | Silicon Mercenary \===/ Freelance Chip Designer always #5 FOO = ~FOO; // the sound of a beating heart |