Helium Loon
-
Posts
309 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Helium Loon
-
-
While I don't understand the language you write in, I do understand LSL. The script looks mostly correct. I think the problem is that the "&" and "|" operators are equal in precedence, and so your condition in the run_time_permissions() event is evaluated left-to-right.
Try changing:
if (perm & PERMISSION_TRIGGER_ANIMATION | PERMISSION_ATTACH) {
to
if (perm & (PERMISSION_TRIGGER_ANIMATION | PERMISSION_ATTACH)) {
though I'm not certain if that will work right, as run_time_permissions() events may be separate. Better to change your event handler to something like:
run_time_permissions(integer perm) { if (perm & PERMISSION_ATTACH) { llAttachToAvatar(ATTACH_RHAND); } if(perm & PERMISSION_TRIGGER_ANIMATION) { llStartAnimation("pes1"); }}(edit: Had the PERMISSION flags reversed)
-
It's a common misconception that SL is badly written, or poorly optimized, or sloppily coded in some way. People get bad performance, but see other games run very snappily, so they assume SL isn't done well.
It's important to remember that most games almost all the content is local, optimized, and fixed. The levels in Bioshock don't physically change from one play-through to the other. The geometry, the physics, the lighting.....it's all pre-computed, highly optimized, and resides right there on the hard-drive. Many things are actually not even there.....back faces you should never see? They're removed from the models entirely (go ahead, cheat-code and move to places you shouldn't be able to reach......you'll find all kinds of 'missing' geometry through the maps.)
SL is a dynamic environment. The number of agents that can be present, the objects, their positions, sizes, linkage, lighting, shading, texturing, even the landscape itself......and more......can all change at ANY moment. And most of that data does NOT reside locally.....it has to be streamed over the network. This means that the program CANNOT optimize the content. It cannot know that certain faces 'won't' be visible, or that certain areas are 'unreachable'. Textures can change at any moment, and new agents can suddenly appear, while others vanish.......
Because of all of this, there is a HUGE amount of network overhead, and also processing of all those messages. Updating an object may be fairly quick, but when there are several thousand being updated, along with script updates, agent updates, physics calculations......all being done EVERY frame, no pre-computed stuff here......it can bring even power computers and GPUs to their knees.
SL is actually VERY well written (with a few notable exception areas, but from a capability standpoint) and despite all the problems such a dynamic and changing environment presents, it handles it remarkably well.
But don't compare it's performance to other games. That's an apples-to-oranges comparison. Compare it to other dynamic virtual words.....then you'll see more comparable numbers.
-
26" ASUS at 1920x1200. My second box is on a 24" at 1920x1080.
-
Rollig, I read it differently.
I think (note, this is not tested, of course) that what it is saying is that since these are server side settings, the calls to change them persist.
Much like setting the texture on a prim via llSetTexture(), once it's set, the script could simply be deleted.....the texture stays. When you alter the animation override via these scripts, it 'sticks' for the session.
Now, unlike llSetTexture() and such, it doesn't persist between sessions. So the next time you login, your avatar is back to the normal default animations on the server.
So an object could request permissions, change the AO settings, then simply delete itself. The settings would hold until something else changed them, or the avatar logged out.
-
Use llGetObjectDetails() with the agent's key you want to examine. The following elements can be retrieved:
You CAN'T get a breakdown by attachment, though. Just the totals.
-
Glad to see you here, Dakota!
But the instructions on how to 'fix' the issue.....any 'solution' which requires you to DL and install an OLD third-party viewer to successfully execute shouts "PROBLEM" to me. This says there is a bug in the ALL the LL viewers that still isn't fixed, but ONE old tpv did. WTF?
Please fix DD first. Then eliminate the Magic Boxes. Not the other way around!
-
If I'm understanding the OP correctly, this is a worn object, that when the avatar wearing it logs in, it will attempt to force-sit the avatar on the seat.
The most likely problem is the lack of a delay between the attach() event and the attempt to re-force-sit.
The seat object may not be fully loaded yet. When you log in, objects get loaded around you. Distance, visibility, and complexity all play a role in how long it takes them to load. Same with the objects you are wearing! Since you say it works sometimes, and sometimes not, I'm betting this is the likely issue.
Set a timer from the attach() event of the worn object (to delay 10-15 seconds before executing the force-sit), or re-work your scripts to have the seat and worn object do some chat-based syncing up (worn object says something on attach, and repeats it every x seconds, for up to 10 times, and seat object hears it and responds. On response, worn object can do the force-sit.)
ETA: (Without seeing your code, we won't be able to offer more than generalized speculation.....)
-
1
-
-
It wouldn't require ray-tracing. Nor would it create a huge hit (unless there were a LOT of reflective objects. For each object in the scene graph, if it is reflective, do a sub-render of a environment map. Such a render does require some extra computation, especially when resolution of the environment map is large. But a simple 256x256 sub-render is pretty quick, even with a 360 view angle (fisheye). Then apply it via any number of 'reflection' shaders that have been worked out.
Now, yes, this is going to make a hit on the frame rates. There are ways to reduce it. Base the environment map resolution (i.e., the sub-render size) on the distance to the object and it's bounding box size. Objects that are only rendering to a few pixels on screen would be skipped entirely, while large and/or close objects would get larger resolution sub-renders.
Now, yes, you could easily see frame-rates being reduce by 50%-95% depending on the scene complexity, how many reflective objects there are in view, and so forth. If it normally takes your GPU 20ms to render the frame (i.e., 50fps), a single moderately sized reflective surface could drop that 20%. 5 or 6 such objects in view could easily drop your render rates into low single digits.
There are further ways to optimize it, only re-rendering the environment map when objects in the view frustrum move, every X frames, etc. By doing these kinds of things, though the coding is more involved, it can significantly increase the effective render speed. If you only render those sub-renders every 10 frames, while the reflections will 'lag' or 'stutter' a bit as far as seeing movement in them, it decreases the load consideably.
It IS doable, it's just a LOT of work for only a small benefit. Though it would make the render MUCH more realistic.
Next thing you know, we'll be asking for refractions and caustics too!
-
LEAP + OculusVR could turn SL into a real virtual world. Here's hoping!
-
Are the scripts in the same object? As I recall, objects cannot hear themselves (to prevent recursion problems).
-
1
-
-
The behavior of the llList2X() functions are not guaranteed to work correctly if the type of the list entry does not match the result type X. Try changing parse() to:
integer parseint(list in){ return llList2Integer(in, 0);}And call this one for the parsing of the PRIM_TYPE, and change the if test to be (primType == 7).
I don't think it is a problem with your call to llSetLinkPrimitiveParams() but with the comparison in the if block. Quick test, put an llOwnerSay inside the if(primType == "7")... block.
-
Without seeing the parse() function, it's going to be hard to troubleshoot. The issue lookes to be the if statement:
if(parsedType == "7") ...
I'd check to see what parse(primType) is returning, and going from there.
If parsedType has been coerced into a string type, it should work. If parsedType is an integer type, it's always going to fail.
So if parsedType is an integer, just change the if statement above to be:
if((string)parsedType == "7") ...
but if parsedType is a string, I'd look to make sure parse() isn't adding whitespace or such somewhere in the string.
-
This is a common mistake about IP & copyright.
A logo is NOT copyrightable. It can be TRADEMARKED. This is a whole different area of law. And unless the appearance is VERY similar, AND with the intent to be mistaken for the logo of another company (in order to draw customers/interest based on confusion, not merit) THEN there can be a legal issue.
Your logo looks similar to a few I've seen, but not in SL. For example, it resembles the 'fantastic ferret' emblem of a superhero from the Disney series "Kim Possible". I think I've seen a similar emblem as a skate supply brand of some sort. But they are ALL different enough (both in venue and appearance) that I don't think you are going to run into any trademark issues. And unless the logos are REGISTERED TRADEMARKS, there isn't much legally to worry about anyway.
-
1
-
-
Unfortunately, custom bones aren't really an option now, nor for the forseeable future.
The only way I could see to do it would be to model the lower portion of the sleeve as a set of flexible prims, and attaching those so they seem to flow from the mesh arms.
-
Sorry, Chosen, but in this case I'll have to side with the developer of the converter.
He did give answers. You don't like or agree with those answers. That's fine, but don't say he didn't give them.
I have a lot of scuplt maps I've created over the years. I'm lucky if I can find the hard-drive they are on (if it even still functions!) Having the ability to deconstruct them to OBJ format isn't a bad thing. And sure, I could install Blender (if I didn't already have it) and take up 20-30 Mb of space and plenty of time downloading and installing. Or I could use a command line tool. And what about if I have a whole directory of sculptmaps I want to convert? I haven't discected the applescript to see if it handles wildcards, but a quick shell script could do that and call the script for each. Doing that through most plugin GUIs in a 3D modeller isn't possible.
And it should be mentioned that just because something CAN be used in an illicit manner does not preclude its usefulness outside illicit activities. VCRs and now DVRs both have illicit uses. But they also have perfectly acceptable uses. And while there are other ways of accomplishing the same activities without using them, that doesn't always mean it is the most efficient, or the most convenient.
And even if there were no particular use for it, it can serve as a basic algorithm for those wanting to understand how to write their own utilities for dealing with sculpt maps. *shrug*
-
1
-
-
There are a few pieces of software out there designed to take an image and 'wrap' it onto a 3D object appropriately. Most are a bit too pricey for hobby or one-time use, though.
One of the apps from the Kanae Project, Somato, projects flat textures onto sculpt or OBJ file, and generates the textures. If you have the right pictures of your face (and a copy of the SL Avatar's head object) you can project your face image onto it and build it yourself. It may require some editing, due to hidden surfaces and such, but it can be done. And Somato isn't terribly pricey. http://kanae.net/secondlife/somato.html
-
Sorry to say, you can't. The way SL handles tinting is by applying the prim color and summing it with the texture color. Whether it has any transparency or not.
-
I've been considering pre-ordering the Dev Kit and SDK. I agree, this would be amazing with SL (as well as quite a few MMOs and FPS games.)
I think the Oculus developers need to add a mic & headphones into the design (or at least a convenient way to plug earbuds and a mic) so voice can be done, as the keyboard will NOT be viewable. And having a 3D controller (like the spaceball/spacemouse/spacepilot stuff) is almost mandatory. Having support for those in the viewer as well would be a big benefit as well.
-
You may be able to find someone to do some of that, but I'm sorry to say that some of it cannot be done with LSL scripting.
LSL cannot write notecards. So generating custom 'reciepts' with amount paid and date/time in them isn't possible.
While tracking payment time, amount, and user is easy......LSL is limited to 64k for data and program space. Without an external database, keeping that data in the prim will quickly get too big. As long as the lists can be cleared after the email is sent, not a problem as long as the 'regular' periods are short enough.
The first two requirements are easy. It's 3 and 4 that have problems. The problems with 3 are not insurmountable, but 4 is just not possible with LSL.
-
I think the question is can you have one animated texture play through, then a different one play through, and so on.
Yes, it's possible. But it means you need to use a timer script. llSetTextureAnim() has both length and rate, so your script will already know how 'long' the animation is. Start it playing without looping, and set a timer for the total length. In the timer, set it to the next animation (and reset the timer length to the new animations 'length'.)
If you have more than two, you can use a list of animations and parameters for them. Then just have a counter to keep track of which one is currently playing.
-
You can't change the mesh itself via scripting. Changing the textures is relatively easy, simply using llSetTexture() or llSetLinkTexture() or llSetLinkPrimitiveParamsFast(). Each 'material' in the mesh is a separate texture 'face' on the resulting prim.
Changing makeup and such (i.e., the textures) would just require a library of texture UUIDs the script could switch between. If it needed to change shape, one could create 'copies' of the head (each consisiting of ONE material) and linking them so each has a different material. Then by setting all but the 'active' one to 100% transparent, you can 'change' the appearance of the mesh.
To do any of this from a HUD would require the HUD to communicate via llSay() or llRegionSayTo() with the mesh object script.
-
Considering the breadth of the experience you are asking for, and for full-time dedication, you might want to indicate what kind of salary range you are willing to entertain. What you are describing is not just a scripter, but also an IT professional and developer. If you really want full-time dedication and performance, you can expect to pay professional wages.
Are you prepared to pay $30k-$60k USD (or equivalent) per year, DOE? If not, you might want to also include expected time involvement on a weekly or monthly basis to earn what you are planning to offer. Most professional developers contract at $45-$90 USD per hour, higher for very short term or such.
If you are planning on paying percentage on sales to offset the dev cost, how much? For how long? You're looking for a lot, you might want to give a few more details......
-
As has been noted already, the xCite people have done this. Not that a little healthy competition would be a bad thing!
To have the remote USB device controlled from within an LSL script in world:
(1) LSL-Script opens connection to a Webserver somewhere (via llHTTPRequest() call) passing data to it in the body or header.
(2) Webserver acts on the data passed into it from the LSL script, changing values in a server-side DB.
(3) USB device driver uses IP to make queries over HTTP to a webpage front-end on the same webserver, retrieving updates in the server-side DB for THAT particular registered device.
(4) USB driver alters function of connected USB "peripheral".Obviously, this is something where having authentication is probably VERY important.....so there will be some additional steps in some of those. But that's the basics of it. Alternatively, you can have an in-world script set up as an HTTP server, which is then accessed much like from (3) above, but that limits some flexibility, and also can put various other problems into place.
-
A HTTP server is just that. A server. ANY client can connect to it. What the server DOES in response to those requests is up to the person implementing the server.
llRequestURL() just requests a server URL for the automatic sim HTTP server to respond to, and assigns a specific UUID key to identify requests as being for/from that URL and script. What that script does with any requests to that URL (i.e., authentication, encryption/decryption, etc.) is up to the scripter.
Facebook
Instagram
Twitter
YouTube
Flickr
Adobe Creative Cloud Is Awesome!
in Building and Texturing Forum
Posted
I still use Photoshop 7.0 from back in the late 90s. It still works just fine. What abou those of us who tend to keep and use software without paying for unneeded (for us) upgrades every few years?
No, I don't need another monthly fee to add up for years. And what about buying an older version for cheaper? Not possible with the new 'cloud-based' apps. When I bought PS7.0, it was already a couple of years old.....and I got it for $99.....and I'm still using it.
Yes, I've worked with newer versions. And I don't need MOST of the features. Some are useful, but there are other standalone programs that do those features, and usually better (like 3d painting.)
And I own it. As long as windows can still install it, and run 32-bit apps like it, I will continue to use it.
A single cloud subscription, for 4 months, would cost more than I paid for that. And I couldn't use it anymore if I stopped paying. That's not owning software. That's renting it. No thanks.