Zugg Software :: View topic

Posted: Tue Dec 26, 2006 2:31 pm

If you import multi-state triggers, they set priorities correctly (which i'm really liking btw, now you just need to make a compress priorities and expand priorities function) but they display in the pretty little tree-view in the wrong order until you drag them back into their parent trigger

Posted: Tue Dec 26, 2006 6:50 pm

I'm not sure wha tyou mean by compress and expand function. If you sort the package editor by priority you see them listed. Is that what you're looking for? Or do you mean something else?

Posted: Tue Dec 26, 2006 7:38 pm

At the moment, the priorities are automatically incremented by 10 each time you create a new func or whatever
a compress function would remove all the unused numbers between them, so your maximum (read lowest) priority would go from 1230 down to 123, and an expand function would pad the numbers, either by 1 each time used, or by a variable amount chosen when you run it, so 1|2|3|4|5 would then become 1|3|5|7|9 which leaves room to put functions in between without adjusting large blocks manually

Trust me, if it can be done, it will be used

Posted: Tue Dec 26, 2006 8:19 pm

That's a very good idea alluran. I think the compress function should be settable as well. Even better would be %setpriorityspacing(2) which would change 1|2|3|26|52 to 1|3|5|7|9.

Though how would you choose which settings to change? If there was a class parameter for the function and you compressed the space between priorities to nothing, for example, and then you did the same to another class completely independently. It'd result in more than one setting with the same priority, which isn't good.

Perhaps there could be an %addpriority function, too, which would just add a set number. Then you could compress both classes and then add a number to the second class. There could also be a function that just returns the priority of a given trigger, so you could then do %addpriority(%getpriority(setting),classname) to keep the priority numbers close together but not identical.

This might be too much complexity for something that really doesn't need changing - making priority numbers closer together isn't actually needed in any situation I can think of except for making something pretty. In that situation the %setpriorityspacing function would be better though, I think. Adding spacing or adding a fixed value to priority numbers en masse definitely has some applications, though.

Posted: Tue Dec 26, 2006 8:40 pm

i meant more of a manual thing, done in the package editor, not so much something we'd script. Basically, you'd run it once you'd finished a release for a script, so it only took up priorities from 1-100 say, and then when someone else downloads it, there's less chance for priority conflicts. Also, the ability to globally increase the starting priority on a single package would be useful too, so once compressed down to this 100 priorities, you could then order your package priorities too.

It all makes sense in my mind :\ tricky part is expressing what i mean :)
But atm, it worries me to see priorities blowing out to 1740 etc when i've only ported 1 or 2 scripts across, and from what i can see, it isn't reusing old priorities atm.

Posted: Wed Dec 27, 2006 9:40 pm

I think the take on this would probably be something like "Why does that matter?". It seems to be creating an awful lot of complexity for something that really doesn't need it. People compressing their priorities, as I say, could very easily result in matching priority numbers, as I explained. People using this would have to understand why that's a bad thing, and if it's going to create problems like that, why bother changing it? What's the point?

Equally, though, I think there is an issue here - if having identical priority numbers is so bad, what happens when you start using packages from the library? It's bound to happen eventually. There needs to be a way around it.

Posted: Thu Dec 28, 2006 1:45 am

I tend to agree with you Fang... I don't see why we'd want to 'compress' the priority numbers.

There's nothing necessarily wrong with having two items with the seem priority.. they will both executed. The drawback is that you can not determine what order those items (at that particular priority number) will be executed in.

For most folks this won't matter anyway, for others it will.

Posted: Thu Dec 28, 2006 2:43 am

You just know if it doesn't get done, then people like me are going to go through and painstakingly do this themselves dont you >:) hell, i might make a program that does it to exported xml files

Posted: Thu Dec 28, 2006 3:06 pm

But... why? What's the point?

Perhaps some kind of batch priority setting would be useful, though... say you create many triggers and then decide you want to order them into priority sets by class to make one script always execute before another. It'd take a long time to sort out manually, I suppose.