Nova Convair

LSL scripts are compiled for running under a very special run time environment and of course scripts can become compiled. In this case an interpreter is surely way to inefficient. So you think that you can take an object into inventory and take it back out and it continues to run. So the variables need to be stored somewhere you think? I don't think so. I think that the code, stack and heap is stored as a memory block and therefore no single variables. In a compiled code you have no variables. Just pointers that point to a place on the stack or heap. So the only one that can retrieve the value of the variable is the script itself. Anything else would require debugging and reverse engineering. I suggest to solve your problems yourself by using what you have in SL and not ask LL to solve your problems for you. That surely won't work.

Orbs work fine on group land in general but of course not every crappy orb you find out there. When do you need group land? - to run an orb 24/7 even when you are not online - to allow setting of parcel media for other avatars - to give other avatars land powers - for group building You do not need group land if you just want others allow to rez stuff permanently

Du hast keine L$ gekauft. Du hast ein Angebot abgegeben eine bestimmte Menge L$ zu einem bestimmten Preis kaufen zu wollen. Jetzt wartest Du bis 1. jemand L$ zum entsprechenden Preis verkauft und 2. Du in der Warteschlange nach vorne gerückt bist und dran kommst. Warte also ein paar Tage. Sollte dein Preis unrealistisch gewesen sein, dann wirst du allerdings in 100 Jahren immer noch warten. Das Geld, das du bezahlt hast ist in Form von US$ auf deinem account geparkt. Allerdings kommst du nicht ran, da es für den Ankauf von L$ reserviert ist. Cancel also deinen Auftrag, wenn du nicht warten willst. Die US$ werden dir dann gutgeschrieben und beim nächsten Kauf verrechnet. Ich schlage den Sofortkauf vor oder du informierst dich genauer, was du da machst.

Nobody knows anything at the moment - so I will not waste my time with it. Once it's known what happens - then it's time for solutions. Bye for now

c:\Users\<username>\AppData\Roaming\Firestorm_x64\user_settings\windlight\ That's the windlight path for Firestorm. For other viewers replace "Firestorm_x64" by the viewers directory like "SecondLife" for the LL viewer.

It's not necessary to reset scripts. Just initialize what's needed when it's needed. If that seems too difficult use a 2nd script with the only task to read/write data. That's easy and there is no need ever reset this data script. (as long as you avoid heap/stack collisions of course) For a grid wide storage I see 3 possibilities: 1. KVP storage in an experience - disadvantage: you need an experience. For a hud I think KVP is pretty useless. 2. Your own external server. Perfect solution but only for you not for others. Probably too much efforts. 3. You use a server-script in World. If you ever loose connection you need to link again by - having a backup server somewhere or kvp or the server is in a sim that you visit regularly or whatever. A minor annoyance.

I just calculate the list index. If I have a 2 dimensional array with index a and b and the size of a is 10 (0-9) then the list entry is simply b*10+a For a=0..9 and b=0..x If I store records I use a string with divider between the elements as list entry. The list needs to be initialized since it's not possible to read/write non existing list elements. If the data structure becomes really complicated then json is maybe a better choice

You can not optimise things that way. You have a script with one listener that is completely inactive all the time. (as long as the hud isn't used) And you want to optimize that with a script that triggers a timer regularly and burns cpu cycles that way. If you want to optimize things you need numbers but not guesses. In this case you can compare both scripts in the management console which requires you to be an estate manager. Even then, the load is so low you won't see much here so you need to put 100 scripts into each object and then check and compare the script load. That gives numbers and a base to decide about optimizations. In this case it's a waste of time and energy anyways. A while ago I made some tests and even if you have a few 1000 listeners you will not notice any problems. If you trigger them all at the same time 1000 times in a row then you will notice an effect the script execution of the sim will recover shortly after that load btw.

Circumventing this is easy list data = [1,2,3, ... 75]; default state_entry() { data += [76,77,78, ... 150]; data += [151,152]; llOwnerSay((string)llGetListLength(data)); } }

The number of list elements is not limited but by available memory. What Phil means is: how many elements you can assign in the script header. Example: list data = [1,2,3,4, ... ,75]; In the past there was a limit. I don't know if the limit still exists since I don't need that large initializations in my scripts But try it out - just add more elements for data: list data = [1,2,3]; default state_entry() { llOwnerSay((string)llGetListLength(data)); } }

I tested it and wasn't happy with the performance of moving_end. I wasn't aware that this event is of the type: "yes it's there but it's not useable". So I replaced it vector act_pos; result() { integer Dice1 = 0; vector vPosTest;vPosTest = llRot2Up( llGetRot() ); if (llFabs( vPosTest.z ) > 0.5) { if (vPosTest.z > 0) {Dice1 = 2;} else{Dice1 = 4;} } else { vPosTest = llRot2Left( llGetRot() ); if (llFabs( vPosTest.z ) > 0.5) { if (vPosTest.z > 0){Dice1 = 1;} else{Dice1 = 6;} } else { vPosTest = llRot2Fwd( llGetRot() ); if (vPosTest.z > 0){Dice1 = 5;} else{Dice1 = 3;} } } llOwnerSay((string)Dice1); } default { state_entry() { llSetPrimitiveParams([PRIM_PHYSICS, TRUE]); } touch_start(integer i) { llApplyImpulse(<0,0,10>,FALSE); llApplyRotationalImpulse(<llFrand(1)-0.5,llFrand(1)-0.5,llFrand(1)-0.5>,TRUE); } moving_start() { act_pos=llGetPos(); llSetTimerEvent(0.1); } timer() { vector new_pos=llGetPos(); if (new_pos==act_pos) { llSetTimerEvent(0); result(); } else { act_pos=new_pos; } } }

