Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

69 Excellent

About arabellajones

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Now, how do we notate this to be clear? Some people do seem to delight in making this complicated... We start at position Pos₁ and rotation Rot₁ and move a distance Delta. We then do the llSensor routines for the Bogie prims to get the new centreline for the Coach. We're on Vec₁ and we have a Vec₂ defined, and the lines should intersect at Pos₃. Some scripts call it an "Orbit", a rotation around an arbitrary axis. Is an Orbit around Pos₃ with the change of Coach-axis from Rot₁ to Rot₂ going to be a good enough result? Do we need to set a maximum distance to Pos₃ Let's check a couple of standards. The European Berne Gauge specifies 4m centre to centre, which is about 5.45m for SLRR track The SLRR loading gauge is 4m, compared to 3.15m EBG, which would allow 5m centre-to-centre, so maybe the SLRR loading gauge is a bit narrower. Anyway, if the train somehow jumps sideways from one track to another, call it 5m. If the parallel tracks are assumed to converge 250m away, that's 5/250 radians. which is about 1 degree, and that's a pretty small rotation, just do a sideways translation. Think about this. We have a triangle. Does the difference between a right-angle triangle and an isosceles triangle matter? The Orbit method uses an isosceles triangle. We need to find the distance for the sidestep, but will the difference between sidestep-first and rotation-first matter? From the SLRR standards, a maximum curve rate of 15 degrees in 5m. That's about 0.25 radians in 5m, 0.05 rad/m, well below the point where the difference between a curve and a straight line matters. This is the Small-angle approximation. I am now wondering if I was looking the the VRC script for the wrong functions... If we can use Some of the rather scary-looking combinations of trig functions are suddenly a lot simpler. I had better remember to put this in my comments when I turn in my code.
  2. There's no real hierarchy of the prims in an SL linkset, so that's a bit of a red herring. So it might be necessary to take the position difference between the two sensor prims (a vector) and convert that to a rotation. You picked out an example I missed, thanks. We have two Guide-prim positions, and the average sets the position of the linkset-root. Those two positions also give us a vector which defines a direction, and we have to rotate the linkset to match that. We have a function to convert a Euler to a Rotation, but how do we get the Euler? Just running an llSensor/llDetectedRot from the rear bogie isn't going to work because we need to change the rotation to get the value we need. And, O botheration, this guide-prim vector doesn't always tell you much about the movement of the vehicle. We want the correct distance from the previous vehicle location
  3. What I have found so far: The standard VRC train script uses the the llSensor function to call the llDetectedPos function. This returns a vector value which is the regional coordinates of the target. This code can be put in a child prim: see the llSensor page. Key quote follows: Sensors placed in prims other than the root prim of an attachment will have their forward direction offset relative to the root prim's forward direction, e.g. a sensor in a prim whose +X direction is the reverse of the root +X will look backward. The earliest collision-based scripting for trains appears to be obsolete, but the change is not well-documented in the script. I have already done a small rant on that and I shall only refer reader's to Knuth's Literate Programming. A code fragment is here: { llSleep(0.5); llSensor(gsSensorTargetName, "", ACTIVE | PASSIVE, gfSensorSeekRange, gfSensorScanArc); } This is using one of several naming conventions too-briefly documented in the LSL Style Guide which we're expected to recognise instantly. It's a form of Hungarian notation. For a child prim, the sensor scan arc will be affected by the prim's local rotation. There doesn't seem to be any reason to make this different to the root prim. Thought experiment here: a bogie coach. Even on branch lines, these could be 70ft long, which in proportion to track gauge would be 30m for the SLRR. The root prim is the lead bogie (at the front) while the child (sensor) is the trailing bogie. That gives us two position vectors and two rotations for the nearest "Guide" prims. The arithmetic mean of the two position vectors should be right for the position correction. The VRC code already uses gvUnitToGuideOffset added to the llDetectedPos() so we need a value for the complete coach. This may be easier if both sensors/bogies are child prims and the root prim is the coach. There may need to be a GuideOffset for each bogie prim. So the centre of the coach is, in plan or elevation, at the mid-point of a line connecting the sensor/bogie prims, which is where it should be. But what about rotation? Do we just take the mean of the rotations returned by llDetectedRot for the two sensor/bogie prims? It makes sense. Obviously, passing the data between the various scripts is a complication. But I have been thinking about the real-world item, and how you can model it for SL, and fitting the scripting to that. It doesn't look all that complicated. For something like this it should be fine. (That Railcar entered service in 1934 with skirts over the bogies.) I do wonder if some of you LSL experts aren't looking at the whole problem. "Literate Programming" again: where's the starting specification in the documentation we see?
  4. One thing you're missing is that the model railroading hobby has some of the same space problems that the SLRR has. One of the standards for that, goes back over half a century, would scale out at about 34m radius. If you want to keep things in proportion to track gauge, you'd use a 45m radius with SLRR track. (I just looked this up.) Why they adopted that Broad Gauge standard, I have no idea. It's even more exaggerated than what they did with the classic Avatar design.
  5. I am not impressed by the way in which the code is written. It's not really documented. The most recent VRC free script apparently uses the Sensor method which the SLRR tech spec refers to, not the Collision method, but "sensor" isn't mentioned until line 300, and there's only an indirect reference in the comments. So I was on a wild goose chase. // this is setup for non-physical, phantom movement which uses Sensor events through llSensor, rather than Collisions, // but can be modified for physical, etc. The guidance code expects to run in the root prim of the linkset. That's how I have changed the comments. There's a concept called "Literate Programming" which I commend to the general attention of the scripting community. Because LSL is compiled into byte-code, you don't have to be parsimonious over comments, or assume readers can spot Hungarian notation as a naming convention. On this piece of code I suspect I'm seeing the use of Leszynski naming convention but nobody bothered to document that. Fair enough, you're getting a bit of that just from the use of such things as llDetectedPos And then there are two different conventions given in the LSL Style Guide , only as the two most popular, so it doesn't get you out of documenting it. Less than a screen to document only two out of an unknown number of naming conventions comes across to me as a little inadequate. Look guys, several talented creators I know have shuffled off their mortal coil, rung down the curtain, and joined the bleedin' choir invisible, and CoViD-19 hasn't even come into it yet. Without better documentation, your work will not survive.
  6. Yes, that particular example was built by the Great Western Railway, in England, other companies did the same thing. There was a driving compartment at the far end of the coach, from where the driver (US: Engineer) could control the train, while the fireman stayed in the locomotive. There's a good description of it all here https://www.svrwiki.com/GWR_238_Autotrailer_Third As for stovepipe hats... There is a song... Brunel
  7. That's the routine answer, widely used at the SL-Birthday events and others. With the content-delivery changes moving much of the high-volume traffic away from the Linden Lab servers things are very different from "A few years ago". Whatever the event, it doesn't help that some creators are still producing grotesquely over-complex models. Just look at some avatars in wire-frame mode. If the mesh looks solid, it isn't worth using at a busy event. It also helps if people turn up early, and give their viewer cache time to fill. But avatar components and textures can still be a problem. Starting with a minimal draw-distance can help. Come SL17B and I shall be running around with an all mesh avatar showing under 15k ARC. That's not a perfect measure of the load I put on somebody's connection and viewer, but it does leave me wondering what excesses Bake-on-Mesh really cures.
  8. There is one thing you missed at this stage, though it trickled out in the thread. Windows, Mac, or Linux, and which version. I had a fun time, earlier this week, with trying to get some software to run. Long story, nothing to do with SL, but some open source programming teams can't document their way out of a soggy wet paper bag. There was a bit of "everyone knows" in the process which nobody had bothered to document, neither before nor after a significant change.
  9. I know that the SLRR trains use a script in the root prim to detect the "Guide" prim in the track. These scripts are very old, and much is hardly documented: a few comments and maybe something about variable-names. Is there some way of getting the same sort of position vector between the nearest "Guide" prim and a child prim in the linkset. There is real-world rolling stock which, when scaled in proportion to the SLRR track gauge, is over 30m long. If a model were behaving like the real vehicle, there would be two points following the track, not the single central point of a root-prim. So, if one prim is still the root of the linkset, how can the position vectors be generated for the other prims? I know that there are train-things on the SLRR which are a single-vehicle/linkset that bends to follow the track. How might they work?
  10. There is a version of the standard VRC train script which allows this, but it depends on the SLRR track system to keep the follower vehicles on the track. It does allow sim crossing, but there can be failures. It works on the SLRR but not on the new Bellisaria line, because of differences in parcel permissions. The follower vehicles have to be set to maintain their distance from the "driver" of the locomotive. This "Carriage" modification is by Kadai Flanagan, and the copy I have is No Transfer. I know you can get it in stuff from the Waxen Works range, and Kadai Flanagan is still active in SL I am groping for an articulated vehicle version of this, a single linkset that can bend in the middle, but I need to understand how the Guide prim on the track is detected and followed. The documentation for the SLRR is woefully inadequate, a huge gap between knowing there is a Guide prim and the erratic commenting in the code.
  11. On what I have seen, most of the available train scripting is pretty old, maybe 2015, and there are features of the the new continent's system which make some SLRR features unusable. As far as I can tell, it is only possible to operate single vehicles on the line. Because of the permissions used on the SLRR, it is possible for a train to be multiple vehicles, most following the locomotive. That works on the SLRR but it's the big weakness at region crossings. Because the Belliseria railroad doesn't have the track as a distinct parcel with the normal SLRR permissions, these vehicle cannot work. The Quarry Freight train that people are showing off uses a different technology, a single vehicle which bends in the middle. It works well, SLRR or otherwise, but it's rather limited. The same tech applied to something in the style of the Wisbech and Upwell Tramway, passenger and freight traffic, would look rather good. Waxen Works did some SLRR-standard models for this. This web page has some photos of the real-world rolling stock. https://www.lner.info/co/GER/wisbech/stock.php I am slowly struggling through the train-scripting, trying to understand how it works, to produce some decent mesh models which run as a single articulated vehicle. Something such as a GWR 48xx locomotive with an autocoach would look pretty good. It wouldn't even need to flip, they could be driven from the far end of the coach. We really need a mole with a top hat...
  12. Depends on how your internet connection is set up, but it's fairly common for a domestic-line IP address to change if it's been disconnected for a while. So if your problem started after a disconnection, you may be able to fix it by turning off your modem before you go to bed, and reconnecting in the morning. Don't do this more than once. Repeated disconnections can make the ISP think they need to reduce your connection speed. There are other ways that somebody else could have been making a fool of themselves on the same visible IP address, but this is one you have a chance to deal with.
  13. I've been struggling with the Puppeteer script. The version in the Wiki is very old (http://wiki.secondlife.com/wiki/Puppeteer) and a later version is available elsewhere (https://grimore.org/secondlife/puppeteer) I have not found anything more recent. The problem I have been seeing is an apparent failure to record and dump all the steps. Often there are a different number of steps for the position and rotation data. That different number of steps suggests that it's not my forgetting to use the "Mark" option to record a step. Since the most recent version is dated 2015, and there are some old script packages still using it. I am wondering if anything has changed. In one case a 12-step rotation was dumped as a 6-step half-rotation. I can program a similar rotation, without problems, but synchronising the result across different prims seems poorly supported.
  14. arabellajones

    Blender 2.82

    I have Blender 2.79 with Avastar and blender 2.8 with the Avastar beta. This image works well as a desktop icon. Rescale to suit your OS and desktop,
  15. Short Answer: Yes The jargon and methods vary a bit with the modelling program but you can set several materials with their own UV mapping. Each material is what is called a "face" in the SL editor. The UV mapping is the 2D coordinates of the vertices of the 3D object. This is an example of a UV map; each section could be a distinct material/face, and the UV coordinates re-scaled to each fill the full range: they would overlap but each could use its own texture without wasting space. This is a tee shirt, front and back panels and two sleeves. There's a few things wrong with that UV mapping, a doubling over at the bottom edge, and I should have set horizontal edges in the mesh to be horizontal in the UV map.
  • Create New...