Nova Convair

It's not a bug - it's a feature ! ?

Well I am using and observing viewers over many years and I don't see anything unexpected in FS memory consumption. You have 2 GB texture memory instead of 0.5 and go to a busy place. What you expect then? Even in old times the 32-bit LL viewer cranked up to about 3.5 GB before it crashed and now the situation is far worse All the extras in FS use memory too. In the past there were versions with memory holes but atm FS and LL viewer never crash, so all good from my point of view. If you dont have the memory you need to lower features or change viewer. For performance I barely see differences. The LL viewer seems to be slightly faster but that depends on situation too. If you like LL give Kokua a try. It's very close to the LL viewer with a few extras and optional RLV and is kept up to date.

How do you want to compress the notecard? In a whole? Then you need to read the whole notecard 1st and then decompress it and split it to lines again. (requires double memory consumption during the process but less lines to read) Or line by line? Max. line length (for script reading) is 256. I see no way to speed things up here. I never had the wish to speed up notecard reading but shouldn't it work to simply fire 10 ReadLine commands at once and sort the incoming lines in the dataserver event? Or read from multiple notecards at once? (I'll not test that atm)

Persecution complex? Nothing happened, nothing happens and you see bots everywhere. You don't even have proof that they are bots. This is SL and not RL so relax. In RL a violation of our home is serious. In SL it's just an illusion. If someone dosn't belong there kick 'em out and if that's too exhausting then install an automatic asskicker and relax while you watch it working.

When I started scripting - many years ago - I wouldn't have been able to make a turret system - even with a background in programming. I made smaller tasks 1st and most gain of knowledge started with the question: "why this damn thing doesn't work?" But thats about one thing not working and not 10 at the same time - that leads to nothing. The op needs to understand how SL scripts work at 1st. Without that basic understandment there will be no chance to solve scripting tasks and problems. There are a few scripting classes out there. Maybe take a few and script some more simple things for a start. If you want turrets NOW you need to hire someone.

The turrets I use know their working angle. But if you have a complicated shape or wings there may be a problem to implement limits. You can "shoot" with castray 1st and see if it hits the target or something else (like your ship). With that info you can decide to follow up with a "bullet" or wait for the next round. But ! What is your target? An avatar? In that case you will never hit the target but only the ship the avatar is sitting in. In that case you can not test for a target hit but check the distance of the castray hit and the name of the hit. If it's your ship's name then don't shoot. if it's approximately the distance of your target then shoot. if it's another distance - your decision - I prefer to shoot in doubt though Oh ... another dirty trick is to fire the bullets as physical+phantom. They will flip to physical+non phantom after a short traveltime - preferably after they have minimal distance to your ship. Just saying.

Your blinds are most probably inside of an invisible prim or mesh structure. Can be a challenge for a non builder to select it then. - Just move your camera close (almost 0 distance at flat angle) and select it (is not hard with some practice) - or derender the house and whatever is in the way, then you can easily select the blinds (not with LL viewer) - or go to build/pathfinding and get a list of all objects filter for your objects and sort by distance, should get you to the blinds in front of you quickly and you can select it

Imagine this scene: Object A has a script that sends out a message 1000 times - as fast as possible - and a time measuring. It takes about 1-2 seconds to send 1000 messages. Object B has a script that receives this messages and counts them - and a time measuring - triggered by a start and a stop message included in the 1st and last message of Object A. A script can receive about 12-15 messages per second as it turns out. What happens? Object A runs for one second then it has fired out 1000 messages Object B runs for about 70 seconds and reports that it has received 1000 messages Conclusion The event queue is 64 entries, but the sim obviously runs a message buffer in a way that it does not overrun the event queue of a script. The size of the buffer is limited. If i send longer messages or 5000 instead of 1000 messages then Object B reports less received messages than were sent by object A. So the chance of missing a message are almost zero - except the sim is full of communicating scripts.

