Eve Neutron

Well, it turns out that all the big and great are doing the same. Maintaining an index is not hard. But when there's a need to run around between the inventory index and notecard lines, it becomes a bit complicated. And script grows alot. My lite v6 HUDs holds index. But the full ones with notecards don't, it's alot more complicated. But I'll do it and test to see how it goes.

Thank you, that was exactly my question . So I got an answer finally. Currently today, all the HUDs I know does the same. I think I will change my scripts to work by index/notecard line instead of a list. Not an easy task, but preferable I want as less lag as possible. So thanks alot

i understand, but, i dont think people like too much setup. and setting up a notecard can be a bit of work. i started doing changes to save only index of inventory, but when i reached notecards i saw the script will be too big. currently with a list, i checked with 300 animations and it worked fine and fast. i know it will reflect on sim memory, but calling dataserver events can cause lag too, 64K is not really so bad. and amount of dancers doesnt affect my memory consumption. the only affect is the core script that hold the list of animations. there can be 100 people on a sim, and lets say they all have my hud. so the animation list script will take 6400K which it 6.4M of memory. thats not alot of course the hud is not 64K there is much more than one script. but the only breathing script, in terms of memory will be the core.

Good point, I shall try that. Thanks alot.

You got me wrong, notecards are not for friendlier names. They are for making playlists.

My thought exactly and I started out with this implementation until I reached notecards. And than I thought no problem, in notecard I can go to specific line. And than I started reading, and noticed that each llgetnotecardline causes a sleep of 0.1 and calls dataserver. So it may cause more lag and lack of performance when trying to display a page of animations. Especially if someone decides to play with it. Also, my question was about the dataserver, is calling a data server event better than holding a list. An I still don't have an answer for that. My lite HUDs V6 have that mechanism exactly. It consumes very low memory. But when notecards are involved it seems more complicated and problematic. Especially that sleep issue. If you are in a laggy place and I will try to retrieve 10 animations there will be at least 1 sec of delay. At least.

That's what I thought too, I think I'll stick to the lists. Thank you so much for the answers

what about the load of dataserver events on the server? will it cause more lag? or less lag? when comparing to a list of course

dirst of all, thank you so much for answering so quickly but i already know the trade off between memory and performance when speaking of notecards. i would like to add more info, maybe it will help its a dance hud ive been selling for years. i want to make it better. currently its using a list of all dances. i tested with 300 dances, it worked fine. but im worried that someday somone will be eager to test my hud and put more dances, and i dont know how much it will hold. a list of 300 strings is alot. so i compile it on mono, but still. i thought it will be better if, for every request for "NEXT" or "PREVIOUS" i will read straight from notecard line with dataserver event. and than i will not have the use for a list. the script will be lighter, the question is: will calling multiple dataserver events cause more load on the server than a big list of strings? and will i have glitches? for this i know now, that the answer is maybe, first because of bugs, second, because of dataserver is asynchronous. thank you

ive tried them all, lsl plus for eclipse is the best, no doubt about it. the installation and debugging might be a bit complicated, but its worth the trouble. it has good autocomplete for functions, constants and events.

you should give the prim with script inside a name.

you can move in a loop until you reach target, everytime, you will take your current position and add 60m that will solve your problem.

or, you can get current position, calculate a new vector of the destination, and use llMoveToTarget() this is smooth, but, door must not be linked !

you can use llSleep() inside a loopso it will move slower.

of course, but you cannot go over inventory with lsl. you must consider changing the scripts so it wont need attachement.