*really* wish scripts would do a Script.scriptEnding when they are reloaded


#1


#2

Technical a problem to implement and give a HUGH overhead. because you need to monitor which script did rezz wich entity and coordinates etc. same for icons.

The scripter ! that is writing the script need to implement script.ending routings. The basic command is available. But i think there’s also a bug in High fidelity, because icones that are created wth a script are not removed. Or it’s not implemented in the script.


#3

The problem isn’t whether or not there are script.endings, the problem is script.ending is not called when a script is reloaded.


#4

Did a test with this script i made.

function scriptEnding() 
{
    print("Script stopped or reloaded.....");
}

print("Script start.....");
Script.scriptEnding.connect(scriptEnding);

It’s working for me, So i think in the script you use . it’s not programmed or have a bug to remove the created entitiy or icon or other thing in ScriptEnding. The script need to remember itself what it have placed and remove that in scriptending itself.

Not sure if the bug with icons on the hud is fixt, because on ride the icon is not getting removed from my screen. SO, maby scriptending only failing on HUD components.


#5

Maybe so! Also, this script is being executed from a zone entity on users entering the zone, so it doesn’t show up in running scripts. Another thing, it uses includes for the overlay as well so not sure which is the problem.

All scripts have a cleanup function for script.scriptending though so there is definitely a bug somewhere. My money would be on the zone entity script not firing off a scriptending.


#6

Just a guess, if your cleanup() is contained in the include script maybe thats why its not firing, have you tried combining the includes to see if it makes any difference? Or move the cleanup to the main script.
I have found includes dont always behave nicely. Which is why I asked for scripts to be able to close other scripts, and I use script start instead of include and close it when done, it doesnt cover all the possibilities but its a workaround.

Also I have found some issues with enterEntity and leaveEntity, like if you TP out of the zone or log off then leaveEntity doesnt fire and leaves the script thinking the avatar is still in the zone.


#7

Yes I have noticed that. It only works when you first enter. If you tp away then back it no longer works. The only solution is to keep it running but hidden, I guess (which is REALLY bad. Imagine somebody using this as a trojan to spy on you).

I am starting to think there will need to be some sort of antivirus scripts. Lol.


#8

I just tried making the cleanup section in the included script global and running it in the master script in cleanup(), and it still didnt work.

I also tried it using a non-forced script and I got the same results except in the non-forced script the overlays are nonresponsive while the forced script overlays retain responsiveness.


#9

This is just a guess but maybe the container variable linking to the overlay entities are being destroyed before the overlays themselves are being destroyed (in included scripts). I think the real problem is there is no really good way to manage overlay panels. I think what is needed is a API function that handles layering (currently we have no control of how overlays are layered except by what order they are created in the first place and they cannot be relayered on top of each other) and destruction. I really think overlays should autodestruct when a script has ended anyway, there is really no legitimate reason to have floating overlays left over from a non-running script.

I also noticed image overlays and text overlays work differently. If you have them grouped to move around together, they move differently, causing image overlays to slide away from the text overlays during movement (you can see this in the widgets example script).

Overlays clearly need more work.


#10

Are you explicitly deleting the overlay during the cleanup() ? because just shutting down the script that created the overlay wont remove the overlay, it will just stay on the screen and be unresponsive until relog.
You are right the overlay entity can be destroyed but the onscreen render remains and must be deleted separately.


#11

Yes I am deleting each overlay in both scripts. I did fix the nonforced script though (it was my own error), but the forced script will not delete the old overlays. If you try “stop all scripts” on a forced script it will not end the script, so I am thinking that script.ending also will not work during a reload.


#12

Here is a test script I wrote. Attach this to a zone entity, enter the zone and try reloading it a few times. The background is .1 alpha, so the more you refresh it the less transparent it will become (because it will not be deleting the old overlays). If you leave the domain it will clear the panels because script.stop is called in Window.domainChanged.connect.


#13

Here is another script that gives unexpected results. Just run it in script editor and try reloading it a few times. It only hits scriptEnding one time, after that it no longer works.

I added this to worklist here


#14

Well, I don’t know, if Mac and PC dos work in the same way. But for me reloading fully doesn’t stop the script. The old script runs and the new script is only loaded in the script editor. I must stop the script in the script editor and start it again, to get the new script running.


#15

Well, i expect there’s still a bug around @thoys possible knows more about it. because RIDE keeps showing the icon still after stopping the script the hud still hud icon still show.


#16

Well I remove all my Buttons in the ScriptEnding function with:
Overlays.deleteOverlay(Button);

And if I stop a script, they are really gone.


#17

Totally confirmed, reload does not trigger script ending.

I know this is not a real solution but a temp hack (your name suggests you will like that), and you probably already know of this solution, but I offer it anyway because this is how I managed my overlays because the onscreen render is so easily orphaned. I check the said spot and clear it at the start of the script, so each time it is reloaded it cleans up old overlays.

(function()
 {
    var posx = 300;
    var posy = 100;
    var oldOverlay = Overlays.getOverlayAtPoint({x: posx, y: posy});
    Overlays.deleteOverlay(oldOverlay);
     var black = { red: 0, green:0, blue:0};
     var white = { red: 255, green: 255, blue:255};
     var window = [];

function newWindow(posx,posy)
     {
         var elements = [];

var element = Overlays.addOverlay(“text”, {
             bounds: { x: posx, y: posy, width: 300, height: 120},
             backgroundColor: white,
             color: white,
             backgroundAlpha: .1,
             text: “\n  This is a test panel”,
             alpha: 1
         });
         window.push(element);

}
     function cleanup() {
         closeWindow(window);
     }
     function closeWindow(window)
     {
         for(var i = 0; i < window.length; i++)
             Overlays.deleteOverlay(window[i]);
     }

Script.scriptEnding.connect(cleanup);
     Window.domainChanged.connect(function()
                                  {
                                      Script.stop();
                                  });
     newWindow(posx, posy);
 })

This mod presumes there is only one old overlay at that point, if there are several you will need to loop.

Not a permanent solution but an effective workaround. Unless you spawn overlays at various places then it might become more involved.


#18

Hah good idea :smiley:

I think this would be a good solution. I really don’t see that floating leftover overlays could ever be useful to anybody, so they should automatically delete when a script is closed. It’s stupid to require manual deletion of them.

If for some reason people feel like they really really need overlays to be left unmanaged then perhaps an Overlays.oncreate event could be added instead.

My main concern is whether or not it is JUST overlays. What other memory leaks do we have lurking around in script that we can’t see?


#19

Bumping this as long is it is still an issue.


#20

I noticed this causes a huge memory leak since script includes are not freed, or at least that’s what it looks like. Something is not being freed and eventually when restarting scripts a memory leak of some kind is revealed.