Zugg Software :: View topic - [1.18 - 1.19] new settings going to the wrong package

Posted: Sun Dec 03, 2006 12:50 pm

Finding that the ability to move settings from one class to another is absolutely fine now, i know you worked your butt off doing that Zugg.

Ive encountered a problem however.

If you create a new package, move settings over (working fine), and then go to create a new setting, in that new package, the setting appears in the old one. This first happened when i created a button in a new package, which was fine, then tried to add another state to it, which then appeared in the main package for that char. I then tried to create a class folder in another package, and that also went to the main char package.

Now, this ISN'T happening all the time, which is very strange, ive tried to boil down to the exact circumstances this happens, but I just cant recreate it when I WANT to see it happen.. so chances are, this is going to be hellish to track down unless you have an idea of why already.

Sorry to be a bit obscure, ill carry on trying to find out exactly how to make it happen over and over.

Posted: Sun Dec 03, 2006 3:00 pm

small update:

I have a trigger in a package that creates another trigger. this new triggers goes to the root rather than staying inside the package where it was intended to go. Doesnt stop it working, but I guess it should create in its parent pkg.

Posted: Sun Dec 03, 2006 3:25 pm

Do you definitely mean package there, crycry, or do you mean class? When you say "goes to the root" it sounds like it's been created in the root of the window/module that contains the trigger that creates the problem trigger. If it's creating it in a different package, that sounds kinda serious :|

Posted: Sun Dec 03, 2006 3:28 pm

yeah, going to the window module, rather than staying in the package whose trigger created it. sorry, im a bit blonde today haha

EDIT: This isnt happening all the time, so far Ive had it happen with triggers, but not alarm triggers, they behave as they should do.

Posted: Sun Dec 03, 2006 5:47 pm

So you have:

Package 1
->WindowOrModule1
---> Trigger1

Package 2
-> WindowOrModule1
--->Trigger 2

Where trigger 2 was created by trigger 1? That's very bizarre. I thought you meant

Package
->Window
--->Trigger 2
--->Class
----->Trigger 1

Where Trigger 1 created Trigger 2.

Posted: Sun Dec 03, 2006 5:59 pm

pretty much, Trigger 2 is going to the main package containing the main output window.. its a bit hit and miss, it doesnt do it all the time, which is odd.. im struggling to narrow it down.

On a positive note though.. ive messed about today ALOT moving classes into packages, settings from one package to another.. and its been PERFECT all the way through, no silly stutters, no crashes.. very well behaved.

My only other issue right now is buttons not doing what they should be, but i know Zuggs well on the case of that one.

Posted: Sun Dec 03, 2006 8:37 pm

odd, its now doing it with alarms.

package 1:
trigger 1 to create trigger 2 from captured data.

main module for window:
trigger 2 ends up here, not in package 1

Posted: Mon Dec 04, 2006 10:33 pm

Haven't been able to reproduce this one yet.

Posted: Mon Dec 04, 2006 10:53 pm

it seems very intermittent with me, had it a few times today. only when ive been working on a package and the setting has gone to the main module.. will keep taking notes, if i get anything different and more replicable, ill let you know.

Posted: Tue Dec 05, 2006 3:58 pm

okies, have a scenario that seems to be constant fail.

package 1:
trigger 1.. set to create alarm 1 on fire.

window module:
alarm 1 goes here, not to package 1.

This seems to happen without fail, as far as i can see.

Posted: Tue Dec 05, 2006 5:33 pm

That is actually correct. When a trigger runs, it runs in the context of a window (it's the window that receives the MUD text). So when the trigger fires and creates an alarm, then it's going to be created within the window that received the MUD text. So that's expected.

Posted: Tue Dec 05, 2006 5:36 pm

ah ok. thanks zugg.

Posted: Tue Dec 05, 2006 6:03 pm

there is a bug though with the alarms in a seperate package.

an %alarm( xxx) call in a seperte package cant seem to pull out the remaining time information unless i manually move the alarm back into the package where the call is being made from, where it works fine. both packages are available to eachother in the list.

edit: ok odd. i thought id just quickly try putting the alarm in another package, other than the main window module, and it works fine.. but when i drag it back to the main window module.. no go. just thought id add

Posted: Tue Dec 05, 2006 7:21 pm

That's because windows can never be published, settings in them are always visible only to other settings inside them. Would it be possible to define where the alarm is created using the //module/class/ syntax?

Posted: Tue Dec 05, 2006 7:23 pm

I guess the workaround would be to put the settings that pull out the data in the main module and not in the package itself, which, i feel is kinda defeating the object, but it would work however.. but it would mean that i cant publish the package

edit: on further thinking, ive gotton around it by making it a non onetime alarm and just suspending it when it fires. then, when i want to reset it, just use %alarm to reset it to the right remaining time. that way, i can stick it where i like and it stays there.

Posted: Tue Dec 05, 2006 10:35 pm

I think we have talked about this before. You can't have an alarm in a separate package. It needs some sort of window context to run in when it fires. For example, imagine an alarm that does "#show hello". When this alarm fires, what window should it display the text in? Alarms only make sense when they are associated with a window.

Also, if you think about Windows timers, a Windows timer needs to be associated with a particular window handle. A package doesn't have any window handle for the timer to use. Again, it needs a visible window so that it can use that handle for the Windows timer.

Actually, I just reread your post and I see that you are talking about the %alarm function. I'll leave my post since it explains some of the limitations with alarms, but I'm not sure it helps with your particular problem ;)

Posted: Tue Dec 05, 2006 10:43 pm

yeah my only issue is that the alarm function cant pull out the data, the actual alarm being located elsewhere isnt a worry to me as i wanted it to be fire once anyway.

i tried it my way as i stated, and made it recurring, it still fires the output to the main window ok and does what i wanted. is that a valid workaround? im a little confused cos it kinda goes against what you just said.