Jump to content
You are about to reply to a thread that has been inactive for 1178 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

No.

This is impossible with no-mod objects containing no-mod scripts.

If the object was mod, you could add a script with a link_message() event and llOwnerSay() the message. This will tell you nothing about whether the other script is working properly. 

Only if a script is mod, can you examine variables (by modifying the script to say variable values in chat).  Even if you do this, it could break the hud easily. (Changing the script resets it, which can break the hud depending on its design.)

Are you certain that you are not trying to use your hud in a “no-script” area?

Link to post
Share on other sites
1 hour ago, Ernesto Perez said:

One object with script dont want to rezz anymore and also cant wear to hud

You've tried this in another region, and it still fails?

What's the exact error message? I'm guessing it's something about "an object that has caused problems in this region" -- but if it's something else, it's possible the entire object was lost to the system, with just the asset handle left in Inventory.

Link to post
Share on other sites

Its my script. Yes, putting into it llOwnerSay() resets script. I cant do this, because it changes my variable. It was my previous version rezzer. I find out, 4 objects dont rezz. I take those objects. Then tried manually rezz. 3 of them rezzed, one even dont rezz. They are doors. Doors had also own script, plus my rezzbox scripts. I have no idea, but seems doors own script doed somthing there, scripts wasnt fit together. But this is not important. Important is - I have doors but I want to know doors coordinates (to put in castle, into right place). Those coordinates are written in script variable. How to get them without resetting script. In normal programming environment, source code editor shows also variables in sepatate window.  Example I put somewhere breakpoint and when debugged code stops, I can look into sepatare window what the variables are. Maybe there is some special additional tools for  LSL.    

Link to post
Share on other sites

Yes, probably its imossible to get those parameters. In newer version I specially for this writed channel listening command to say coordinates to chat.......But maybe there exist some additional tool. Example additional software to install into computer, that directly communicates with Linden SL server and shows those variables. Theoretically its possible.  

Edited by Ernesto Perez
Link to post
Share on other sites

That would be unfathomably complicated. 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.

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. There are still handles to them, but they don't in fact exist.

But I'm also unsure about exactly what happens when this object fails to rezz. 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?

Link to post
Share on other sites
41 minutes ago, Ernesto Perez said:

They are doors. Doors had also own script, plus my rezzbox scripts.

Something that did change, albeit a very long time ago, broke a very common door script that stored coordinates in object Description fields. (The change was to strictly constrain the length of that field, to counter some griefing.) That probably has nothing to do with this case -- it was very long ago -- but the "door" thing reminded me of that history.

Link to post
Share on other sites
7 minutes ago, Qie Niangao said:

That would be unfathomably complicated. 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.

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. There are still handles to them, but they don't in fact exist.

But I'm also unsure about exactly what happens when this object fails to rezz. 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?

It was strange, 4 similar doors, 3 rezzed (altough I anyway cant get variables values), 1 door dont rezzed at all, no errors, nothing. 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. I have lots of stuff not rezzed 6y.  Altough I tested yesterday my UR rezzer and it seems still working without problems. 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.

Link to post
Share on other sites

I'm a bit confused.   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.

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?

Link to post
Share on other sites
1 hour ago, Innula Zenovka said:

I'm a bit confused.   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.

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?

The variables get initial values from your script when it initializes state. You, as script author, itself initialize them. Scripts, called PIN-s, you put into object, and then they initialize variables according to your written code. Example while PIN scripts initialization, your code save object coordinates to script state. This state stay unchanged while object is taken to inventory and put to rezzer. Rezzer script and PIN script communicate by some channel and only when this is necessary. 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. And in my case those values were coordinates where this door must locat. Now I must manually fit them to correct location.

Link to post
Share on other sites

From what you say, after the doors are rezzed, something is telling them the coordinates to which they must move.  So if you if you put  llOwnerSay in either the existing doors or copies of them, and put these talking doors in the rezzer and rez them, you should hear the same message the rezzer sent to the previous set of doors, shouldn't you?

Link to post
Share on other sites
21 minutes ago, Innula Zenovka said:

From what you say, after the doors are rezzed, something is telling them the coordinates to which they must move.  So if you if you put  llOwnerSay in either the existing doors or copies of them, and put these talking doors in the rezzer and rez them, you should hear the same message the rezzer sent to the previous set of doors, shouldn't you?

Doors are not talking. I dont have nothing against talking doors..........but my point was - you cant modify source code without destroying variables. My case was exception, I hope rare, but if something happens, you just cant get those parameters without code modification and with code modification this information get anyway lost. There is space for further developing SL platform - example to add mouse right click option to script and "show all script state variables".  Its just SL server developing work and nothing more.   

Link to post
Share on other sites
2 hours ago, Ernesto Perez said:

Its just SL server developing work and nothing more.   

And it's very unlikely to happen. LSL is a local scripting language that is not used outside of SL.  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++.  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.  We learn to use the tools that we have.

Link to post
Share on other sites
14 minutes ago, Rolig Loon said:

And it's very unlikely to happen. LSL is a local scripting language that is not used outside of SL.  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++.  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.  We learn to use the tools that we have.

This is not actually true. LSL is not scripting language. It only named script, actually its obvious C language, compile and linking able language. It have own libraries and functions. Compilation and linking processed totally automatically. Do you know what is linking (not SL primset linking, but programming language linking). Its joining your compiled code with functions from library (obj parts of lib) and producing exe or dll. Even header files are linked automatically. This all means that LSL is not interpretative language (script). The advantage is faster speed and mode dynamic in code.......No, its not zero, I still hope after 10y this all is common feature......or after 50y when 10y is too short.   

Link to post
Share on other sites

We know all of these things. The bottom line is that this is not a forum for debating what might happen ten years from now in an alternative universe.  You wanted to know what is possible, and several people have told you.  Now it's time to get to work.  ¬¬

Link to post
Share on other sites

Sorry but I have to chime in because of the misinformed claim.

1 hour ago, Ernesto Perez said:

This is not actually true. LSL is not scripting language. It only named script, actually its obvious C language, compile and linking able language. It have own libraries and functions. Compilation and linking processed totally automatically. Do you know what is linking (not SL primset linking, but programming language linking). Its joining your compiled code with functions from library (obj parts of lib) and producing exe or dll. Even header files are linked automatically. This all means that LSL is not interpretative language (script). The advantage is faster speed and mode dynamic in code.......No, its not zero, I still hope after 10y this all is common feature......or after 50y when 10y is too short.   

Sims don't restart every time you compile and add a script to an object. No new EXEs or DLLs are being created so no linking is needed.

The script is compiled into bytecode which is then interpreted by the server as it's running uninterrupted.
That is the definition of scripting languages.

Edited by Wulfie Reanimator
Link to post
Share on other sites
4 minutes ago, Wulfie Reanimator said:

Sorry but I have to chime in because of the misinformed claim.

Sims don't restart every time you compile and a script to an object. No new EXEs or DLLs are being created so no linking is needed.

The script is compiled into bytecode which is then interpreted by the server as it's running uninterrupted.
That is the definition of scripting languages.

But no any scripted interpretative language dont need compilation. Bytecode? This is compilation. Its C language, only some restricted functionality compiler. Not all language rules apply. It depends from compiler. Sim restarting dont classify languages and yes, probably there isnt exe-s, but also this is platform dependent. Script means - no compilation. Compiled language (like C) - needed compilation. So, whitch it is then?

Link to post
Share on other sites
2 minutes ago, Ernesto Perez said:

But no any scripted interpretative language dont need compilation. Bytecode? This is compilation. Its C language, only some restricted functionality compiler. Not all language rules apply. It depends from compiler. Sim restarting dont classify languages and yes, probably there isnt exe-s, but also this is platform dependent. Script means - no compilation. Compiled language (like C) - needed compilation. So, whitch it is then?

All I have to say is that compiling alone doesn't disqualify something from being a scripting language.

Do some research, languages that are interpreted from bytecode are classified as "scripting languages."

  • Thanks 1
Link to post
Share on other sites
5 minutes ago, Wulfie Reanimator said:

All I have to say is that compiling alone doesn't disqualify something from being a scripting language.

Do some research, languages that are interpreted from bytecode are classified as "scripting languages."

Ok, seems you are right. When I learned code, definitions were others, but Im old man also.

Link to post
Share on other sites

It may be simply misleading that LSL looks a little like C, syntactically. It does not behave like C in many ways.

But that's not the main practical problem here, as I understand it. Rather, there's a script instance in an object that won't rez, and the objective is to find the value of variables in that script's state. This is vastly different from what a debugger can do, attaching to a running program image and mapping memory to the program source and symbols. Now, one can imagine that some similar mapping might be possible between the script and its state stored in a database blob somewhere, but again this is several levels of extra effort beyond a symbolic program debugger. For starters, there's not even a mechanism to point to a script inside an unrezzed Inventory object.

(Because this direction of attack seems so hopeless, I was trying to focus on figuring out why the object won't rez in the first place.)

Edited by Qie Niangao
  • Like 1
  • Haha 1
Link to post
Share on other sites
On 3/30/2018 at 4:20 AM, Berksey said:

If I were having this many problems with something I made, I'd just scrap it and start from scratch.

I usually get better results that way, anyway.

You get absolutely wrong. My Universal-Rezzer works perfectly. I was talked not about my product.

Link to post
Share on other sites

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. :)

  • Like 1
Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 1178 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...