You probably will like that movement better: integer Dice1; default { touch_start(integer i) { llSetPrimitiveParams([PRIM_PHYSICS, TRUE]); llApplyImpulse(<0,0,10>,FALSE); llApplyRotationalImpulse(<llFrand(1)-0.5,llFrand(1)-0.5,llFrand(1)-0.5>,TRUE); Dice1 = 0; } moving_end() { vector vPosTest;vPosTest = llRot2Up( llGetRot() ); if (llFabs( vPosTest.z ) > 0.5) { if (vPosTest.z > 0) {Dice1 = 2;} else{Dice1 = 4;} } else { vPosTest = llRot2Left( llGetRot() ); if (llFabs( vPosTest.z ) > 0.5) { if (vPosTest.z > 0){Dice1 = 1;} else{Dice1 = 6;} } else { vPosTest = llRot2Fwd( llGetRot() ); if (vPosTest.z > 0){Dice1 = 5;} else{Dice1 = 3;} } } llOwnerSay((string)Dice1); llSetPrimitiveParams([PRIM_PHYSICS, FALSE]); } } moving_end is not 100% reliable so a little stall here and there will happen, (just click again) can be solved by refining the script.

I've seen that topic many times here. Personally I would prefer automatic flak cannons to deal with overflights though - orbs are so boring.

I've seen many places that look like crap with shaders. Thats because they are made by someone with shaders and shadows off. You need lighting, the sun will not shine through the roof anymore. Without proper lighting you have no shadows and see no materials. The windlight setting can kill every good atmosphere too. See someones place and you know their preferred graphis settings

I needed to check that. There is a setting to check on/off in the about section of the parcel. If the sim is set to adult it's set to adult and can not be changed. If the sim is set to general it's labeled moderate but switched off and can not be changed. If the sim is set to moderate it's labeled moderate and you can switch in on or off. Didn't test if it has any effect. I think its only displayed in search result.

About turning off scripts. My huds will continue to run in that areas because they are made that way. To run every script in every hud/object the only thing to do is to fly up over 70m. That's where the no script zone ends and everything will run again. And dont say you switched off flying. Thats not really possible. Even more funny is when i see clubs or homes in a skybox with scripts switched off. Never wondered why everybody can run scripts? jeez

I can login better the more I approach full moon. What does that tell us? Nothing of course. It's interesting how you can make nonsense info by just state something and have a few people that support it.

I had a short look in the landing area. Triangle count is low - by my standards but I used over 700 MB of texture memory. The sim looks ok, a bit overscripted but thats harmless. Scripts will run at the speed of 50-80% of their normal speed. Huge spikes of "net time" whenever someone teleports in - that causes the rubberband effect. So they are either pretty evil avatars or they have to load alot of stuff - most probably too many of to hi res textures. For the scripts - that's not too important here but someone with access to the management console can check if we have objects that use an unusual high amount of cpu time and kill them. Most probably there aren't any though. Another problem can be avatars loaded with 1000 scripts when they TP into the sim. Tell them or kill them or both.

I kicked Flash out a few years ago and got rid of that garbage. The MOAP TV I made lately didn't have problems though. Youtube and some random tests worked - but I made no field tests - so I may have missed certain content.

I don't see a solution. If we assume that hud and vehicle get and exchange an url each - whenever they enter a new sim - then from the viewpoint of the hud: - can communicate to vehicle by http if it is still in the old sim - can communicate by llRegionSayTo if it's in the same sim - need external server if it's in an unknown 3rd sim Experiences are not useable since you need it enabled in all the sims you travel. That's only possible in very special cases like a multi-sim-racetrack. For a reliable communication in all cases you need an external server.

Small addon: llGetOwnerKey only returns the uuid for the name - llKey2Name or llGetDisplayName required for the name. string userName = llKey2Name(llGetOwnerKey(id)); // Get the name of the person who has sent the message.

You can see exactly who is on the same sim and where. Just camming is not possible if you are not on the same parcel. If you always visit the same places someonn can just TP through all your places until you are found and of course can see who is with you. No devices or magic needed. The LL viewer is a bit limited here but TPV's offer more info about your environment. I wonder why I would care if someone knows where I am and with who? That's for me that important like a sack of rice that drops somewhere in China. This is SL and not RL. But for me SL and RL is not connected in any way. If that's different for you - maybe rethink how you want to appoach SL.

Attach everything you wear to a DIFFERENT attachment point. One Object per attachment point.

"llDetectedKey(0)" doesnt work in a listen event. Replace it by "id".

You request permissions and immediately switch state - so your run_time_permissions event is never triggered. start() belongs into the run_time_permissions event.