Jump to content

Extrude Ragu

  • Content Count

  • Joined

  • Last visited

Community Reputation

39 Excellent

About Extrude Ragu

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I would recommend against a while(TRUE) loop, as an infinite loop like this means that the script will use 100% of the Server's CPU resource given to it, making it laggy. It also means that any other event handlers in the script (ie, touch_start, collison etc) will not run as events are queued whilst code is running and a while(TRUE) loop never stops running. Instead you can get the same performance, whilst still letting the server process events by running the same code inside a fast running timer. EG default { state_entry() { llSetTimerEvent(1.0 / llGetRegionFPS()); } timer() { llSetTimerEvent(1.0 / llGetRegionFPS()); // Continually adjust to current simulator framerate. // Do the stuff inside the while(TRUE) loop here instead } }
  2. This turns out to be deeply complicated. From what I've read, agents that sit on an object are not attached to the child prim they sit on, but rather the object as a whole. That means that the agent is actually being treated as a separate link and is rotating around the root like a child prim would. In order for the agent to appear to remain on the object, the agent would not only need to be rotated like the child prim, but would also need to be moved so that it's position offset relative to the child prim is rotated around the child prims axis (Oh mama..) I'd guess you would need to hook the changed event to detect when agent(s) sit on the object, and figure out which prim they're supposed to be sat on. This'll be whatever child prim is closest, which could be figured out by using llVecDist against agent local position/all child prims local position (PRIM_POS_LOCAL) to figure out which is nearest. You'd then save the inferred child prim, the rotation of the child prim at the time the agent sat on it, the agent offset relative to that prim, the agents intial rotation, and the link number of the agent (Phew..) Then, each simulator frame (timer event) you'd take the child prim's rotation, subtract the child prims initial rotation to get the change in rotation of the child prim. You'd then rotate the agents initial offset around that axis to get the new local position the agent should be in, and you would also rotate the agent based on the agents initial rotation and the change the same way the child prims are rotated. I am going to leave that as an exercise to the reader because I have other stuff to do, but I have in the past written a script function to rotate a position vector around an axis which is probably useful for this scenario:- vector rotate_around_axis(vector axis, vector position, rotation r) { // Calculate position's offset from axis. vector offset = position - axis; // Rotate the offset vector rotOffset = offset * r; return axis + rotOffset; } Hope it helps
  3. Judging by the wiki they deprecated sending to the creator.
  4. I am bored stuck at home so I had a go at implementing this. Preview https://i.gyazo.com/9d0168650a2a83607996148573c18561.mp4 Script https://pastebin.com/p00LMaat Note that my script assumes that all cars are any non-root link prims, you might have to manually populate the list if that's not the case.
  5. Regarding stuttering: Just because you set a timer event for every 0.05 seconds doesn't mean that's when the timer will run. Better to calculate the elapsed time each timer event by using llGetTime() and llResetTime() and calculate the true rotation needed based on that. It will look smoother and correct for timer inconsistency. You could set timer event to 1/llGetRegionFps() to ensure that each simulation frame of the simulator the rotation is calculated making it as smooth as can be. Regarding seats in car: I would discourage having a separate script in each car as it introduces latency between the movements and requires parsing strings which is not optimal. I recommend instead using llSetLinkPrimitiveParamsFast from the root prim in conjunction with PRIM_ROTATION, to control each car link during every timer event to correct for the rotation of the main wheel.
  6. So you're me, and you make a model that's big, really big. 238meters, by 69 meters by 155 meters big. The maximum size a mesh can be in SL is 64m in any direction. How would you go about breaking up the model into chunks that fit into the bounding box, is there a non-destructive way to do that?
  7. I am curious about the internal nature of how llSleep is handled on LL Servers. Coming from a background in software engineering, usually to 'Sleep' in programming implies blocking the thread, something that is quite undesirable because it causes the system to no longer be able to use that thread to perform other tasks, which is why we usually prefer to turn to a more asynchronous model of programming, preferring events (eg, timers) so as to keep the thread open for other tasks to use. So that got me wondering, is llSleep actually blocking a thread in the server side code whenever it is being called? It would seem that, if this were true, it would make servers vulnerable to being completely thread-blocked. It seems unlikely to me that LL would want people to actually be able to sleep in threads. So I wonder perhaps does llSleep when compiled, actually generate a state machine similar to async/await model in C#?
  8. I don't think it's necessarily just about sexualization although I am sure it is a part of it. Making good looking long skirts in Secondlife is basically impossible due to the fundamentals of how clothes rigging works in Secondlife. Even once you start to approach the knees you are basically signing your creation up for a bunch of clipping or some really weird deformations during movement. There is a low incentive for creators to take the time to make long skirts when they know that 1. They're not going to deform as realistically as short skirts and 2. They won't sell as much. Other games usually get around this issue by either giving their female protagonists pants, or implementing some kind of clothing physics. Which LL could do, but are probably not keen to do due to new technology requirements/software development/testing etc that goes into getting something like that working.
  9. When I started playing SL in like 2008 I set up a headquarters out of prims on I think yumix's land, we had those prim police cars that could fly if you held page up/down at the same time. Went around making a racket and having a blast with a friend for a while like this. Our headquarters was like 12 stories high too, it had one of those scripted elevators that were the fascination of SL at the time. Great times
  10. I've actually been around on SL since about 2008 but I've never really introduced myself. Some things about me:- I love to create stuff. I run the anime themed roleplay school, Kokoro Academy, which I've been building since 2014! In RL I work as a software engineer, and I can reach >100 Words per minute 🔥 I'm a dude, and I live in London! Best, ~Captain Ai, At your service ( `∀´)ゝ”
  11. As someone who is making an anime-themed sim that I hope one day people can roleplay in and make friends etc, I must admit I am one of those introverted people who just made my place because I enjoy building things and have basically no experience in roleplay itself. What do you guys enjoy the most in roleplay and what in your opinion makes a high quality roleplay experience?
  • Create New...