Jump to content

Wulfie Reanimator

  • Content Count

  • Joined

  • Last visited

Community Reputation

1,679 Excellent

About Wulfie Reanimator

  • Rank
    Passively Aggressive

Recent Profile Visitors

1,399 profile views
  1. You would get multiple results, but raycast doesn't cause damage on its own. Like @Fenix Eldritch said, you would have to process the results in a way that makes sense for you. If you used 3 rays in a triangle shape, for example, you could have 3 separate variables for each ray's result, and check those results in some set order to choose which ray is the "most important" for a hit. If RayA has a result, damage that avatar and ignore the rest. If RayA didn't hit, check RayB, etc. Also, regardless of how many rays you shoot (As few as possible! Rays can fail to cast completely if the sim is busy.) you should figure out what the expected maximum range for your weapon is, and then figure out the "width" of your raycasted shot, and then remember that you're shooting at a target about 0.2 - 0.4 meters wide. Your maximum spread should not be much greater than the width of your target (<0.5) at maximum range. Parallel rays are the simplest solution so you won't need to calculate an angle and you'll have the advantage of the maximum width of the shot regardless of distance. Ah, I had only tested it with an array of "visual lasers" that used raycast to determine their length. They seemed to form a spherical shape, close enough I suppose but interesting to see. This one even I didn't know about!
  2. Here's a small wrench to throw in: If the message that's received is NOT a valid vector, vReceived_vector will get ZERO_VECTOR as its value. So, if your script is always listening, or might also receive non-vector messages, you may want to verify that the message that's received is actually supposed to be a vector. The absolute simplest thing to start with is to see if the message begins and ends with < >, to at least have an idea if it could be a valid vector. The useful snippets section on the wiki has a convenient function to do everything.
  3. Two fun facts: An avatar that is standing up is shaped like an oblong sphere for raycast. This sphere is smaller than the avatar's hitbox (from render metadata). An avatar that is "sitting on ground" is shaped like a pyramid with a flat tip. Shoot multiple rays, either parallel to each other or starting from the same point but diverging by some degrees.
  4. Impressive word salad, but here: https://get.catznip.com/downloads
  5. While it is technically possible to fix, it's not very practical/efficient. It takes a lot of calculations to figure out which of many surfaces is in front of the others, and what order the rest of them are in. Most games make an attempt but to get it right in every situation is veeerry slow, so most games try to avoid using blended alpha surfaces. Second Life has no quality control or standard for assets, so these kinds of technical concerns aren't thought about or worked around by almost anybody. Creators just accept it as a reality and leave it at that.
  6. I think I'm starting to understand where this weird separatism is stemming from.
  7. Yes, but this only makes sense for TCP because TCP is very pedantic about making sure you received the previous packet before sending in the next one. That article specifically says: SL uses UDP for most things, including texture streaming. UDP is one-way, ideal for streaming content (video, files, etc...), because it does not care whether the previous packets were received before the next ones. The viewer handles and re-requests missing data and stitches them in the correct order. http://wiki.secondlife.com/wiki/UDP http://wiki.secondlife.com/wiki/Transfer_Manager http://wiki.secondlife.com/wiki/Image_Pipeline http://wiki.secondlife.com/wiki/Texture_Console
  8. Even if I grant you that grey textures are somehow bad for FPS on their own (I don't agree), latency does not affect how fast something is downloaded in the overall scale. You can have 10000+ ping and still download things at gigabytes per second. (Theoretically speaking. It's an extreme example to bring the point across.) Latency is a measure of time it takes for one packet (or a round-trip) to travel from A to B (or A->B->A). When you're downloading contiguous data like a texture file, latency won't affect the download speed after the first packet has arrived, as the rest will follow just as quickly regardless of distance, because they were already on the way right behind the first packet. (Similarly, the viewer won't wait for one texture to finish downloading before the next -- the viewer is receiving multiple file downloads at once. No delay between each texture.) Latency is only important for things like communicating inputs. If it takes 1 second after pressing W before your avatar starts moving... that's not pleasant, but you wouldn't notice the ping just from looking at how fast textures are loading. The act of streaming itself doesn't cause FPS issues. It's the CPU/HDD time spent on decoding a finished download. Let's say that hypothetically you start downloading all the textures on a sim at the same time (ignoring viewer restrictions), but due to a disconnect or you throttling your internet speed to like 1Kb/s, you're not going to experience any lag from textures. Why? Because your computer can and only render what's already on your computer, and rendering no textures is super easy. I guess this is a bad example because you think that the streaming itself causes problems and disconnect/1kbps means there's no streaming. But just go and open some debug consoles in your viewer and watch where the slowdowns happen. It's not proportional to current network activity. No textures ever finish downloading = No lag from decoding them into usable data = No texture lag. And then you get disconnected from SL because 1Kb/s is not enough to sustain you.
  9. I mostly agree with you but here you're equally misinformed. The quality or bandwidth or latency of your connection has no impact on FPS, because there's absolutely no networking involved in rendering on your computer. Stadia is a streaming service, where the rendering happens somewhere else and the resulting frames are sent to you over the internet, which is why FPS might be lowered by Stadia to reduce the size of the stream when they detect you can't handle it. There might be some residual side effects from a slow connection because of other systems, like texture loading, but even that shouldn't be a thing because if there's little texture data coming in, there's also nothing to decode, which means no lag from loading.
  10. I can't tell if this is satire, but since we're on the SL forums, I don't feel so confident...
  11. These are just "offsets" relative to the size of the texture itself, think of it like a percentage. A texture, by default, is at 0.0 (or 0%) offset for both X(left/right) and Y(down/up) directions. If you were to set the values to 0.5 (50%) and 0.0, you would see that the texture is shifted halfway to the side, so that the "edge" of the texture is in the center. 1.0 means 100% to the left/down. -1.0 means 100% to the right/up. You can experiment with this by selecting an object you own while in Edit Mode and going into the Texture tab. There will be settings called "Horizontal offset" and "Vertical offset."
  12. Here you go: https://vibhub.io/ There's no hope for SL in VR though, unless you like headaches and vomit.
  13. I was thinking even more broadly, but I think the method you're showing there is more practical.
  14. It would also eliminate any need for massive if-trees. Since, if everything is in one list, and you already know which B and which C have been selected, you can immediately calculate the correct position in the main list without any if-checks, and get the right amount of data out.
  • Create New...