Jump to content

Kagehi Kohn

Resident
  • Posts

    60
  • Joined

  • Last visited

Everything posted by Kagehi Kohn

  1. Yeah, there are some "less than clean" ways to do it. In this case "less than clean" means, "Not in a way that will let you a) look through a window/door, and see the inside, from the connect sim, or b) do so without the expense of a full sim added. The latter, for most people, being the most prohibitive. I did have the idea for something not entirely disimilar, and it might even work on "large scale" projects, presuming a few things, like a lot of twisty corridors (steam tunnels, perhaps?). A mesh based "structure", or even prim based, if you where clever about where you put the offset prims (while still linking one), in which the "center" of the whole entire level is at a fixed point, but only the elevator, or stairway, etc. is "always rezzed". Rooms, and their contents, sections of corridor, etc. get rezzed, based on tracking who entered the area, and where they are (this thought requires some clever sensing, like, say a custom mesh, with volume detect on it, which defines the "trigger points" needed to see when someone is passing a certain point, and in which direction. then you derez the area they can't get to/see, and rez the next area, they are about to arrive at. Though its more likely you also need to "sense" where they are in general, in case they stop and stand someplace, instead of passing a sensor, or leave the sim, or log in/out, etc. and you need to bring back/derez parts... In principle.. this means you might have, including the place they are at, maybe 5 sections rezzed at a time, per AV. The next one they will be at, and may need to see, the next one after that, in case they run to get there, and the prior two, they just left. If you have, say, 50 such sections, then unless some people decide to all stand in different places in the maze of tunnels, and "force" then to all be rezzed, your might, at worst, have say, 1/4 of them "in world" at any time. It would, in principle, save on a lot of LE, depending on the complexity of the build. And, by making sure that each "part" is centered on the same point, you only need one rezzed for the whole thing, not one with scripts in every part, to move it all about, or some similar mess. Still, would be a rean mess to design, build, test, and custom create, so it worked right. But, for a large building, like a sky scraper.. maybe its not so bad if you could, say, move a second object, ahead of your elevator, to "rez" the next two floors you are about to arrive at. And, thus, gain 50 floors of rooms, instead of, like is common, 2-3 real floors?
  2. Gah.. Ate my post.. Ok, well.. Thinking I will just keep it as the /444 version, but unlock it for anyone that knows it. The RP for this was that my "alternate" self, a female version of me that showed up, due ot magic going wacko in the city, has been playing around, and came up with this thing. lol So, having it work only with the owner, instead of both of my AVs, when she is on, would be.. annoying. Still, only solution I can really think of would be, if I had a damn idea what I was doing, using the website I pay for to create a PHP, which would take a word, send google a "define" request, scrape the noun definition from it, if there, then pass that back as a json.. Except.. don't know jack about how to do that... lol Still, need to do something with the page, eventually. Had ideas, but.. Well, the two most obvious ones run into, "I can't wrap my head around how web on prim will actually behave, and many people turn off, 'play media'". Think they shouldh have created a version of this function that uses the same "permissions" request as you have with teleporting, personally. So, if its "everyone sees it" they can opt to accept seeing it, or not. But, both ideas have similar problems. 1. Interactive signs. Thinking like in one of the recent "futuristic" games, where it detects you approaching a building, and a sign saying "closed", or "here is our menu", etc. "drops down". This one would be OK "if" only the person its supposed to be talking to can see it, in theory, same with a kiosk for a store. Except, not always, but "interacting" with the page is.. iffy. 2. Virtual desktop/single user/but everyone sees what is there, display. See, installed a virtual desktop on my site, but.. since its the client that pulls the page, not SL, I think this means that not everyone "sees" the same content, its streamed "per player", which won't work, if you are looking over someone's shoulder, to see the contents. The only way this "does" work then is if well.. a) you somehow redesing the sight so everyone sees what the one logged in is doing (I don't know how the VD works enough to edit it, never mind fo this, and.. not sure about anything else I might do), b) host the "page" on the object, and "upload" it to the display. The latter is possible, except, you can't tell, I don't think, who is "seing" the resulting page, so, unless they click on it, or something, to see, it has no way of knowing what to show, and it can't give the first person something that is "interactive", but the second one only "what is going on." In short.. I just don't get how, when, and under what circumstances, "everyone" or "just one person" is "seeing" the web content. And, that.. presents problems, over and above it just not working, "at all", if they don't have playback turned on. Still, other than using the page to somehow scrape the data I need, its a whole different tangle of of mess of complications. lol
  3. Forgot to mark this so I got replies in email, when I get replies, so responding late. But.. Sure, completely different engine would work. Except, that isn't the point. The where intended, on the off chance someone in Linden might be looking, to spark ideas of what might be possible to do. One huge limitation SL has imho, besides its nuts land costs, is its prim limits, which make it impractical to actually furnish anything higher than two stories, for the most part, or even, sometimes, justo one story, never mind a real city. So.. Being able to, for someone that can afford to rent space enough (if not a whole sim), to be able to, in effect, offload the "inside" of a building to anothing simulator... would be a huge improvement. We are, imho, already at a bottleneck, when it comes to creating realistic buildings with a lot of floors/rooms. But, mesh has, while helping in some cases, also created a new issue - we can make things look more real, but.. there is a limit to how far you can push that, before you are right back to the, "Not enough prims to do this.", situation. So, a solution that lets you, or someone else, rent land "off sim", as it where, an "link it" to become the inside of a building that is "in sim"...
  4. I got this nuts idea of building a sort of shoulder pet, based around the idea that I accidentally "magicked" the thing into existence - it would listen to things going on, and, with certain limits on interval, blab out stuff related to what is being talked about. So, here is what I intended: 1. Pick the first noun in what was said. 2. Feed this to something online, to get a response back. 3. Pull out the first sentence, and repeat that in channel 0 chat. So, here is the script I managed to, with some dificulty, bang together. It has several issues... key requestid; integer delay = 300; integer last; integer is_json = FALSE; default { on_rez(integer param) { llResetScript(); } state_entry() { //llListen(444, "", llGetOwner(), ""); llListen(0, "", NULL_KEY, ""); llResetTime(); } listen (integer chan, string name, key id, string msg) { if (llGetTime() > 1) //300) { llResetTime(); list words = llParseString2List(msg, [" ", ","], ["."]); if ((llSubStringIndex(msg, "(") == -1) && (llGetListLength(words) > 0)) { integer step = 0; integer len = llGetListLength(words); string word; for (step = 0; step <= len; ++step) { word = llList2String(words, step); //llOwnerSay(word); if (llStringLength(word) > 4) { //llOwnerSay("Here."); requestid = llHTTPRequest("http://en.wikipedia.org/w/api.php?action=query&format=json&prop=extracts&exintro=&titles=" + llEscapeURL(word), [HTTP_METHOD, "POST"], ""); step = len + 1; } } } } } http_response(key request_id, integer status, list metadata, string body) { if (request_id = requestid) { integer test; integer end; string del; do { test = llSubStringIndex(body, "<"); if (test != -1) { end = llSubStringIndex(body, ">"); if (end != -1) body = llDeleteSubString(body, test, end); else body = llDeleteSubString(body, test, llStringLength(body)); } } while (test != -1); // In theory, this might work instead, to get the correct info. // I thought of it after, so haven't tested it. // //string temp = llJsonGetValue(body, ["query"]); //string data = llJsonGetValue(body, ["extract"]); integer dex = llSubStringIndex(body, "\"extract"); string data3 = llGetSubString(body, dex, dex + 300) + "\""; list sentences = llParseString2List(data3, [":"], ["."]); string first_sent = llList2String(sentences, 1); if (llStringLength(first_sent) > 0) if (llSubStringIndex(first_sent, "may refer to") < 0 && llSubStringIndex(first_sent, "This is a redirect from") < 0) { llSay(0, first_sent + "."); llResetTime(); //llOwnerSay(first_sent + "."); } } } }First issue.. I had to cheat, since I can't find a simple, "Is this a noun" lookup online, or even a dictionary one. Ironically, if Google had kept the old "Google Dictionary" interface, this would be all solved, since you could, back then, pull a json from it, sending it a word. Instead, I look for the first thing longer than 4 leters, and assume its something I want to look for. Second - Most responses exceed the max string length. So, even though the data is in json, the "string" that contains the body of the page, short of doing a lot of silly stuff to grap more of the body, when the first string is full up (I haven't bothered to look to see if that is even possible), the resulting json is "broken", for most lookups. In short, the json functions won't work, because, as far as the returned text is concerned, its not a json. Third - Even if this was correctable, it seems that the "piece" I need, i.e., the extract, is nested in a mess of other parts. So, I would have to do something like: Check if the I have a value returned when looking for llJsonGetValue(body, "extract"). If no, then use llJson2List, then search the first list item, as above. Repeat until I either find the result I need, or run out of things to look at. This is doable... But, requires first fixing the bloody, "My string wasn't long enough." issue. So.. Anyone know some "other" service I can maybe use, to find the right data? Or, heck, I suppose googles new "Define:word" thing might work, if I had some idea how to scrape the stuff I need from it... :p
  5. I consider this a two birds type idea. But, I suspect its completely impractical, from a server standpoint, if not from a tech standpoint. So.. What is the idea... something similar to portal apatures (this being the best analogy I can come up with). The two birds this potentially kills are: 1. Camera, like real working ones. 2. Building interiors. So, the prinicple idea is to take advantage of the abilty to create a secondary "camera", which views another location. This isn't used much, but it does exist in some games. In this case, it serves two functions - you could, with restrictions to, say, region owner, have the capacity to set up textures that "watch" another location in the sim. This however is a "side effect" of the true purpose, and may represent enough of a problem to be "will not implement". The real benefit of being able to do this is to create something I will call a threshold object. This would be limited in size, and number, say, max 32mx32m, and.. not sure how many. They would create a physical link, or threshold, that functions like a sim boundary, linking to another sim. The sim itself would be a micro sim, or sorts. I envision one of three options here: 1. Scalable micro - sim. You decide how big the inside of your building needs to actually be, say, a 16mx16m, then a microsim is set up, which matches those dimensions. Connections are at the "sim boundary" on this side, and via the threshold object, in the sim that connects to them. 2. Fragmented sim - something like ban lines create subdivided areas. Without a threshold, any "open" space stares off into blank space (or rather, endless water, like any normal sim), so, you would be constructing a building so that, for example, you have two exists, or even a fire escape, each with a threshold, linking to the sim. The actual sim would be 128mx128m, but you could break it up any way you like. Threshholds, in this case, link the sims "by location", sort of like a TP hub, sort of. Entering the threshold object on "either side" would land you in the connected sim, as though you walked between two normal sims. 3. Non-scalable, boundary linked - a normal sim, again, possibly smaller, since you are only linking via the thresholds, but where you are limited to X number of connection points, along the edge - in other words, you build all your structures, so that the "entries" fall along the edge you want. This is less versitile, and constrains you to, at best, two connections points per building (since, unless the building was the size of the whole sim, it could have, at most, only two adjacent edges in next to each other. This is in contrast to #1, the "scalable" version, where you could simply have the building "be" the same size as the sim, so you have all edges to work with. What this has to do with cameras is this - the threshold would also "see through" to the interior of the building, where the threshold exists. So.. basically, the door to your building, in the main sim, "sees" through to the linked sim, but only inside the bounds of the "threshold" you placed, and same from the inside of the building. You still see what people are doing, through any windows you place "as long as the threshold is big enough to let you, and you can walk between the sims, across this boundary, but placing a solid wall, or window pane, etc. "in the way" effectively cuts off access, but not the view. (And, being an object, instead of an actual sim boundary, attempting to "jump" through the wall lands you inside an empty shell, so they have to actually use the entries you provided to get in and out. So.. What is the point of this? Well, prim counts, and sky scrappers. lol Right now, these are the things you can't do: 1. Have a lot of decoration in your building. 2. Have a lot of real floors in a sky scraper. 3. Have, say, 4-5 floors of a hotel, in which all of the rooms in the hotel are useable, instead of locked, like its some FPS "on rails", games, where everything except the key rooms are locked. 4. Tardis like features (its bigger on the inside). 5. Anything else which requires a lot of prims, and structure, which strain the limits of the existing sim. In short - SL, for the moment, it good at the "Hollywood stage city" effect, but.. it starts having issues when you try to build a working city block. So, I had this mad idea - how do you, transparently, get the same result as a sim crossing, including being able to see people inside, but.. also get all the extra "prims" you need to make the inside of the building more than just a cardboard box, with stuff painted on the walls (sure, you can do a lot with one room, or even a few, but.. like I said, forget having multiple floors, a basement, a secret undergroung lab, or "anything else". Even if you where willing/able to use experience keys to just TP the person to a different sim... it would be nice if there was a... less expensive alternative. ;)
  6. All I can say to that is.. progress or die. Second Life 2.0 will probably manage to do some of that, but, seriously, there is, perhaps not as rapidly as I would like, approaching a time where the excuse that, "Its not intended to do that.", won't stand. Half the game engines out there "disallow" an demand scripting of new objects only due to the need to make them coherent, so people don't whine about "game bugs". But, most of them, going clear back to the clones of Everquest "support" such scripting (and, in fact, its actually probably possible on newer engines to dynamically reload changed to individual NPCs, its just easier to clone the server, or offfline it/them, make changes and propogate changes, than do it on a case by case basis. Heck, even SL needs sim reboots. A lot sometimes.. lol But, no, real games don't do this because they want to create a consistent story, not because its impossible to do SL better. I wouldn't, for example, call the latest Everquest incarnation "better", but its system lets you craft with detail "nearly" as good as mesh, using the inworld tools. It runs somelike "like" a sim, but vastly, and I mean "VASTLY" larger, and everything in the landscape, including the buildings, is voxel data. Got tired of how bad I was at building with it, the delays on some stuff, and how hard it was to actually find certain materials, so haven't been in there for a while, but they where working on adding water, and, yes, the water was going to have the same effects, like swimming, that SL has, yet, it was also going to be "voxel", so you could "poor" it into lakes, streams, pools, fountains, wells, etc. So, yeah, I will keep working within SL, trying to push its limits, but.. I really hope Linden keeps pushing the limits too, otherwise... someone is going to torpedo SL, its only a matter of time, and if its not SL compatible... whole businesses are going to go down the drain with it. And, that is the scariest thing about whether or not Linden has the vision to push those limits, and recognize what is possible (or should be). Fact is, even a "social environment", and its a dang expensive environment, at this point, to only do that with it, isn't worth much if someone else makes one more believable.
  7. but uses substitute anims for "walk", "fly", "swim", etc. Hmm, yeah, that is another one that kind of drives me nuts - swimming. Currently, swimming either requires that "flight" be enabled, or that you have a special AO. There is no direct detection of water as part of animation, nor support for either floating on the surface, or zero bouyancy, or "drifting" to the bottom, instead of falling like a brick. Well that and the whole, "Every game on the planet, even if you don't include the truly insane ones like, "Hydrophobia", support ways to do water effects in what would best be described as a "prim boundary" - i.e., not just prim water, and a special hud, but, actually filling a room, a high lake, etc., with the same "water" as Linden water. Not that I expect Hydrophobia water, which is just insane. For those not having played it, it was based on dynamic warping of the plane of the water, so you could "lift" the water in front of the player, to raise it, hurl objects, and do other insane things. In other words, instead of using a flat surface, or even one with some bobbing effects, if actually stretched the shape of the surface, like pulling taffy. But, apparently, we can't even manage to do, "Make this prim act like Linden water." Sigh... Maybe in time, but for now, I just want to not have to be wearing the Swimmer 2.0 hud to actually swim, when flight is disabled in a sim...
  8. Well, strictly speaking you are correct - there is no "move by path" sort of option, just llMoveToTarget, which an attachment can use to move your AV. Now, if you add in some script to do pathing... (And I mean the equation that exists which follows the control points exactly, not the aweful one where the control points are used to tweak the path... Seriously, you might have more control over the shape of the path with the standard one people always use, but... you have to pre-determine what the path will be, not just pick arbitrary points, which is just... impractical in many cases.) But, in any case, most of the times you would be using movement controls in the context I describe you would not be moving people along a path in that sense - you would be taking controls, employing animations to show what is happening, but letting the player control what is happening. This differs from most ladders, for example, because they tend to work by either a) pop on/off, b) once your are climbing, you are just climbing until the end, and that is it, or c) very, very, rarely have I seen one where you can pause part way up, and short of '"unsitting" manually, there is no option to jump off, halfway up the ladder. In any case, the point of the whole thing is to eleminate sits for these sorts of things, not make it easier to do them. Sure, there is a case in UNIA, for example, where you have to get onto a convayor belt, where being able to force a sit would be helpful (except.. definiing the target would be... interesting, in that case, since it keeps changing as new toys, and sit points, get added.) But, you can get the same result with a ladder, a duct, wall climbing a building that had handholds, etc. by just animation, take controls, and llMoveToTarget. Its not perfect, but.. short of Linden implementing the real thing, its as close as is managable. In any case, the point of using the experience keys to do it is that, once animations exist for it - and I find it absurd that no one has built any for some of this stuff already, just for personal sneak huds, or **something**, the cost is only in figuring out how to define the animation control points, to take advantage of them. And.. really, that isn't that hard. The second aspect to it is the "rezzed and attached" tools. Right now, there is a heavy realiance on third party stuff for this. And, that's not a terrible problem, except, the only way you can get the same result is if a) the object is scripted to attach to owner, and b) its been "pre-accepted" to do what ever animations and stuff it does, before dropping it into the hud/prim that needs to rez it, for each person. Its not practical, especially for the brand spanking new player. But, what I could see is, for example, from where I RP myself - some basic things, like lockpicks, or the like, and the "basic" weapons (non-enhanced, just like a fist fighter, or a knife, or basic gun), being "built into" the hud, to start. I can see when someone needs to level, and choose skills, having the meter object auto-detach, then re-attach, when finished - and more to the point, just wearing the hud, and having the meter just straight attach, without having to have the person wear both of them. They just wear one, and the rest is handled. Once you are already doing this sort of thing... why not add in animation controls (which, heck, already exist for some things, like the one ability that makes someone go nuts and attack people near them, or animated them dead, when they lose all their hit points). Adding in, "Heh, there is a ladder here, would you like to climb it?", isn't much of a stretch, except.. it just doesn't seem to have occured to anyone (kind of like figuring out how to sneak believably, like an actual stealth game). The means to do some of it already where possible, more or less, from a personal hud, and even the tools aspect was, *if* you wanted to pre-accept permissions for everything, before cramming them into your hud/rezzer. But, you couldn't sell/hand someone one of them, and have it just work, not if attachments where involved. As to no one buying such a thing... Well, maybe, but maybe not - UNIA manages to get people to do so.... And, the main cost issue, as you say, is the damn animations - which people just haven't made available...
  9. OK, what do I mean by this title.. Well, I have been thinking long and hard about this for some time, and.. SL's character animation and AOs are OK, but they do some things "badly". So, here is a little story, followed by the SL reality: What should happen: It was time to break in. I crouched, back to the wall, looking down the alley, to make sure there was no one passing by, before quickly rolling across to the opposite side. Another quick look and a quickly climbed the city trash bin, reached up and swung a moment from the bottom of the fire escape ladder, before pullnig myself up, to start climbing. Upon reaching the top I grabbed the edge of the roof, and pulled myself over, rolling quickly into the shadow of the air duct on the roof, where I crouched and took out my tools. A few moments with a screw driver and I was in, climbing through the ducts. What does happen: AV walks into the alley, finds a dumpster, jumps onto the dumpster, finds that the fire escape is not scripted with sits, and is built so there is no way to jump to it, or climb. Rez a prim - sit on prim, drag yourself to the roof. Stand on the roof, maybe try to crouch, but the animation isn't too good for that. Pretend to take appart the cover on the vent. Jump off the building, so you can enter through the doors (hope the doors are not locked) and/or use a wallwalker, and "jump" through the ceiling. Pretends, again, that you got there through the perfectly good duct works. So... Something seems to be... wrong here, and I have spent years trying to figure out how the F you would fix it. lolSo, this is more or less a comment on how fixible is now may be. The new experience key thing, it seems to me, provides an opertunity to do three things that have driven me mad about SL for a while now:1. This one was solvable before, if anyone "bothered" to try (and I would love to, but I don't do animation, so...). By generating a general "map" of the environment around your AV, such as the location and size of buildings, structures, etc. there is "no" reason why you can't mimic things like the FPS style "hug the wall, and constrain movement, while doing this, to right and left, looking around corners, and rolling/moving between cover locations." Just never had the time, or the patience, to try to code one to do this.2. Ladders, ducts, short walls (the dupster), or bloody anything else that uses "sits"... Though, the short wall thing is more a problem #1 situation. This is what I mean by action points, basically, or at least part of it - have the experience key system provide the animations, and the control points, so when you arrive at a ladder, you get a notice that you can climb it, and your E key goes from jumping, to actually initating the bloody climb, like in actual games... Lets lose all the sits for this stuff, which don't work well, and are often missing in half the places that need them, in the first place.3. The final one - being able to actually pull out that screw driver, to make it look like you are actually taking the duct cover apart, on the roof. Oh, and well, hiding the AV, some way, and setting the camera up so you can crawl through the duct work. You know, silly stuff like that, which works because the hud is doing the moving, not the normal walk stuff, so.. you don't have to worry about the silly issue that your AV collision box won't like the duct work...Anyway.. That is the idea. And, its been driving me nuts that, until now, it was, at best, 1/3 to 1/2 possible. lol
  10. Uh.. Wait, so you can't use llAttachToAvatar at all with something that you don't own... Then what the heck is this at all useful for exactly? You would have to temp attach, then "give them" a copy anyway, to get the result. Also, there is nothing in the function description on the official wiki that says it is restricted to the owner, not someone else who happens along, which you want to, say, be the first to "find" something... ... Argh!!! This must have been an actual bug of some kind, which got fixed since I posted the question. I just did the same bloody thing I did last time, exactly, with the same script, and a new object, and its bloody working as I expected. Previously.... it failed, every single attempt to attach the previous copy. /me bangs head on desk, while contemplating which Linden to blame for the headache. Right.. nothing to see here. Move along, move along. lol
  11. Not going to go into why I was trying this, I don't want to restart the argument, but.. in the prior cases I had someone insisting, "This works fine!", and.. well, I want to understand what is actually going on, since I retried what I was attempting, and confirmed it has some odd behavior, so here is the thing. 1. Create a prim. 2. Add in a simple script that used llAttachToAvatar in it, with, say, you click on it to attach it. 3. Take the resulting object "in" inventory, and rez it again (this means that you now have two copies, one in inventory, and your "copy" in world). 4. Click on it (or what ever you set up the script to do), and have it attach again. Expected result - you should now have "TWO" copies of the object in inventory. Actual result - You still have the one you first picked up this way, but the copy you rezzed is gone, as though it was attached using llAttachToAvatarTemp. Ok, so.. Here is the thing.. Is this a "per AV" issue, or a "per object" one? In other words, in SL marking the original as, "This has already been picked up onces, never allow a copy to be made, if someone rezzes it.", or, is it somehow tied to the AV that picked it up, so that you could say. 1. Rez the object. 2. Have someone slse attach it. 3. Now have two copies, one in your inventory, and one in there inventory. Or, as seems likely, based on the behavior I saw, will their "copy" be "temp attached", and never show up in their inventory? If it is the latter, then... doesn't this make testing something that used the function kind of.. problematic? Because unless you copy the script out, then drop it into a clean copy of the core object (the effect, from testing, seems to effect the object, not the script), when you put the thing out for someone else to pick up, its just going to go BOOM on them, i.e., not create an inventory item, which seems kind of pointless, given the whole purpose of the function is to make sure that the object becomes their's, once attached. Heck, maybe this is already fixed, since I haven't tried for a while, but.. If it still happens, then I want ot understand if its just per AV, or if it really does break the object, for everyone, once someone picks the thing up.
  12. Umm. Thanks for the suggestion, but.. this idea is intended to expand one something someone else has "already set up in SL", so, while it would definitely be nice to have a real game world... That said, part of the issue is imho that Linden kind of misses the boat some times when it xome to what SL actually **is**. Example - you can now queue sounds, so you can have a sort of smoothish transition between them. For some things this is not so smooth, since it places sounds "out of sync" unless they are short. Ironically, it hasn't occured to them to do the same thing for animations, where you are forced to either stop the current animation, or hope it isn't looped, and guess when it will halt, to transition into another one. To me... this is kind of an odd situation, because *both* of these things break the emersion, but, at least for me, the animation issue is the worse one. At some point... one has to ask, "What do they really want this thing to do?" Because, while more complicated to do some things in, say Unity, to use your example, it would never the less be possible to recreate a virtual environment that does the exact same things in that, which works better, in some ways. In the long run, that seems to be the direction things kind of have to go - smoother operation, better means to script the environment, less glitchy interactions with elements. Otherwise.. Heck EQ next is letting you built stuff in world, especially in Landmark, using voxels, which isn't as good as mesh, but it *is* far better than the original prim system SL has in it. The intent being to let people design things, and then sell them via a market. Oh, and, eventually you will have interactable water, which you can "pore" into where you want it, something Linden has said, "Because this is a special sort of something or other, we can't figure out how to remove/fill in, water, you will have ot fake it." The latest kickstarter for the age old Ultima series is currently running unity and people playing the pre-release are **creating content for it**, using the theme, and their own copies of unity. Then there are the experimental ones, which will probably also use voxel systems for some things, which can, in theory, simulate whole boody planets, and let you go from low orbit, all the way to the ground. And, yes, I realize that, to some extent, Linden is trying to keep things, probably, so they sort of run on systems people haven't upgraded in 10+ years. lol The point is, maybe there really needs to be a rethink of what virtual world "should" be able to do, at some point, and Second Life 2.0, or something, and some means to transition the existing content, and market, to something that isn't bogged down by what it wasn't designed to do? Because, while they continue to adopt some new things, here and there, its hard to tell if the choices are constrained, in all cases, by security, or privacy issues, so much as by underlying design flaws, and limitations of the engine. Or, do you think even a corporation, which was one of the original people this was aimed at, wouldn't benefit from better scripted content? And, then there are the like thousands, possibly tens of thousands of sims out there doing exactly what you say it wasn't "intended" for, from stuff like Dwarfins, to Gor, to CCS, DCS, BNWCS, DRPGS, ECS, Spellfire, even, ironically, two of them called UnityCore, and UnityCoreG, apparently, none of which (or few of which, unless the weapons of cross scripted) are compatible with each other, because.. Linden's only allowance for this has been "Linden damage", which has a set percentage, and no "secondary" attributes, like Mana, or Stamina, so can't be integrated into any of the systems. So, yeah, if I wanted to throw out "all existing content", just to have a workable backend, including everyone that I already role play with, sure... I would, rather, instead prefer to see SL improve to provide better integration of things that nearly everyone, in one sense or another, from the Hunt runners, to the combat system people, to you name it, are trying to do in the first place. Otherwise.. what would there be left in SL if all of those people finally decides that someone else had finally provided a better alternative? CCS already considered jumping ship over some things, but found that all the opensim's tend to be run by... shady people who often didn't care about content protection at all, despite offering better pricing, and additionaly features. And, there is still talk of CCS eventually moving "some" of its combat system, while retaining some of it in huds and stuff, for those unable, or unwilling to change clients, directly into a custom client, which talks to the CCS server, to remove the lag that otherwise results for 50 people all trying to kill each other in a sim. lol Why? Because while the RP is the key element to the sims that run the system, actually having a working combat system "enhances" the RP. So does having other things that work using scripted rules, when/if they work at all (you don't find a lot of people using real elevators, at all, any more, for example... lol). But, we did get a sort of spastic (I am sure you have seen the crazy driving on the roads where there are auto-rez vehicles, on mainland) path finding for NPCs...
  13. First off... I already concluded that I need something like what you mention. However, two things - #1: it doesn't need to be sold, just given. The only reason to make it sold, instead of given out on touch, when they are close enough, is if I wanted to have the original object no-copy, and them "buy", that object. But, this is unsafe as heck most of the time, if the asset server flakes out. So, yes, what you are suggesting is more or less what will be needed, with some.. modification. So, here is how its going to have to work, also as part of the RP: 1. The sim will be empty of groups initially (this is going to be a hard sell for the person that I need to get the CCS server rights from, since one requirement is that the sim already have its own apposing groups set up in it, for RP purposes. 2. Exploration will eventually result in someone finding the "server room". Attempting to fiddle with it will show them precisely why the place is so abandoned. The control crystal explodes, and its fragments "teleport" to random places in the sim. 3. All the lights go out, the water systems stop, waste recycling/reclaimation halts, and the manufacturing area in the city goes offline. 4. Everyone has to a) figure out what the heck just happened, b) find the fragments, and c) reestablish function of the systems. This means that each "fragment" gives them a copy to rez, which, now "in their group", gives that group control over one of the four systems. 5. This should result in factions arising, and groups for them, pretty much organically, as people try to wrest control of the cities systems from each other. Especially when they work out that, now that its broken, owning more than two of the things, connected to the same group, increases the odds of them all teleporting away again, and all control being lost, again. Note, the last one of your options - self delete, is a problem. Why? Because you can't rename, change description, or otherwise identify the object given out, so as to uniquely determine if the time limit on it has run out. All you can do is make it no-trade, and force the person it was given to to rez it some place, and time out "their" right to rez it, in the time frame (creating a new, randomly places one, some place in the sim, when that happens, so that someone else can grab it instead. I was going to say more, especially about just how "secure" things like media on prim really are... but, yeah, I'll just stop "ranting" as you put it. Wouldn't want to talk about both how things can be improved, or speculate on why they are the way they are, or if there *might* be a way to adjust them to work better (like.. some way to also set prim to match "same title" too, and set them to more than one, so you can "layer" your security to different areas, with different levels of access, without having to have multiple groups?) Sigh. right, I'll stop now.
  14. I'm not following all this, but skimming the original post suggests that this may be trying to use built-in object ownership as an inappropriate proxy for RP "ownership" of RP resources. I mean, there may be a happy coincidence where the semantics of those two realms overlap helpfully, but it's much more likely that SL object ownership is too restricted (for commercial, security, privacy, or other reasons) to serve the intended RP function. I mean, is it really necessary -- or even useful -- that ownership of RP resources coincide with avatar Inventory, as opposed to the "inventory" of some RP game server and associated HUDs? Well, the problem here is that the system already in place doesn't support "groups" via the hud that is used. It made no sense to the developer to do such a thing, since its unmanageable, while, if you want doors to a base to open for the group/faction, you just create an official group for them, and have the doors set up to recognize those people with the right group tag. Trying to do that with a hud would require... an idiot amount of work, not the least of which added an "external" server, to keep track of it all, and it would have to be either only for the sim I had set up (which makes it kind of useless if other people wanted to expand the idea some place else, to other sims using the same combat system), or it would have to be rolled into that combat system, which.. I am pretty sure the developer of the system would go, "Why the F would I need that?" So, yeah, it is necessary that something like this works. And, you are incorrect in one sense, taking it into inventory would be useless, this is just a theory I had on how to make the process less complicated for people, and have more control over it. If I know a specific attribute, like the key, or an ID, or.. anything at all, about who got the item, and thus which "group" it belonged to, I can use the existing system, which lets you limit control over an object "to that group", to handle this, without some complicated, and convoluted, external server, registry of people to some new group system, which ignores how every other one of more than 250+ sims that may be using the same combat system as mine would have running in it, etc. I could track the key of the person that "bought", or was "given" a rezzable object, and then have it so they have to be the one that rezzes it some place. That is, I think, my literal "last resort", but that has the annoying drawback that they can't "pass it" to another group member, and let them rez the thing, as part of the RP, and have it work, since it would then be in the hands of the wrong person, and, again, there is no way to check to see if they are in fact in the same group. Frankly, as a solution, it also kills another option - you couldn't hire someone else to "steal" the item, give it to you, then have you be the one that rezzed it, since, again, **you** wouldn't be the person authorized to do so, according to what the server prim knew about who took the thing. But, yeah, you are all correct, I am trying to come up with something that uses the "existing" system to do something, because the alternatives all create either a) unnecessary limitations, or b) actually compromise, ironically, the security, anonymity, and other factors. not to mention functionality of what I am trying to accomplish. Why does it make sense, at all, to have to go around reinventing the wheel for so many things, because the existing one is either intentionally square shaped, and/or only rolls one direction? Sigh... On a side, but related note: I keep thinking there has to be a happy medium, like, having to "have the key" to a group, and expanding the test to a list of keys, with something like "llIsInGroupList". It does the exact same bloody thing as rezzing multiple prims, for different groups does, but is also "limited" to only those groups you give it (and a limited number of possible groups), without having to waste extra prim/script resources to make it do what you intended. This wouldn't fix my issue, exactly, since you would still need to get the group key, from someone that is in the group, or something like that, but... for nearly everything else, including doors, it would be a godsend. In any case, allowing, or having someone, rezz a prim for the group, to access doors, etc., "already" violates what ever "privacy/security/commercial/other reasons" there might be for not allowing it. You could bloody region say, "So an so is in group ...!", as long as "someone" rezzed an object with the right script in it in the sim, and they came in contact with something, which asked that prim, "Is this person in your group?" So much for any of those concerns... How is giving one prim a limited list of groups to check against any worse exactly? I just don't see it.
  15. You can*t transfer ownership in world. That works only for temporary attached objects. Otherwise you need to buy the object to transfer ownership. I don't see the point for that in a scripted object. To check an avatar for multiple groups, place objects somewhere in the sim - one per group. Send out a message with the avatars uuid and the object with the matching group will answer. So every script can easily determine if that avatar touching (for example) wears the grouptag of group A,B or C. No, I can't do that. I have no way of knowing what groups will be in sim. This is intended for CCS, and if/when I can afford to do it, there are at least 20 groups I can think of which might end up involved, and probable dozens, if not more, including ones that do not even exist yet, which may end up in my sim, as part of their decision to RP there, any one of which may end up sticking around long enough to "acquire" one of these things, even if only very temporarily. To limit it to only those "officially" in the sim just isn't going to work, period.
  16. "The code you posted work exactly as advertized. Drop it into a prim that you own and click on it. The prim attaches to your right hand. Five seconds later, it detaches and appears in your inventory." Hmm. Must have been something wrong with the asset system last night, because this bloody well was not how it was working for me. It never showed up in inventory at all. Is there, possibly, some sort of glitch which causes "new copies" of said object to get borked, and stop working as intended? That is the only possible reason why it wouldn't work for me, since the "initial" attempt worked, but when I rezzed a copy out, and even renamed it, to make sure I could "see it" in inventory, the new copy failed to place the asset into my inventory, instead causing it to poof on me. I tried it in three different sims, just to make sure.... I just don't get why it would be doing that.
  17. Sorry. by "faction" I mean "group". I want to have it do "llSameGroup" on the object. In other words, if you touch a terminal some place, that terminal would "ask" which group currently owned the object that gave control over that terminal. In other words, it would be "capturable". The point being to find some way to make sure there is only one group at any time allowed access to those things, based on the rezzed object. This would be for an RP sim, so.. if, for example, two groups from where I RP would be 'Syndicate' and 'Brood'. If the Brood currently control the city water supply, because they have the fragment that happens to give them access to those systems, the Syndicate may plot an RP to sneak into the location where its kept, and steal it. This would result in the Syndicate taking control over the systems. Thanks to Linden's paranoia, there is no way to check which faction someone is in exactly, so no way to just simply have the "core" object keep track of who has ownership of the system. So, I got the idea instead of having it so you can phsycially "steal" the prim that give them that access, as in picking up a copy, and having the original delete itself. Then, when they rezzed it again, at a new, hopefully secure. location, all member of the new group would gain access to it. The reason this needs to be open ended is that, well.. there are new people coming in all the time, new groups forming, or leaving, and I don't know how many actual groups, not including "racial" ones, where someone might decide to, say, allow all "Humans" in the city to access it, instead of a specific group (i.e., they would rez it with the city human group, not their own specific "faction". I believe there is one for humans, lycan, and some others as well, besides the main groups, which have clear differences between them.) So, the point of this is to get around not being able to find out which the exact group they are in is, and second, to not have to bloody keep track of hundreds, or more, people, over time, and which group they claim to be in, just to get the same result. If I can rez a prim, which already has the same group, I can just have the main server prim ask if the person that touched some object in world if they are in the "same group" as the fragment that controls it. The script I posted was an attempt to see what happens when a) you attach an object on touch, and b) what happens to the key, when you rez it again. The answer seemed to be, "For some damn reason, its treating it as a temp attachment, even though that isn't what I specified.", and, "Unless I set it as no-copy, I probably won't get the same key, so I can't make sure that the object "is" the same one each time. Meaning, I can't keep them from keeping the copy in inventory for a week, then rezzing it, and stealing control that way." Think of this like.. capture the flag, only, you need to be able to actually have the flag drop/planted, and the sytems needs to be able to bloody tell which group "owns" the flag right now, based on their current group. Or, if you prefer, think of the problem like that of a door, in a building, where you rez a prim for each group you want to have access, but, in this case, someone can "steal" the keys and change the locks, i.e., somehow delete the prior owners access, and rez their own, but only under very specific conditions. Or, any other case where ownership of "access" can change hands, but, via scripting, not through some pre-planned thing, where the two sides agree to change the locks. As for the code I posted.. Its just not working right, at all. According to the Wiki, and the like llAttachToAvatar, "Creates the object in inventory.", so, when it detaches, a copy should be "in inventory", not just totally gone. When I tried it with the script I posted, it attached, it was visible on the AV, it never appeared in my AV's inventory at all, and when I manually detached it, or when I let the timer do it, it just poofed out of existence entitrely, as though I had used, instead llAttachToAvatarTemp. This contradicts the whole point of the difference between the functions.
  18. Hmm. IS this a bug, or just something its doing to me? The following script attaches, but doesn't seem to create and inventory object, and then, just to make things even more annoying, when it detaches, there is no "copy" left in my AV inventory of the resulting object. Its acting like its doing a temp attachment. Also.. Another case of "You can't test this.", from Linden, in that I can't set my object to not be mine, so it is no-copy, so that I can make sure it retains the key, as it needs to be able to, to "trade" permissions, using this trick. default{ state_entry() { llOwnerSay(llGetKey()); } touch_start(integer num) { llRequestPermissions(llDetectedKey(0), PERMISSION_ATTACH ); } run_time_permissions( integer vBitPermissions ) { if ( vBitPermissions & PERMISSION_ATTACH ) llAttachToAvatar(ATTACH_RHAND); else llOwnerSay( "Permission to attach denied" ); } attach (key id) { llOwnerSay("Rez this with your group tag set to the group you want to have access to the fragment, to gain access to its features."); llOwnerSay(llGetKey()); llSetTimerEvent(5); } timer() { llDetachFromAvatar(); } } Note, the timer in there is because I thought their might be some sort of odd delay in "creating" the asset in inventory, which was causing the problem.
  19. Hmm. Ok.. I can see maybe.. using "llAttachToAvatar", then "llDetachFromAvatar" back into inventory, to be latter rezzed where they want it, and, if they don't in 24 hours, rez a new one some place in the world, send in its key as the "valid" one, and when either one is rezzed, check that against the current "live" version. That should keep the same key on the object in question, since it shouldn't change one taken this way, and it would still be what ever the "current" valid key is. Its just matter of having the core "server" check to make sure that the current allowed copy is "in the world" still, every few hours, then, if tis gone more than 24, creating a new one to be found. Would that be the only way to make it work?
  20. This would be so much easier if you could detect the faction of someone touching, and then also "set" an object to be that faction. But, I had the idea for a system where certain "services" in a sim would be "owned" by which ever faction captured a crystal fragment that somehow "links" to those features. The idea being that, at some point, the crystal worked like a core server for all things on the place, but it overloaded and fractured, leaving each "section" of the cities infrastructure, security, etc. tied to individual fragments, and you could say, only have two fragments tied to a faction at one time, or otherwise they would randomly displace, loss their faction connection, and have to be found again. Or, maybe the odds of this happening each day goes up, the more of them you have. This is a working idea, and until I can actually pay for a server, its just theoretical.. Still, while looking at a post someone had about rezzing an object, and then changing ownership to someone else, i.e., not having to put it "into" their inventory first, which is, of course, not really possible, I had a great idea - have each of the fragments give a copy of themselves, then, when the new copy is rezzed, kill the original copy. That way, the person that rezzes it ends up having "their" faction as the owner of those systems tied to that fragment. Now, the problems I see with this, and need to be solved are: 1. How do you keep more than one person from stealing the fragment from where its being kept? 2. If you can't, how do you make sure only the first thief gets the new fragment? 3. If you simply disable the ability to get a copy, or disable/remove the original fragment, how do you make sure that #1 & #2 don't happen anyway? Now, obviously one could set the name, or the object "after" rezzed, or even the description, but.. it needs to happen "before" it is rezzed, if I wanted to, say, have a master server "set" the new ID, then only allow that ID to work if rezzed, or time out the rez. Such as, say having 24 hours to rez the new one, or the old one reappears some place random again. I don't know what the key will be for any "given" object, so can't "register" that as a valid copy either. Literally the best I can think of is saying you have to "bind" your faction to the object, i.e., rez it, within 24 hours, or it will randomly displace again, but.. I then, still, can't "prevent" someone from rezzing the copy they got, and causing the faction to change anyway, as a result. So, any ideas how to make this secure, since.. ironically, Linden's "security" with respect to factions, object ownership, etc., and just the way things work, period, all get in the bloody way of doing it? Because, I can't see any way to make either a) make it give only one **AND** make it only work within a time limit, so any copy someone has, if rezzed late, will fail to change faction ownership.
  21. This would be so much easier if you could detect the faction of someone touching, and then also "set" an object to be that faction. But, I had the idea for a system where certain "services" in a sim would be "owned" by which ever faction captured a crystal fragment that somehow "links" to those features. The idea being that, at some point, the crystal worked like a core server for all things on the place, but it overloaded and fractured, leaving each "section" of the cities infrastructure, security, etc. tied to individual fragments, and you could say, only have two fragments tied to a faction at one time, or otherwise they would randomly displace, loss their faction connection, and have to be found again. Or, maybe the odds of this happening each day goes up, the more of them you have. This is a working idea, and until I can actually pay for a server, its just theoretical.. Still, while looking at a post someone had about rezzing an object, and then changing ownership to someone else, i.e., not having to put it "into" their inventory first, which is, of course, not really possible, I had a great idea - have each of the fragments give a copy of themselves, then, when the new copy is rezzed, kill the original copy. That way, the person that rezzes it ends up having "their" faction as the owner of those systems tied to that fragment. Now, the problems I see with this, and need to be solved are: 1. How do you keep more than one person from stealing the fragment from where its being kept? 2. If you can't, how do you make sure only the first thief gets the new fragment? 3. If you simply disable the ability to get a copy, or disable/remove the original fragment, how do you make sure that #1 & #2 don't happen anyway? Now, obviously one could set the name, or the object "after" rezzed, or even the description, but.. it needs to happen "before" it is rezzed, if I wanted to, say, have a master server "set" the new ID, then only allow that ID to work if rezzed, or time out the rez. Such as, say having 24 hours to rez the new one, or the old one reappears some place random again. I don't know what the key will be for any "given" object, so can't "register" that as a valid copy either. Literally the best I can think of is saying you have to "bind" your faction to the object, i.e., rez it, within 24 hours, or it will randomly displace again, but.. I then, still, can't "prevent" someone from rezzing the copy they got, and causing the faction to change anyway, as a result. So, any ideas how to make this secure, since.. ironically, Linden's "security" with respect to factions, object ownership, etc., and just the way things work, period, all get in the bloody way of doing it? Because, I can't see any way to make either a) make it give only one **AND** make it only work within a time limit, so any copy someone has, if rezzed late, will fail to change faction ownership.
  22. Note, there is an alternative I considered, which is, since you, presumably, know where the buttons are, you could use a second "layer". If mesh, this means you "media" is on a face behind an otherwise invisible "case", or, if prim, then, you just have an invisible prim, over top of you media layer (one of the only damn times I am glad Linden can't figure out how to set transparent stuff to be "click through", or even, allow the option), as a touch surface, and thus, just get the uv coordinates of the touch, from that, and handle it like a texture. I really wish there was a cleaner way though to get the on-page and in-prim script to talk to each other. Have several ideas recently, both huds/in-world type things, which just. frustrate me, when it comes to "real time" handling of what I want the things to do. Good example, if you have played 'Remember Me', when ever you come up to a store, there is a "pop down" display that shows up, telling you what the place sells, or even if its open/closed, on the window itself. Now, imagine that "in world", in SL. You walk up to a shop and you get a display. Now.. not so much for a shop, but.. how about an RP environment. The sign, detects who you are, and flashes you a message, from your faction, or the like, which you can then, touch away, at which point it goes back to just talking about the great deal on orange juice the shop is having. lol My current annoyance is trying to rig a "small" version of a particle script, which is likely to take up most of the "available" space to load the page, then "push in" text, so that it functions like one of those animated light signs. But, again, just getting the thing "onto" the prim, without an server is half the problem, then you have to be able to send it stuff, and get stuff back. Would be simpler, for a display, to just... well, "display" text. Another good one - a "higher tech" safe/vendor, for RP, like you get in some games, where you buy/sell inventory from it, and it actually lists the items, and how many in stock, as you buy/sell to it. Try that with textures... Try it with HTML, and.. well... might be a way to do it, but, a) fast, b) real time, or c) anything like simply? Yeah, not bloody likely.
  23. Well, no. I fact I was thinking more in term, with the climbing thing, of having an attachment run animations, instead of using sit. Mind, that probably means messing with bouyancy stuff, instead of moving, but.. I am not sure what you can, and can't do with AVs in all cases. The principle idea would be that, instead of having to add scripts to the objects, you just have a single server, to "tell" the attachment where things are, which you an interact with, then actually do the proper "adjustments" to position, facing, animation, etc., **exactly** like you would see in a real game. Right now.. SL pretty much doesn't do this, with "anything", and its really goofy, and unbelievable, because of it. You can think of it like a swim hud. When in water, Linden just treats it like air, and lets you fall (but, ironically, clients do provide 'swim' AO settings, for when you actually "do" interact with the water...), you have to detect it yourself, then do a bunch of extra things, to make it so you float, or swim, etc, based on being "on/under" the water. Most games have "trigger points" to handle this, and, in fact, some, like the Stalker series, actually went one step farther with the concept, and had terrain points, whose distance would "trigger" changes in behavior, for the NPCs, so being close to a place with a findable artifact would, for example, send the NPC team into the field, to find an artifact. Being near a campsite resulted in them setting up camp for the night, etc. The point being to try to make things "fluid", instead of, for example, a wall climber, which has no damn clue where the top of the wall is, can't let you peak over, never mind climb over it, and where you can't, possibly, even "get" onto the resulting roof, because it doesn't know you are at it, and the only way it can a) dismount you, and b) make you land on the roof, is if you "jump off", and thus both trigger the end of the climbing animation, *and* maybe, if you time it all right, actually end up on the roof, instead of falling 10 stories, to the ground again. FSM forbid you wanted to do an "chimney climb", like in some game like Splinter Cell, allowed, or crouch and move between barriers, smoothly, or.. like, anything else that would make it look less like someone trying to do an FPS, using puppets on a string, and more like an actual environment, with believable actions. I thought about it a lot, and couldn't come up with a real way to manage it, until while working on this, and I realized.. if you an test "where" an AV is, relative to something like a wall, you "can" both a) have them creep along it, without using a mess of ray casts, or sensors, and b), you could have them trigger the actions need to believable go "into" that movement, as well as restrict what they are doing. You can't, at all, do that with, for example, the existing "climbing" methods, because well - 1) they rely on sit, which you can't set a "this is where I get off" on, or 2) they rely on collision tests, and a simple animation setup, which doesn't have a clue what the sim actually looks like, including, where the top of the building is, so, even if you can "climb" with one, you can't animate starting the climb, getting off to the ground, climbing over the wall/edge, to get on/off of it, and the roof, and so on. But, with a hud, which knows where ladders are, or even enough about the buildings, barriers you can hide behind, and so on... all you then need is a clean way to know where the hell you actually are, which "state" your AV is in, and thus, both how to animate them, and in what ways they movement needs to be contrained, to make it believable. All stuff that, imho, the damn server should be doing, if only for "water", and nothing else.
  24. First, let's change the code we have so far and make it into a function that returns TRUE or FALSE, depending on whether the avatar is within the box or not. Yeah, not sure I have the slightest idea what that does. lol Will try to test it out, when I have the chance. Kind of wish I had something, other than SL, to actually drop some of this stuff into and test "see" what is going on though. Especially with some of my own code, where the problem would have been really obvious, if I could have seen what it was actually doing. I have, definitely, not had enough math classes for this sort of stuff.
  25. Hmm. There may be circumstances, like say, flight, where the "door" isn't going to be walked up to, or, for that matter, necessarily, even vertical. Its definitely an interesting problem, which if I can find a good, working, solution for, has a lot of potential for future projects. It doesn't look like, for the original problem, its likely I really need to do anything more complicated at this point than the simple, temporary solution, I dropped in, while seeing if I could find something more versitile. Note, the interesing one with the planes is.. in principle, you could, if you can figure out where all the needed planes would be, and which normal to test against (i.e., which sign is the right one), actually form a basic outline of some fairly complex shapes to test against.
×
×
  • Create New...