Nexii Malthus

I don't think there is a common practice for targetting logging in specifically, just the generic arrival of teleporting in / logging in. By common practice I meant how one interacts with string timestamps by turning into integer seconds which are useful format for manipulation but then forgot how llGetUnixTime existed where only LSL is concerned. (I'd often dealt with string timestamps from different systems previously)

Hmm not sure what you would use to actually check whether they logged in rather than just teleported somewhere else. I would use those events but also setup a very slow polling timer (5 minutes? 60 * 5) that simply saves llGetUnixTime into a global variable. Then when on_rez or attach are executed to check the global variable against the current llGetUnixTime via (current - global) > (60 * 5)

Would be good to have a status update on this as I'm working on respawn systems atm

Hmm, it's still a very, very valuable function to have regardless even with the caveat it doesn't work across regions. I still think that this should be implemented with the caveat. Is there no way to make it work across regions? Guess it's a pain, assume it has to do with teleporting to regions requiring a given predefined vector location as a parameter and having to add in a mechanism for teleports which can target a UUID key instead might be annoying — but honestly also sounds kinda neat in a general sense? Targetting UUID keys would be more precise and flexible. Would it be possible to add UUID keys as optional teleport parameters for locations to the protocol? The vector location could still be required as a fallback, but if the UUID key exists then to rez the agent at that object. Anyways, llSetRespawnObject with caveat that it doesn't work on region crossings would be fine.

There are many tricks to expand the keystore to fit your needs, you could for example have a naming convention that allows you to figure out/compute the keys on the fly easily. Or you could even store lookup lists in a value to create relationships between other keys, or you could just store full JSON in a value. You could have a common global key that has a value that stores other keys to lookup. Such as a list of players that are part of a team and then lookup each players information.

It would be great to be able to set respawns to follow an objects position and facing rotation llSetRespawnObject(key object_id) When a respawn occurs, the agent will be teleported directly above that prim as follows: position = prim position + (prim scale / prim rotation).z/2 + agent size.z/2 See: https://gist.github.com/Martin-Pitt/fd40476d1ef086d6051b273e6ac972d1 facing = prim rotation Or alternatively just simply at the prim position directly position = prim position, although would need to make sure the prim's physics doesn't get in the way. (Which is why I wanted to take into account the agent size) The prim could be part of a linkset btw, such as a deployment/respawn pad within a large structure or a moving vehicle that uses KFM. So this for example would allow usecases such as targetting spawn pads in a cargo elevator in a big structure, deployable spawn pads that attach to a surface, a passenger seat prim on a train's carriage that is slowly moving around the sim via llSetKeyframedMotion or a gunship hovering over the battlefield that carries droppods to act as respawn locations without having to frequently poll the location constantly and getting out of date quickly due to movements. There could be an issue if the object doesn't exist on that sim anymore, so perhaps llSetRespawnLocation could act as a fallback? EDIT: I realise my "above that prim" math is off, since prim scale would be just one of the corners, here is a script that calculates the top of the rotated bounding box: https://gist.github.com/Martin-Pitt/fd40476d1ef086d6051b273e6ac972d1 (effectively trying to put agent ontop of an axis -aligned bounding box / AABB) Additionally, setting respawn location to an object can be much more convenient and simple at times. As this means you can set the respawn location once and then just simply move the object, instead of having to suddenly go through about say ~30 agents and updating each one with the new respawn locations, it is easier to update the location of one, two or a few objects.

They have been working on gLTF uploads for meshes which will introduce some new features with it, but that's basically the successor to it. Information is a bit scarce since it's very much alpha and details aren't confirmed yet. FYI: gLTF has already been implemented for PBR materials but it's actually a format that was intended for 3D scenes and models. People might be eager for it but considering how messy PBR materials been I hope it bakes in the oven a bit more to be well done considering the impact it can have. It could streamline mesh uploads, offer some scripting support for moving nodes in a scene and if I recall correctly allow custom skeletons to be defined instead of having to use the SL bento skeleton for animesh.

@Crubo Carver recently bought the new compact model and it works great. Did have to finetune the settings in the joystick menu for flycam and also disable the default button functionality so it can toggle flycam mode properly, but that was it pretty much.

@Kayla Woodrunner Highly recommend using a SpaceMouse Compact: https://3dconnexion.com/uk/product/spacemouse-compact/ It is what I used to record the camera on this video for example: The movement in the video is rather erratic since it was spontaneous/unplanned moment of recording a live event, so was trying to follow the action, but you should see how I have completely continuous and smooth movement throughout the entire video recording. It requires some finetuning to get it just right for what you need but it's a great piece of kit for anyone exploring or recording SL.

Audio engines usually have a max amount of channels for playing sounds specified by the app, in games I'd sometimes see up to 128 channels specified. In the secondlife viewer, which uses FMOD and falls back to OpenAL, has a constant specified at 30 channels max -- https://github.com/secondlife/viewer/blob/83e80d79672210355d0291e30bd89bd03c672ca6/indra/llaudio/llaudioengine.h#L51 -- some viewer specific sounds may take up some channels at any time, for example clicky interface sounds, etc. This seems to match with testing against 60 looping sound cubes in a grid and noticeably hearing some get cutoff when reaching the max channel limit across half the cube grid. The viewer could probably be updated to handle way more audio channels at once imho, the limit is very low and conservative based on the hardware that came out at the time, but this should give you a ballpark range on layering subtle ambient sounds.

I use grabbing in scripted objects quite a few times. For example doors that a user can grab, or slide, open or slam them closed in a loud bang. It's a lot of fun. The scripted objects are non-physical and the prim movement is animated procedurally which makes the movement stable and easy to use. Grab in scripted objects is quite useful albeit can be quite confusing for scripters to implement, however the advantage is that the grab can exceed the surface of the object compared to touch. If you have ever used a slider in a LSL user interface you know how frustrating it is when you try to slam a slider to the end but you leave the edge of the slider making it non-responsive. Scripters will try to implement a graceful safe area around a slider to counter this problem so it knows if a slider needs to hit the edge. However you can't quite use this workaround for in-world objects like doors. So grab is the perfect tool here and works better than the workaround since it works to the edges of the viewer. Some might wonder why not just have a click open the door? Because it's boring and actually is quite unattractive, I'll still have that option for convenience, but.. doors look a lot more natural when they can be left at angles you'd naturally open and leave them at, which is different across people as well, making a house actually look lived in. It can be useful for roleplay or socialising. Being able to slam a door closed or leave it at an angle is silly but exactly what SL allows you to do and adds warmth to our little world. I feel like I went on a bit on a rant there. Anyway! Grabbing for physical objects? Pretty rare, I've used it once for a virtual target marker when testing inverse kinematics: But it's application to physical objects is very rare to see in SL. Most games are very contained to prevent cheating and the grabbing doesn't give the right UX for fun mechanics anyway. However for scripted non-physical objects, the usecases grow much wider and it shouldn't be too rare to see it being used. I've already explained above it being used for in-world objects like doors. I've used it in the past for being able to move around HUDs and some HUDs may still rely on grab, there might be example code in the LSL Wiki on how to do this. But I've personally switched to relying on resizing a large transparent surface instead, like e.g. in openLayout.

Any preferences and settings are typically reflected in the Debug Settings where you can set them manually, the cam feathering one you mention is called FlycamFeathering if you need to tweak it in the SL viewer.

The only way would be to tweak the encoding settings, I once coded in some sliders in the texture uploader of the viewer that would re-encode and measure the filesize -- inspired by photoshop save to web. There's a bit of wiggle room to optimise better than the linden defaults if exposed to the content creator. Something that does matter a lot is that the source format you upload with should ideally be at the highest quality / lossless as possible so that the best/most ideal jpeg2000 texture can be generated in the first place. Otherwise if you, say, upload a jpeg as a texture, you would get jpeg artifacts transcoded into it.

With llSetKeyFramedMotion you can still take advantage of client-side motion, as with normal physics objects the client uses interpolation. The sim will try to avoid sending updates unless velocity has changed. A phantom KFM with little to no velocity changes would be very optimal.

You made the assumption that re-arranging the attachments would be a pain. However you could automate re-attaching the attacks to stagger an attack to the next slot ready for use. See RLVa for methods on automating attaching and detaching inventory items.

