Ela Talaj

Why would someone working in an object-oriented language on a real-time platform charge about 50% of a junior programmer wage? Are you offshore or just a starving college student?

Like this ?

There is no LSL method known to me to register keystrokes except for those listed in llTakeControl() method http://wiki.secondlife.com/wiki/LlTakeControls

You may include several variables in the for loop construct. For instance for(i=0, j=100; i<100; i++, j--) is perfectly legitimate. In your example: for (liIndex = 0; liIndex < liCount; ++liIndex, liFlag = liFlag << 1) liIndex would be incremented by one and liFlag shifted one bit to the right on each iteration. In general there is no difference between C and LSLfor loops syntax so you may refer to any C language tutorial available on line.

You can sell notecards (or any SL item type for that matter) from this vendor

There is absolutely no need to verify dialog choice. The menu is not going to display any buttons not listed in the MENU_MAIN. Just make CHANNEL = -42, instead of 42, so no one would be able to just type /42 wrong color choice.

Prolly it would be somewhat elaborate. llPlaySound() is not going to play any songs because it plays no more than 10 sec clips so for each song have to load several such short clips and configure their sequence prolly in a notecard. I recall making one like that a long while ago, it is not too complex but still not completely trivial.

Everything has a maximum as a script is not made from rubber I don't really remember details on MLPV-2 and have no time to look it up for free but it would appear to me that the limitation is not in animation names but in associated positions. For each animation you have to load its poseball position and rotation. rotation is in a vector (Euler) format, so there are 2 vectors of 35 bytes each (or is it 36 bytes for a vector? don't recall from the top of my head), anyways considering list management overhead, we'd count 40 bytes per vector for the total of 80. A list of x bytes actually needs 2x bytes of memory for operations on that list, so a list of over 28000 bytes is highly improbable as you would not have enough memory left for code. So 28000 : 80 = 350. That is probably the maximum number of animations you can have. Should you start including 3-somes, gang-bangs, etc the maximum would decrease sharply because you would need 6 or more vectors to store in the list (2 per each poseball). the above assumes the list operations are handled memory-efficiently and that is a very big IF From what I looked at MLPV scripts long time ago they looked pretty amateurish. In any case look if all MLPV scripts you have installed run as mono, just to be sure.

Why not recommend exclusive products Ela made ?

"That second script, I don't have a lot of control over" is not very clear. Do you have modify permission on it or you don't? If you do, it should be fairly trivial to insert linked messages to send to your script after each llSetAlpha() or llSetLinkAlpha() call. Then you don't need any change event, just go by these linked messages.

There is no difference whatsoever between objects rezzed on the ground and objects worn (ttached) in respect to alpha properties. The problem with your script is that it will change alpha only for a listening prim, whether the root or a child. Instead of llSetAlpha(alpha_value, ALL_SIDES); you should use llSetLinkAlpha(LINK_SET, alpha_value, ALL_SIDES); Additionally, your timer event should be as follows. Figure out why as your homework timer() { llSetTimerEvent(0.0); llSetAlpha(0,ALL_SIDES); }

Don't do the while loop in such cases. It works, but it is awkward programming. Do either for(i=0; i<n; i++) { llRemoveInventory(llGetInventoryName(INVENTORY_TEXTURE, i)); i--; // that is what prevents your problem n-- // llSleep(1); } Or as darkie said, which is much better: for(i=n-1; i>=0; i--) { llRemoveInventory(llGetInventoryName(INVENTORY_TEXTURE, i)); llSleep(1); }

I've several products dumping recorded positions in IMs so a user could C&P them in a notecard and load back into a device. Each IM includes only one position. As there is 2 sec built-in delay it would take about a minute to dump 30 positions but still I find it preferable to aggregating several in a single IM. It is rather trivial to separate a text string into 1024 bytes chunks but in my view not worth the effort. If a user were that busy that cannot wait for a minute for the IMs to complete, the user wouldn't have time to be playing SL in the first place As for formats, I use the following format for IM's: @<position identifier>@ <position>@<rotation> This outputs as: [timestamp] object name: @<position identifier>@ <position>@<rotation> When this is parsed back into the system, I make a list with "@" as separator. It is easy to see that the first list element indexed at 0 would include object name and timestamp so it is discarded and only elements indexed from 1 to 3 are further processed.

