![]() This all means that LSL is not interpretative language (script). Even header files are linked automatically. Its joining your compiled code with functions from library (obj parts of lib) and producing exe or dll. ![]() Do you know what is linking (not SL primset linking, but programming language linking). Compilation and linking processed totally automatically. It only named script, actually its obvious C language, compile and linking able language. Many of the things you have suggested recently would be useful to have, but affect so few people that the chances of ever seeing them implemented are close to zero. There's little incentive to add all of the extra server functionality that would be necessary to make it have all of the debug capability that you may be accustomed to seeing in major languages like C++. LSL is a local scripting language that is not used outside of SL. Now I must manually fit them to correct location.Īnd it's very unlikely to happen. And in my case those values were coordinates where this door must locat. In my UR they communicate only after very first phase after rezzing and before PIN independent movement algorithm.When you put llOwnerSay, then script is compiled and reset and all previous values are lost. Rezzer script and PIN script communicate by some channel and only when this is necessary. ![]() This state stay unchanged while object is taken to inventory and put to rezzer. Example while PIN scripts initialization, your code save object coordinates to script state. Scripts, called PIN-s, you put into object, and then they initialize variables according to your written code. You, as script author, itself initialize them. The variables get initial values from your script when it initializes state. If that's the case, what's the problem with putting some llOwnerSays in the door scripts, putting them in the rezzer and rezzing things again, and seeing what you hear from the new door scripts when the rezzer sends them the values? Where are these variables getting their values from in the first place? Presumably they're not hard coded in any of the scripts in the doors, from what you say, so presumably the rezzer sends them to the doors when they rez. Also scaried maybe my script dont work anymore and I dont remember nothing how my own scritp worked, its the dark side of programming, oblivion, and this makes nuts. Altough I tested yesterday my UR rezzer and it seems still working without problems. Ok, those only doors and I can put them manually in place, but still strange.But your mentioned "If this object hasn't been rezzed for a very long time, there's a non-trivial probability that it contains something that's simply gone missing" is more scary, extremely scary. It was strange, 4 similar doors, 3 rezzed (altough I anyway cant get variables values), 1 door dont rezzed at all, no errors, nothing. With the Build Tool already open (Ctrl-3), dragging the object from Inventory to the ground, what happens? Nothing in the Build Tool? No error message at all? No "foosh" rezzing sound? There are still handles to them, but they don't in fact exist.īut I'm also unsure about exactly what happens when this object fails to rezz. If this object hasn't been rezzed for a very long time, there's a non-trivial probability that it contains something that's simply gone missing - I regularly stumble on ancient embedded assets that were erroneously garbage-collected over time. Until that object is rezzed, the script's state is not even present in memory on any simulator, but rather stored deep in some unstructured blob of database Inventory storage, so wading into that would require a debugging program that imitates the whole process of restoring a script state without actually restoring it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |