Nova Convair

And why can I only add 2048? Ok, some more but 8192 is far out of scope It's obviously 16 bytes per element in my example and 4 in your example.

I made a test. 1st thing I encounterd - 8192 integers do not fit into memory at all. Although I see NO error in your method of doubling the list - it obviously doesn't work. // // Memory allocation test - do we get free memory back? // integer listcnt = 2047; default { touch_start(integer total_number) { llOwnerSay("Free mem before allocating list: " + (string) llGetFreeMemory()); list buf = [1]; integer i; for (i=0; i<listcnt; i++) { buf += [i]; } // llSleep(0.5); llOwnerSay("Free mem after allocating list of " + (string)llGetListLength(buf) + " integers: " + (string) llGetFreeMemory()); buf = []; // release memory llSleep(0.5); llOwnerSay("Free mem after releasing list: " + (string) llGetFreeMemory()); } } And the result is: [03:41] Object: Free mem before allocating list: 61140 [03:41] Object: Free mem after allocating list of 2048 integers: 28228 [03:41] Object: Free mem after releasing list: 28228 [03:41] Object: Free mem before allocating list: 28228 [03:41] Object: Free mem after allocating list of 2048 integers: 28228 [03:41] Object: Free mem after releasing list: 28228 The last 3 lines repeat over and over on every click. So what happens: - You need to use llSleep before you you llGetFreememory or you will not get a valid result. - After adding 2048 single integers to the list the occupied memory is not freed - On the next run there is no stack/heap collision - that means an automatic garbage collection was performed an so we can run this forever. It makes no sense that you could allocate 8192 integers to the list. Some math: an integer needs 4 bytes but every list element needs at least a pointer (4 bytes) and most probably some extra info like type flag and stuff not to mention a backward pointer so I don't see how 8192 elements will fit into 64k. I've read that scripts can exceed the 64k limit for a short time - in this case a garbage collection is forced - and if the result is still over 64k a stack/heap error is generated. Probably this doesnt work like expected here. Edit: clicking after 15 mins gave this result: [04:09] Object: Free mem before allocating list: 61140 [04:10] Object: Free mem after allocating list of 2048 integers: 28228 [04:10] Object: Free mem after releasing list: 28228 If seems that garbage collections are performed when the script idles long enough.

You don't need a special viewer. You just need to compile in world and NOT in inventory.

Yes, insanely fast But not over time like it happens here. If the script continues to run then you have left the recursive stack. You can't accumulate used memory on the stack that way in LSL. Either you crash or the recursion has ended. If processing stays in the function then you will have no events in that time. Edit: I get the impression that it's not known how recursion works. Example: - We call a function - let's call the level we are in: incarnation 0 - Now the function calls itself - the processing happens in incarnation 1 now - same function - Now we do it again - the processing is in incarnation 2. - The function ends - but that means incarnation 2 stops to exist and is removed from the stack and the processing ends in incarnation 1 - at the next statement after the recursive function call. - The function ends again - incarnation 1 is removed and the processing continues in incarnation 0 - The function ends again - now that we are leaving incarnation 0 the control goes back to the event where the function was called the 1st time. As you can see - you can not leave until the whole stack on incarnations is worked off - you can not leave things back on the stack. If that would be possible - LSL wouldn't be able to do recursion at all. But LSL can do recursion! So there are only 2 possibilities - the recursive call crashes your script - or leaves with a clean stack.

LSL is single threaded - as long as an event or a function is processed - no other event will fire. If processing is in an incarnation of a recursion that will block any other events. If processing leaves this incarnation it will continue in the previous incarnation of that function and still block events. The script will only continue to process events when all incarnations of the function are left. The stack is cleared then. So in the end it's no difference to any other non recursive function.

There are 2 ways to make a stack/heap collision happen. Allocate heap space. That isn't supposed to happen when you only use local variables. But maybe there are functions that always use heap space. If the heap memory is not marked as free - because the function is buggy or crashed while executing - then a garbage collection will NOT fix it. The other way is to "forget" to reset the stack pointer. Do you have "return" statments or multiple ones in the middle of a function? I know this is supposed to work and I see it working but maybe you created a special scenario where it doesn't. A garbage collection will also NOT fix this of course.

I see what you mean Molly. A small experience that requests one permission for example. Only needed for the few cases where the present permission system doesnt work. One point I see is: object 1 needs permission A and object 2 needs permission B - You are aware that both objects need to ask for permissions A+B although they dont need both? That's the 1st step to get more permissions as you need. Making many small things with taylored permission would require many permission keys. Doesn't look like that's part of LL's plans. By my opinion it's absolutely not necessary to limit things - I'd like some expansions. But that's like the brexit - people have fixed opinions. 😎

I don't think so. That will make no sense since there will still be a few permissions lined up. So it makes no difference for the irrational paranoid ones. 😋 Another point is that there can be 100s of scripts in multiple parcels using that experience. You want to collect all that permissions? Really? Oh, and every day a new script can be added - which means you need to give experience permissions over and over again. So - forget it - it's not the way permissions are implemented.

It's not possible to permanently revoke permissions for any piece of furniture, huggers, dance balls, elevators, teleporters, whatever. (the script can keep them forever if it wants to) But experience permissions can be revoked easily and anytime. That kind of irrational behaviour made me think that experiences are completely useless - except you really build an experience game/adventure/whatever with it. Even then you will have to block alot of people. But I see the point here. You don't know what could happen and that's the scary thing for many people. (not for me) You need a list: - this thing will teleport you when you stand on the platform and its activated - you will die horribly if you step on a trapdoor - a hud will be attached to you If people get to know that in advance they will confirm (or run away crying maybe?) hehe Problem is - nobody will read that if it fills the whole screen. So - most probably - experiences are and will be useless with very few exceptions.

just type in chat: tp2cam Firestorm required and you need to activate the commands, there are more commands. Since you mention FS it's no scripting question and I don't see the relation to RLV. Even if you script that I don't see the relation to RLV.

You can use an autoincrement field in the database. The numbers are unique. If you need it in a variable while performing an insert you can get it with lastInsertId() Only the database can guarantee you unique numbers, everything else is clumsy. In LSL - llGetTime delivers a float - I don't know the resolution - random numbers - uuid - date - if you mix it all up you can consrtuct something that is unique (with a 1:1 million chance of failure)

What would I do? Since I live in a spaceship I can park it 100m higher, but that's no option for most others 😎 Plan B: I place an invisible volume detect prim at that spot and add a script that will tp home+ban temporary on contact. Avatars will still appear but only for a fraction of a second. Maybe add a whitelist in case some friend or me walks over that spot. But: someone circumvents privacy and security settings by using an army of alts. LL should ban that whole army in a single strike. Since there is a possibility of an error the owner of that army should get 1-2 warnings. But after that - kill 'em all!

There is no division with speed as the divisor in the code so thats no problem. The only divisor is turning_ratio and that is a constant. And - scripts crash on division by zero errors and don't generate more errors then. The only terms that can generate errors are llLoopSound, llStartAnimation, llStopAnimation - this ones generate an error in the debug window for a missing animation (or a misspelled one) Missing permissions can happen too in theory but then the error is shouted instead of the debug window so that would have been recognized. Edit: Wulfie - it doesn't matter if speed is zero - look at the division again.

Are you aware that the control event is constantly triggered when you hold down a key? Every bug here will flood you in no time. The error message tells you what the problem is.

You need to click on "More Info" and then allow it. It's quite normal for all software that you download - except the publisher has payed microsoft so their software is signed. That's nothing new so not related to the 1903 update.

I got curious and downloaded this viewer. Works like every other viewer - it downloaded within a few seconds and I get a working exe file. It's hosted by bitbucket and everything not on the bitbucket domain is blocked here (pictures, media, scripts, ads, whatever) So I don't see any server sided problems. That doesn't help you much but gives you a hint maybe.

Hi, Namen nennen ist gegen die Forenregeln also entferne den Screenshot besser. Ich habe ein paar Namen durchgecheckt. Teilwiese gleiche Bilder und Texte. Man kann also vermuten, dass es sich um eine Person handelt, mit einer grösseren Anzahl von Alts. Da die Aktionen alle gleich sind würde ich weiterhin vermuten, dass es Bots sind die ganz einfach ihren Job machen. Warum du die Zielperson bist - keine Ahnung. Es muss jedenfalls ein Objekt sein, dass du trägst und das den Vorgang startet. Lege mal alles ab und schaue was passiert. Wenn die gebannt sind, dann können die auch nicht auf deine Parzelle kommen. Da ist was nicht richtig eingestellt oder du bist im Irrtum über deine permissions. Bedenke, dass ich keinerlei Informationen habe und hier nur Vermutungen äußere.