Another way to do it is to set two states in the script you want to start (script 2) from another script (script 1). The first state is default which does nothing except for waiting for a linked message from script 1. When received it goes to operations state where it actually does things. Script 2 may or may not acknowledge the starting msg. If synchronization between scrips 1 and 2 is required it should acknowledge and this technique works the best. If no sync is needed llSetScriptState() is preferable.

You're correct in principle but it is not as simple as it seems. Firstly a daily timer (86400) would introduce an increasing time deviation due to dilation which in a month or so may become quite significant. Experience shows that an hourly timer with dilation correction works the best. Secondly must have adjustment for sim being offline. Thirdly, both the llGetDate() and llGetTimestamp() return zulu time zone (UTC) so got to convert to a desired timezone because what's the 1st of the month in UTC is still last day of the previous month in for instance Pacific or may be already 2nd of the month in the Far East. I personally would've used unix time via llGetUnixTime() and convert to date from there (there are algorithms for unix time to a date in a specific timezone conversion on the web). All considered more than just a few lines of code may be required.

If on mainland, contact tech support to restart your region. If on private land, ask the sim owner to restart.

Your listen event is very badly coded. Rewrite like this: listen(integer channel, string name, key id, string message){ list data = llParseStringKeepNulls(message, ["|"], []); message = llList2String(data, 0); USERID = llList2String(data, 1); llSay(0, USERID); llSay(0, (string)llGetOwner()); if (channel != secretchannel) return; if (message == "request security") { llSetObjectName("SECURITY MENU"); llDialog(USERID,"\nSECURITY MENU:\n\n* you have 60 seconds to make a choice.\n* issue cmds within chatrange.\n* if only 1 person nearby they autotargetted.\n* doesnt work on yourself",order_buttons(buttons),secretchannel); llSetObjectName(housename); // llSetTimerEvent(60); ALWAYS LISTENING ANYWAY return; } if(message == "Eject") state eject; if(message == "TP Home") state tp_home; if(message == "Unsit") state unsit; if(message == "Cancel") state cancel; if(message != "Ban") return; if(llGetOwner() == (key)USERID) state ban; llSay(0, USERID); llSetObjectName("SECURITY"); llSay(0,"sorry this is a owner only function."); llSetObjectName(housename); state default; }

Why on earth do you need your objects to communicate by email??

Strife, I don't really like your proposed changes. It seems logical to firstly specify what a method returns (type) and then secondly what the returned value means in the content of the method.

In your application performance is the last thing I would worry about because it is not a real-time system. A real-time system is the one with timing constrains, that is a response to a signal must be received within a certain time interval. The real-time system in SL would be the one affecting viewer graphics. For instance if you make a moving vehicle like a car or a plane and your software responce latency is too large the movement would appear jerky on the user screen. In another example if you have a door opening on proximity you don't want a visitor to stand there for too long waiting until it opens. Your application involves no graphics and it does not really matter if a new visitor arrival is processed within 2 sec or 5 sec.

If com[piled in LSL-2, recompile as mono and see if the problem still occurs. If it does then Rolig's answer is a correct one.

There is no other way to send a menu window to user. You cannot change buttons size in the menu, it is hardcoded by Lindens. A menu button text is limited to 23 characters, if there is more llDialog() would fail and give an error on the debug channel. Out of 23 characters available only the first 11 will be displayed on the button, the rest is truncated. These limits are also hardcoded by Lindens and nothing one can do about it.

100 keys take 3600 bytes (100x36), with list overhead prolly would take 5K. An efficient script would need about 10K for processing, no more than that. If don't have 10K available, make another module that would do only large list storage/processing and talk to the main script via linked msgs.

What the heck is nonce and why do you need it? LOL Well really, using cryptography in talking to an SL object is like shooting sparrows with a cannon. It may be useful in communicating between SL objects and web sites but otherwise there's absolutely no need. Reading password from a notecard or receiving it via chat is rather trivial.

A bot is a text client, installable on your PC just like a regular SL viewer. It is simpler than a full-blown graphic viewer but if you are not an experienced C++/C# programmer you are not going to make one. Fortunately there are bots already made, available for free. Google Metabolt.