No pressure or anything Nick, just been looking at release notes and wondering if you have an ETA on vers 3.33 and also if it will include changes to aliases in line with existing trigger properties (in particular if you can send direct to variables rather than using a separate script to set them)
cheers :)
Another thing along the same lines.. I have a bunch of variables where 2 triggers for each variable sets the staus of that variable to either 'on' or 'off'. However, using triggers to send to variable requires putting the variable name as the trigger label, and of course because you cannot currently have 2 triggers with the same label, this again neccessitates having one of each 'pair' of triggers call a sub-routine script instead. This may also cause the same work around if aliases allow sending direct to variables too in the future.
Now I know you can't possibly allow 2 triggers to share the same label as this will cause all sorts of problems with other scripts that enable/disable triggers. As a suggestion, would it be feasible to instead create a new field for the variable name so that multiple triggers (and aliases one day too I hope) can send direct to the same variable without needing to script a separate sub-routine for 1 of them?
It's not a biggie since the sub-routine method works fine at the moment, but it would make things a lot cleaner imho.
I am now in the difficult position where I have done a lot of work to implement custom keymapping (eg. so you can make Ctrl+T be "take", or run script "OnTake", or even disconnect the MUD). However it is a big job, bigger than I expected because of the problems with multiple contexts. eg. if there is no world open then certain keys still need to do things (eg. Shift+Ctrl+C for quick connect), so they can hardly be stored in the world file, as there is no world open.
I also wanted to move away from storing things in the Registry, so it is now a project to move global settings from the Registry, do custom keymaps, and allow for overrides (eg. if a particular key will be the same in all worlds you don't want to have to enter it every time).
This won't be finished for a while, certainly not by Christmas, so the other, more minor, things need to be deferred a bit.
I would suggest, late February for the next version. Sorry it can't be sooner.
any update on 3.33 ETA yet, or am I better off to d/l 3.32 and start rewriting script now for trigger groups etc? (ie is it at least a week or more away).
Sorry again for nagging, just keen to make these changes to my script.
I'm working on it right now, and my mind is boggling looking at Neva's colourtell problem. It seems to be related to recursive calls to the display routine but I'm not sure exactly how. If I don't go insane first, it should be today or tomorrow. ;)
re the colour tells, I've found that if you're doing a series of mixed colour tells in one line like that, the last one in the 'series' needs to be a World.ColourNote, the previous ones all scripted as World.ColorTell. It appears that the same applies if you're doing 2 separate routines where there is no activity between them being run, if that makes sense. Try that.
p.s. I'd loan you a straight jacket, but it's in use. :)
Awesome thanks Nick, been testing out 3.33 and it's all good :)
If I had to make a suggestion, the only thing I miss is when I have an alias that sets a variable, my input (what I'm typing) is not echoed in the display, whether omit from output is selected ot not. Not a major but it's good to check if I mistyped the variable :)
Excellent thanks Nick, omit from output works great now on alias sent to var. :)
wow.. I've only just really begun to rewrite my scripts and already I've managed to take out a huge chunk of the mile long list of subroutines. Happiness filled.