I don't derender avatars. I set them to not render (turns them into a jellydoll) or block (grey jellydoll) That way I don't step on them by accident and can step on them on purpose. 😎 And for the feelings of things being there or not - nothing is there, everything is virtual and if I feel the need to filter stuff I do that. Of course there are possible incidents - If your avatar can't pass an open space you maybe need a better memory about what you have derendered? 😋

You can check in the touch event if the owner or someone with the same active group than the object has clicked. touch_start(integer total_number) { user = llDetectedKey(0); if (user == llGetOwner() || llSameGroup(user)) { menu_page = 0; menu(user, "\n\nPlease select one below.", texture_list); } }

You start in SL and make it into RL - that's easy but only the 1st step - more difficult is the 2nd step from RL to the Real World 😎

The assumptions about script memory are completely wrong. - Scripts don't use 64kb memory - they CAN use up to 64kb - what they really use - only the script itself knows that - external meters have no clue and only show the max. - Equal scripts are only stored once. That means: you have a script that - let's say - uses 10kb of memory. Now you copy that object so you have 2000 out there. How much script memory is used? 10kb code! (and NOT 2000x10!) - plus variables for each script of course. So memory will be no limit here. But script execution time. If you have more scripts than the sim can handle the "scripts run" will show a percentage under 100% If you have a "scripts run" of 50% that means that only 50% of the scripts are executed in every frame. That means that every script runs at half speed. If you put out more scripts the processing speed of each script will sink further.

Looks confused. Position - contains a distance TargetPos and toucherPos are assigned the same value When you calculate the distance in "Position" - "npcpos" wasn't assigned a value so it's <0,0,0> toucherPos wasn't assigned a value so it's <0,0,0> So the distance is 0 and you perform a teleport as expected. When you create an npc does that have an immediate effect? Or does it take some time? Need to take that into account aswell if it takes time so you need to wait or use the timer or an other event if there is one for that purpose.

There is no water in SL. The server tells the viewer a number. That's the height of the surface. The viewer will draw a water plane at this level. No water in the sim, no terraforming. Of course it's imaginable that there are multiple water areas where you determine the position, shape and level. That would be a feature request though. The whole landscaping/water/environment is very poor in SL. But EEP is a 1st step - if LL gets that implemented properly.

You repeat what i said b4. A script can send about 1000 messages per second. (depends on script usage of course) And a script can receive 12-15 messages per second. (depends on script usage) That works because the sim buffers the messages. In this case we don't want buffering - we need to process the messages when they arrive and so we will need at least 2 receiver scripts to have enough receive capacity. (not for 1000! of course - but a stable 15-20 receives)

Some remarks: llRegionSay can not be used if you want to cross a region border - llShout will do - but some math required for the crossing like usage of global coordinates. llSetRegionPos is too slow by my observations and inaccurate - but may be handy in case your vehicle got desintegrated and scattered over the place llSetLinkPrimitiveParamsFast can be executed up to 45 times per second - but - waste of resources since you will never see it. The sim does not update your viewer 45 times per second. That depends on object size, your distance, how busy the sim is. Under good conditions you seem to get max 15. A script can send 1000 messages per second but a listen event receives usually less than 15 messages. If the sim is busy - less or much less. You will need more than one receiver script. llSetKeyFramedMotion has perfect movement for that purpose but no way to sync it between the objects. Maybe needs some testing though. llGetObjectDetails is useable for region crossings (reaches 34m into adjacent regions according to wiki) and has no delay. Could be a candidate. Maybe needs some testing. Smooth movement is only possible with a combination of server side movement plus viewer side interpolation and that works only for physical objects and llSetKeyFramedMotion and both are not useable here. So it will always rattle a bit. In case script execution is NOT at 100% only a part of the scripts is executed in every frame. You can imagine what that means.