Wow, didn't know the avatar could be moved so far away. Could make some really great aircraft with that! https://gyazo.com/365ec98c7c35a3b0cfb0e95ad93caf07 ^ and yes, that's a off-sim terrain sculpt I made for example in there. It's a few megaprims sized 1024x1024x256 with a sculpt applied. I call them voidscapes, as in putting a landscape in the void. I'd made some pretty awesome voidscapes in the past, such as one which was a giant underground cavern! Was working on a whole city even, but alas lost the work in progress of that. Might be fun to go back to making voidscapes with this technique and coupling it with the fast heightmap collision algorithms I had, hm.

This is great, thanks for sharing @Aeragino Shelman! Will make it easier to hire creators

I love this thread and everyone here.

That's awesome Tomos! Great to see. Maybe hide the prims first for a moment (llSetLinkAlpha) so you can flicker them visible? Otherwise you see the prims moving due to client-side interpolation

Yeah, I know about the phantom child hack being broken, but the volume detect trick still works for creating the vehicles I mention.

Armor damage with vehicles in linden damage sims involves the use of two vehicles technically. - One is a seat vehicle that provides invulnerability to the user and follows the second. (Seated avatar and seat vehicle both are phantom through volume detection -- this was a bug at first to be fixed but linden damage users collaborated to convince LL to keep it as an unintentional feature so that we could create vehicular combat that works in symbiosis with linden damage, by establishing policies and a good will) - The second is the real vehicle and actually absorbs the physical projectiles and emulates damage, not to mention is the physical shell to provide movement through the sim. Usually you use a very basic damage emulation to keep in line with policies in most combat sims, which tends to be 100 hit points where each projectile deducts one point; Until hitting 0 whereby you must eject any seated avatar(s) and kill that avatar intentionally yourself with linden damage to complete death. There are no tutorials unfortunately, it is much complicated than developing attachment weaponry, you will have to learn best practices in scripting and content creation first. You could maybe ask Roudy Raccoon, last I know he was handing out help to people trying to understand armor damage systems, but it will still take a lot of your own initiative. (Source: member of Merczateers who were the first to push the use of combat vehicles in the linden damage scene)

The best way I found for achieving click-and-drag in HUDs was to define a 'draggable' area using a prim (e.g. like the top bar of a window) and then when the user starts dragging to resize that prim to fill the screen, so I can figure out where the user is dragging constantly until they let go. This is demonstrated here: When the screen goes darker is where you can see the prim filling the screen. As mentioned before, you can use LlDetectedTouchST I'll give you an example.

joniveehernandez wrote: Because those data must be display on a board. but I was thinking the only way we can display those data with style "Typography" thing is to display them as media viewing the php web page itself. joniveehernandez wrote: Sorry Ron I supposed to be specific on that part, So it's only possible to do it with llSetPrimMediaParams what I see on the land boards from other people. You can actually do some typography using some nifty scripting without using any media params (especially as media is very expensive on the client and will affect your FPS). The idea being to manually create a font renderer, by mixing some maths using textures with specially designed meshes, so that letters can be shifted around to form words. Which means that kerning can be obeyed. As each letter is an individual face, they can be coloured as well, as they are textures their textures can be switched to create different fonts, with variants of weights, italics and bold. If you want, I can give you a copy of this library, it's an opensource project of mine.

The touchee is likely in the same sim to be able to click on the prim. llInstantMessage has a forced delay of 2 seconds ( http://wiki.secondlife.com/wiki/LlInstantMessage ) llRegionSayTo performs similar function (for messages sent to a user in the same sim) but has no delay. ( http://wiki.secondlife.com/wiki/LlRegionSayTo ) Replace the function calls with llRegionSayTo(Who, PUBLIC_CHANNEL, "Text"); "Text" being your original message.

(Übersetzung von deutsch zu english für andere englische scripter dein problem zu verstehen) Lemme translate: I am not sure if I am dumb or wether SL especially hates me. Every time I put a script into a boat / submarine, it just starts flying upwards, without me being able to change anything about it. It isn't anything like a physical collision, but just does so. Could anyone tell me what it could be, i.e., what I do wrong? -- Ist da schon ein vehicle script in den objekt oder ist es leer? (Is there a vehicle script in the object already or is it empty?) Was feur ein script willst du in den objekt setzen? (What kind of script are you trying to put into the object?) Habe deutsch in vielen jahren night gesprochen, so entschulding von jeder grammatik oder andere fehler.