It's floting point math and no bug. 1.5 + 0.5 = 2.0 yes? not quite Decimal round numbers do not match binary numbers. So a round decimal number is not a round number when converted to binary format. If you typecast it back to decimal it is not the same number anymore. 1.5 + 0.5 = something close to 2.0 subtracting the 0.5 means you subtract 0.5 from a number that isn't exactly 2.0 and the result is something close to 1.5 Repeat adding and subtracting 1000 times and you may even get a visible difference (if the errors don't compensate each other but accumulate) If I compare floats in a script I always think twice what exactly am I doing here. In this case the result is out of your scope and you have to live with it.

And what has this to do with SL? There are no drugs in SL. So the question is: is it illegal to roleplay drug usage in a "computer game" or "virtual world" The answer is NO for most places. Even that doesn't matter since LL is not obliged to transfer all rl laws to SL. LL decided that this is adult activity. Point. Is that good or bad? I find that there are good reasons to declare this as adult so I wouldn't complain.

I switched it on when it became available and it's always active of course. SL without ALM looks so incredible bad I would never revert.

What Innula said. But everybody can rez a prim - name it and wear it - so that can not be used to validate anything.

That's not appropriate behaviour for someone with the name DarkEmperor

Well, that's exactly what I do But the LSLForge environment removes all unused functions and variables and even replaces the global variables used as definitions by literal values. The LSLForge modules are alot better than includes. But that is a clever programming environment. LSL by itself has nothing of that functionality. For me the LSLForge environment is very comfortable and I'm not dependant of a specific viewer - which is important for me. Setting up Eclipse for that may be a little overkill but I have no problem overkilling things a little

I never encountered any problems with camera scripts. But the viewer can set limits for the camera movement and a script will not change that limits. And of course you can override any settings by moving the camera manually. If you did - you need to press <esc> before the script tries to move your camera.

It's not <PRIM_MEDIA_CURRENT_URL,"https://www.google.com/"> it's [PRIM_MEDIA_CURRENT_URL,"https://www.google.com/"]

The hud can determine the owner of the collision object which sends the message. (llGetObjectDetails) So it can accept teleportetion commands only from objects of specific owners. That should prevent any griefing activities.

Then let your hud listen and the collision objects send the position where to teleport to the hud. You can use llRegionSayTo(<avatar-uuid>,channel,(string)position) That way only this one hud will get the message and the avatar uuid you get by the collision event. Maybe think about some security measures, so that not every griefer can teleport every RPer or all of them at once.

A script that needs permissions needs to request that permissions. The permissions are then granted for that script. For the requesting script and ONLY this script. If you have a 2nd script that requires permissions this script needs to request permissions too. For your case: your hud has teleport permissions. There is no need to do the teleportation by another object. Just let the object send the target location to the hud and the hud can do the teleportation. Otherwise you need to grant permissions for every collision object or use experiences. You did read the wiki and know that llTeleportAgent can only teleport the owner? If you have other plans you definitely need experiences.

Multiple possible solutions. ----------- Strided lists will of course help here to manage multiple lists in one. ----------- Another way is to add markers to the list. Example: list data = ["@1","1","2","3","@2","3","4","5","@3", ..... ,"@21"]; You call your function with parameter index=2 for example and do: integer start = llListFindList(data,["@"+(string)index]) + 1; integer end = llListFindList(data,["@"+(string)(index+1)]) - 1; you find your list elements from start to end in the data list ----------- Another way is to store separated strings in lists. Example: list data = ["1|2|3","4|5|6","7|8|9" .... ]; You call your function with parameter index=2 for example and do: list sublist = llParseStringKeepNulls(llList2List(data,index,index),["|"],[]); your list elements are in sublist ----------- If the sublists have all the same length a simple calculation gives you the index of the sublist The best solution depends on the circumstances and details of your application

Umm ... needs recalculation. earth radius is 6.4 million m or 6400 km. Assuming that kms means km

Hmmm ... I come to the conclusion that there is unpredictable moderation with unpredictable results. Since I didn't post much here anyways it's easy for me. I'll completely stop posting, I'll just check for news from time to time.

So the message is: the customers are too stupid for mod stuff. Thanks for the confirmation through this thread. If you don't like my simplificated interpretation - I don't care. The good thing is - it did and will do - save me many 1000 L$. Keep up the good work.

Not possible. There is no water in SL There is a level for the water line and your viewer paints a water surface at that level. If you are under the water level your viewer will switch to blurry view to simulate that you are "under water". Means of course the "water" is everywhere. Since it doesn't exist you cant pump it out of your house. Invisiprims are obsolete and most residents see only grey prims instead.

I wasn't sure so i tried it out and set a landing point at 3800m. Works fine, landing points can be set everywhere.