Board ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
henry todd // User Search
henry todd // User Search*pbbt* HoloCorp splitting up with Cognitive Labs *Warning large image attached*Apr 6, 2000, 2:57am
Idea: if-then-else through obj. actions (server-side variables, etc.)Nov 4, 1998, 1:14am
Note: I realize this is LONG. Try to bear with me, I think I might
really have something here. Well, I know everyone enjoys (err...) yelling at COF about stuff like privacy features, but I thought maybe I'd toss in a suggestion for a feature related to building (just how many years has it been since something significant changed in the building stuff?). This post is laid out in sections because the topic has so many issues. Now, the message subject is probably confusing some of you, so I'll get right to the point. Those of you who understand the if-then-else structure and variables (for example, anyone at COF lucky enough to be reading) can skip right down to section 2 to see how this applies to AW and building. Those of you who don't, read this little section below so you're not hopelessly lost. 1. A quick lesson in programming Those of you who know anything about programming in basically any language will recognize the idea of if-then-else. In C, the "if-statement" tests a condition. For example, "if (variable==3)" checks to see if the variable (basically a piece of data... in this case, a number), which is aptly named "variable" is equal to 3. If so, it would continue and execute the statement(s) below that line. Below the statement to be executed, you would probably find an else statement. The statements that follow are what is executed should the if-statement be false. For example, if variable was equal to 4. Once these statements are completed, the program continues on with the next statement, whatever it may be. 2. The point Okay, you're not here to learn C. You want to know what this has to do with AW (some of you might be taking guesses). It's as simple as this: If the ACTION field of an object could take some simple, C style scripts and the AW server program could store some variables, it would allow for all sorts of new and interesting building developments (not to mention games, but we'll leave that for later). Eep, if you're listening, I bet you could come up with around 10,000 great ideas to use with this before you finish this sentence.... 3. Why? You all know that we have a number of actions and triggers to use on objects. But, there's a problem with them. They all work on the client side only. Perhaps you've built a door with a switch to open it. You press the switch, you see the door open, you walk through it. The problem is that everyone standing around you sees you walk through a solid door. Okay, who cares, right (I do! I do!)? Not only that, the door is closed as soon as you walk away and come back. Or, if the switch is too far away and your visibility is too low, it won't open the door for you at all. Once again, these are all minor annoyances. But remember, folks, as Eep reminds us now and then (and you thought I completely hated you! :) ), AW is losing its "edge." The novelty wears off, and it's time for some content. The way a door works is only the tip of the proverbial iceberg. I'm looking at a feature which would allow a little more realism in the mechanism of ACTION commands, AND the ability to create, for example, a complex RPG (Role Playing Game) in that world you bought. Programmers know what I'm thinking of. Gets better than that, but I'm not near done yet. 4. How (Simplistic version)? Okay, the light details (stick with me, folks). The current system with the object ACTIONs runs totally off the client that triggers them. This keeps the server from... you know... exploding. It also means you can't trigger an ACTION on something outside your visibility, one that affects someone else, or one that lasts for an extended time. So what do I want to do? Contrary to popular belief I do not want to make ACTION things server side (running off the server). I want this: Variable storage on the server end (solves all of the problems above and introduces new possibilities), and C style (doesn't have to be C... but it's easy to learn and pretty darn short) scripting interface through the object ACTION box (allows for access and modification of the variables via ACTION box, not to mention triggers). 5. How's it work (Simplistic)? It's really pretty easy. This is the simple explanation. Keep on reading for more detailed "how's it work?" suggestions. The server program stores all the variables you declare (variables don't exist until you tell the program they do, since I didn't mention declaration before). You declare them in the ACTION field of an object via a statement such as "int BoboVar", which would create an integer variable called BoboVar. So now that you've got a variable stored on the server, do something with it! You'll use a combination of standard AW ACTION syntax and the C code (once again JUST A SUGGESTED LANGUAGE BASIS... I know the AW programmers know C very well so I can use it here freely) to manipulate these variables. The variables will also help you work the triggers. For example, you could set up a device for the following: if BoboVar was equal to 1 (probably got that way by someone triggering an activate command on a button), you could have a panel become "visible off" and "solid off". Everyone to come to this location until something was triggered which returned it to "solid on" and "visible on" would be able to pass through it and see through it. Everyone in the area would see it open when the trigger was activated. Cool huh? There are some problems, but I believe I've already solved them. I'll explain the problems and solutions later. 6. Let's hear some more about the door.... (People who have never seen C might want to move on to 7... but this is easy stuff) Let's cover the door thing again for those of you who know what's going on. :) You have three objects in the middle of nowhere. One "pp07.rwx" and two "pole2m.rwx"s. The pp07 is our panel and the two pole2m's are going to be our "buttons" (well they don't look like 'em, but everyone knows the pole objects). Below I'm going to explain what goes in each object's ACTION field and what the stuff does. Note that anything following the double slashes is a comment I've added to help you folks. The real script wouldn't have 'em. pp07.rwx has the following in ACTION: int doorcontrol = 0; // declares an integer variable and sets it to zero if (doorcontrol==1) // does our variable equal one? if so, go on with the stuff between the "odd braces" { // begin statements to be performed should the above test true visible off; // invisible please solid off; // I wanna walk through this thing } // end statements to be performed else // if the if-statement was false, do what's in the odd braces. someone, what's the tech term on those things? { // the stuff below is going to make sure the door is closed as long as doorcontrol isn't 1 visible on; // make it visible! solid on; // make it solid! } // and we're done Okay, that wasn't so painful! This simply creates the variable we'll use to control the door and explains to the software that it should be open when it's 1 and closed when it's 0 (or anything else, for that matter). Take a look at it without comments: int doorcontrol = 0; if (doorcontrol==1) { visible off; solid off; } else { visible on; solid on; } Easy, right? Right. Let's move on, remembering that the variable doorcontrol is now on the server, and we don't have to worry about sending this info to the other object. (Note: We'll talk about how much server space this uses and why it shouldn't be allowed in AlphaWorld later) first pole2m.rwx's ACTION field: activate doorcontrol = 1 Wow! That was easy, huh? All this does is set doorcontrol to 1 when you click on the pole. The door now pops open and stays that way for everyone. (NOTE: Those of you who know how AW works are seeing a problem right here. The pp07 should have to update in order to know that it's supposed to be open! We'll cover this soon. Trust me, it works. =D) second pole2m.rwx's ACTION field: activate doorcontrol = 0 Sets doorcontrol to zero, door closes. Wahoo, we're done!! We've just created the first door in AW that works for everyone, not just the one who opened it! Too bad it doesn't really work yet, huh? 7A. Okay, if you're so smart, HOW would it work? (we're gonna get technical now) So you wanna know more. That's good, because I've thought of basically everything (I think). First, where are these variables going? I'm going to suggest they're stored in a simple text file in the directory world.exe is in. How much space do they take up? One byte per character. Average variable would probably take up about 10 bytes on the drive (perhaps 15 if the server stored the owner's cit number with it). On second thought, it'd probably be harmless to use them in AlphaWorld, but we'll leave that up to COF, no? The ability to have variables, and how many variables each user could "own" in a world are up to the world owner. More about the variables: When your client loads an object into the scene which uses any variables, it immediately asks the server "what is the value of <variablename>?" (in a shorter form of course) for any variables there (this could be mixed in with the standard "anything changed?" packet the client sends out every single time you leave the visibility range of an object and come back, close the program, etc.). Once it receives the values it runs the scripts on the objects. So........ it goes: check objects for use of variables, ask about variables used, receive answer from server, run scripts. It all happens within a portion of a second assuming lag isn't bad. It's fast and it's easy. It doesn't slow anything down (well, by half a second if you're entering an area you don't have cached). Even more about variables! self. variables for that matter. Such as Quake's "self.health". A "self." variable is stored client side and does not go to the server unless a script specifically tells the client to send it in with a command such as "store self.health". This would put a variable with the user's name, a dot, and the second part ("King Henry.health" for me). This could later be called up with something like "recall self.health", in which case the client would ask for self.health from the server, and the server would send back yourname.health ("King Henry.health") which would update your client's self.health. This is one way to go about making an RPG with "save points" that could be played for a long time. The data limit... It would have to go. I suggest the following: Instead of a data/cell limit, make it an object/cell limit, with the server allowed to set ANY number of maximum objects per cell (or COF could remove it all together for all I care). Now, to solve the most annoying problem.... How does a change in a variable that effects an object next to you effect it on everyone else around you's computer if the ACTION is still client side? This will require a new subject. Read on, everyone! 7B. A little client remodeling? It won't hurt a bit! We need to solve a major problem. Sure, COF could figure it out, but I'll save 'em the trouble! Normally the client only refreshes objects when they're changed or you leave the area and come back (or you trigger something that affects them). This is no good. The objects also need to be refreshed when a variable attached to them changes. Here's how it can work: Let's say that, in the world NoName, there are 60 variables. There are 4 people there for this example, standing in the same cell. Now, when one of them does something that changes a variable (opens the example door from earlier), their client sends off a short packet to the server that tells what variable and what the new value is (the packet is probably about 5 bytes). Server picks it up, and changes it in the text file of variables (Note: Due to the fact that the server would run checks on vars while you're building, such as "does this variable name already exist, and if so, do you own it?", there would be no need for it to verify anything at this point). Now, these four people nearby wouldn't see the door open under normal conditions until they walked away and came back (actually it'd be that you'd wait 60 seconds until the client did a "did anything change?" packet)! This is where we employ some technology of ActiveWorlds that I don't totally know about. Little while back, they added a feature which made changes in building appear instantly to people around you. I don't know if your client tells the other clients directly or what, but a simple employment of this feature (Bobo presses the button, his client tells the server that the variable is changed, server tells anyone near an object that uses that variable that it has changed) would fix all the problems. When the other three people receive the variable info, their clients rerun the script for the door and it opens. Once again, all this happens very fast. So... we have this: I change variable, client tells server, server tells people within range of objects (could be more than one, and they don't have to be close to each other) using variable, all objects using the variable are refreshed by all people who see them, changes stick. Whew! We're almost done! 8. Server Script! Yes the server itself should have an "action box." It can take the same kind of stuff, but it's executed every single time a variable in it changes (or maybe every 30 seconds if a variable inside has been changed? Well whatever). This way the server could, going back up into 7A, say that if self.health was less than 1, you get teleported back to GZ and self.health resets to 30. So basically, if you lose all your health, you "die" and start over. All the self. vars are client side, so everyone who enters gets one. So... with one little command the world caretaker just set the world up for a game of Quake or dodge the lava pits! =D 9. Okay that's it I give up. Well, I hope I've bored most of you to sleep and maybe even successfully explained an idea to a couple of you. Err... maybe the other way around? Well I hope someone out there got all this and... you know... kind of likes it. Suggestions, comments, flames (scratch that), criticism, something I forgot to explain, additions, pointers about things I said that would never work/would cause other problems? For Bob's sake reply (to the newsgroup please)! Should you reply, It'd be easiest if you either did just a general comment or went through the message and put in your replies under the section that it belongs under ("variables suck" belongs under the second section =D). Eep, Grover, don't fail me now! I know you folks can easily outdo me in programming. Say, anyone from COF read this? Roland: "Zzzzzzzzzzz......" Yeah I didn't think so. Henry Todd Idea: if-then-else through obj. actions (server-side variables, etc.)Nov 4, 1998, 12:26pm
[View Quote]
> You should email this to roland at activeworlds.com to be sure that he sees it,
> he doesn't always read every NG post but he reads his email. > Wow someone actually read it! I had originally considered just sending it directly to him, but didn't for two reasons... one, I wanted some feedback from other users, and two, I thought it might be rude to drop a 16K e-mail on the guy. Maybe I'll send it on over anyway. :) Henry Todd Idea: if-then-else through obj. actions (server-side variables, etc.)Nov 5, 1998, 1:57pm
[View Quote]
> Basically, this is a great idea. But there are a few holes and some dents
> in what you suggest. > Of course! This is why I post it here instead of sending it to COF directly. > 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. > 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.... > Place this code on the close door trigger: > bump var doorcontrol 0 // or perhaps activate in place of bump > 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). > 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. > Not bad. Not bad at all. And this way the whole thing is based on existing syntax structures, giving the programer (darn it what ever happened to the good old days when we had TWO programmers? =D) even less work to do, making it just a little more likely that it could actually happen. 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): activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) Simple enough. When you click on the object, zort is set to zero and the loop begins. It sees that zort is less than 4, you fly into the air, it increments zort, you fly higher, yadda yadda yadda. When the loop finally results in a 0, it sees that there are no statements to be executed upon reaching the end of the loop and stops. You fall and fall and faaaaaallllll.... Had you wanted to have something happen you could have done it directly such as: 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 For this we assume zortvisible was set to 1 by something else. Perhaps a bump panel. create if zortvisible (visible on, solid on) (visible off, solid off) activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) (zortvisible=0) Now the thing becomes invisible to everyone when your ride is over. That is, until someone else bumps the previously mentioned panel. > 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. > Quite true. This way everyone can have a var named "spork" instead of spork245. > 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. > Not my area. If you say it's faster, go with it. > Hmmm, there were a few other things too, but I am too sleepy to continue. > Goodnight. > 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: 1. The original suggestion, but it's a matter of figuring out how the server can do it. Perhaps it could keep track of where you are based on a "cluster" of four or eight cells? This wouldn't be very taxing on either end, as, for example, you're still at GZ in the server's opinion until you move to 2N, then it doesn't update again until you hit 6N, 10N, and so forth. 2. Every second the server does a general broadcast of all the variable updates to everyone. At 15 bytes/var (just a high estimation) this would be harmless. Remember that it only sends data on variables that have changed! Your client requests variable info when it's requesting object info, so this is something we don't need to worry about. Even in AlphaWorld, chances are the highest number of vars that will ever change in a single second is about 10. That's 150 bytes to each user, or 15K total transmission (assuming 100 people). The server could handle that a million times over! and for those servers running on 28.8s... well they won't ever have more than around 8 people in them anyway. 1 var/sec * 8 is a whopping 120 bytes or .12K. And that's your maximum. Besides, you could always turn variable use off. I think we may have a winner! Assuming the server prog can't handle #1. 3. Hey Roland... you figure it out! The bell's gonna ring soon, gotta head to the next class. Seeya! > 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 5, 1998, 2:08pm
[View Quote]
[View Quote]
Actually scratch the whole "set" thing. One command can create and set variables.
Apply everything I wrote about "create set" to "create var" and throw away the stuff about create var. Let's do it again... all this below is about "create var" (specifically "create var variablename 0") 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 little thing the program needs to check. "create var" 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). What this means is that creating a variable with the "create var" command is only for something that resets a la today's create commands, just for everyone at the same time. Now, there should also probably be an external interface to mess with your variables if you're running the server. For example, if you had a server, you could load up a small util that would let you add variables and change values of existing ones. If not, you could always do it the "other" way and build an "activate var" button everytime you wanted to set one, then delete it. Idea: if-then-else through obj. actions (server-side variables, etc.)Dec 3, 1998, 10:01pm
[View Quote]
[View Quote]
Well, I'm quite aware of the reasoning behind it. I just think that owners of
personal worlds should be given the option to say "adios" to it. Instead of normal, large, and huge, use normal, large, huge, and unlimited. I paid for it, I'll kill my framerate if I darn well please thank you very much! ::insert evil villain laughter here:: > --snip-- > > 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. > Well, I was simply referring to the concept of the use of create to define a variable. Every time you refreshed your objects the var would reset itself. But, if we don't even need to define variables in the standard sense, the point is null and void. And the other issue related to this is that the action field has a very small maximum character limit. > 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-- > > 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). Pffft. I'm a high school freshman, my "boss" doesn't even know what a variables is beyond that X he used in pre-algebra. :D > > > > 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-- > > 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? Yep, without the space between the ++ and zort, anyway. > 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 > To tell you the truth, I can't remember what I was doing at the time. Been a month now. :) > > 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. > See my next message for the big "DOH!" that relates to the fact that this whole thing is not needed. > --snip-- > > 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). Couple extra packets... should be harmless enough. > > > --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 MP3 SupportMar 11, 2000, 11:48pm
This is a multi-part message in MIME format.
------=_NextPart_000_00C2_01BF8B9B.03D2C680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [View Quote] Quite true... and unlike Napster, AWCOM really couldn't handle any big = MP3-related legal issues.=20 But uh.. still... all hail Napster! Winamp doesnt take much CPU load (I run AW, Winamp, two Visual Studio = instances and 3 browsers at once with no prob on my P2300 64meg comp). =20 My question is this... why doesn't someone just make a frontend for = mp3s? Only people who are in to them are gonna use them/care anyway and = they'd all download the frontend software. Not sure about AW third = party software limitations, but that shouldnt be a prob. If a non = working action tag such as create mp3 URL were used, the frontend would pick up on it(using the sdk), download = the mp3 and play it using it's own engine. Not to difficult....anyone feel up to it? I'll work on it if noone = else will. Plugins! AW needs to support plugins! For example a plugin to play MP3s = when it reads "create mp3" or one that... Well whatever, but plugins are = a must for a program like this. DLLs tossed into a /plugins directory = and loaded on startup or some such setup... just like 3d studio max. = Imagine the possibilities for 3rd party improvements to the software. -RecilS [View Quote] ------=_NextPart_000_00C2_01BF8B9B.03D2C680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 = HTML//EN"> <META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV> </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV>recils <<A href=3D"mailto:No at Yes.com">No at Yes.com</A>> wrote = in=20 message <A=20 = href=3D"news:38bca1b7 at server1.Activeworlds.com">news:38bca1b7 at server1.Act= iveworlds.com</A>...</DIV> <DIV><FONT color=3D#000000 size=3D2>Yeah limiting the size of mp3s = would=20 work. The mp3 area is probably not the safest place for AW to go = right=20 now, as pirating issues woul become huge. I'm sure 'mp3 = warehouses' and=20 such places would spring up, offering all sorts of songs.</FONT></DIV> <DIV> </DIV></BLOCKQUOTE> <DIV align=3Dleft><FONT face=3DArial size=3D2>Quite true... and unlike = Napster, AWCOM=20 really couldn't handle any big MP3-related legal issues. </FONT></DIV> <DIV align=3Dleft> </DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>But uh.. still... all hail = Napster!</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV><FONT size=3D2>Winamp doesnt take much CPU load (I run AW, = Winamp, two=20 Visual Studio instances and 3 browsers at once with no prob on my = P2300 64meg=20 comp).</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>My question is this... why doesn't someone just = make a=20 frontend for mp3s? Only people who are in to them are gonna use=20 them/care anyway and they'd all download the frontend software. = Not sure=20 about AW third party software limitations, but that shouldnt be a = prob. =20 If a non working action tag such as</FONT></DIV> <DIV><FONT size=3D2>create mp3 URL</FONT></DIV> <DIV><FONT size=3D2>were used, the frontend would pick up on it(using = the sdk),=20 download the mp3 and play it using it's own engine.</FONT></DIV> <DIV><FONT size=3D2>Not to difficult....anyone feel up to it? = I'll work on=20 it if noone else will.</FONT></DIV> <DIV> </DIV></BLOCKQUOTE> <DIV><FONT face=3DArial size=3D2>Plugins! AW needs to support plugins! = For example a=20 plugin to play MP3s when it reads "create mp3" or one that... Well = whatever, but=20 plugins are a must for a program like this. DLLs tossed into a /plugins=20 directory and loaded on startup or some such setup... just like 3d = studio max.=20 Imagine the possibilities for 3rd party improvements to the=20 software.</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV> </DIV> <DIV><FONT size=3D2>-RecilS</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; = PADDING-LEFT: 5px"> [View Quote] ------=_NextPart_000_00C2_01BF8B9B.03D2C680-- News about aw 3.0Mar 11, 2000, 11:38pm
Beta, full, who cares, it's been so many years.... so many long, hard years
since....... .... Actually I don't think AWCOM ever added a useful feature yet. =D [View Quote] Wish for AWMar 11, 2000, 11:41pm
You know what I want? Quake engine style mouselook. You know,
hyper-sensitive left/right/up/down control with pinpoint accuracy. And an MP5 to shoot at... well no, just mouselook will do I guess. [View Quote] I hear you can make an N64->PC converter port thingie for a few dollars worth of parts... but I dunno how =D > > [View Quote] Global Object States ("It's invisible and I can walk through it!" ... "No it's not you moron!")Mar 16, 2000, 12:21am
Well you make a door by having it go visible off solid off right? Problem?
Well, when you open the door, it only opens client-side. This means that everyone else sees it as closed and you glide through a closed door on their screen. Minor annoyance? Yep. But think of the other option and the advantages. EXAMPLE: pp01.rwx action: activate solid off, visible off A simple "door" that goes away when clicked on. That's nice. Wouldn't it be better if the activate trigger could be set up to set some kind of perminant state for the object? So that it would stay open until closed somehow. EXAMPLE: pp01.rwx action: activate state.solid=0, state.visible=0 (note that I made up an example command structure just to show the idea.... as far as I know those are not real AW vars) In this example, clicking on the door actually changes the object itself, setting these two variables (solid and visible) to 0, or off. So the door is opened and will remain open for all eternity until someone does whatever is needed to return it to normal. Or until the builder edits the object which would probably reset it. A simple example, but it could be really useful. Especially for games and the like (Note that I realize bots can be used to do this by removing and replacing the object or actually putting create solid off commands on the object when it's clicked - but this is a real waste or resources and efforts and time and so on). More variables could exist, even things like pos.x, pos.y, pos.z which could be used to actually move the object by a click, bump, etc. Taking that a little farther, the commands like create visible off would be totally obsolete as the object's state.visible variable could be set while placing the object (through some modification to the build window) Adds more to bot interaction too... A bot can then tell if, for example, an object is solid and if it's okay to walk through it ... thus creating sort of a collision detection bot (though this would take more work than that) ....... I'm sure there's better examples, I just don't want to think of them right now. I know this has been around before... but I like to toss things up anyway. ---------------- You must die! I alone am best! Required in AW 3.0 (If it's not too late...)Apr 6, 2000, 1:26am
[View Quote]
Though most likely only due to the fact that a number of them are common sense issues (not that AWCI actually HAS much common sense, but that's another issue entirely), and not them actually reading it.... Hey, look at it this way. At this rate we'll get multiple dynamic colored light sources, just like those first introduced in Quake2, in AW4.0 about 6 years from now. At least it's not software rendering now I guess. =P > [View Quote] |