|
kymon Novice
Joined: 29 Jan 2003 Posts: 40
|
Posted: Sat Dec 09, 2006 5:07 am
[1.22] trigger activation disables save button |
if a trigger gets activated by mud output while you are editing the script of the trigger, the "save changes" button gets disabled. closing and opening the package editor window reveals that the changes didn't get lost, but they are not active either. workaround: just type something, so "save changes" gets enabled again, and save.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Mon Dec 11, 2006 6:57 pm |
Quote: |
the changes didn't get lost, but they are not active either |
I don't know what you mean by that. Exactly which changes were not "active". If the trigger that you are editing fires, then any changes you have made should be saved. This is the downside of trying to edit data while you are "live". It is not recommended that you change triggers while they might be firing. |
|
|
|
Fang Xianfu GURU
Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
|
Posted: Mon Dec 11, 2006 7:03 pm |
He means that your changes don't affect any firings of the trigger after they're saved. To demonstrate:
copy "#echo pasted!" onto the clipboard.
Enter this:
#alarm 10 {#echo test}
#trig {test} {#echo fired!}
See that it fires once and you get the output:
test
fired!
Now, before it fires again edit the trigger and paste your second line in. Leave the package window at the front, do NOT save, and let the alarm set off the trigger again. You would expect:
test
fired!
pasted!
but you still recieve the same output as before. If you allow the trigger to fire again, it still doesn't give you "pasted!" even though your changes are saved. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Mon Dec 11, 2006 7:44 pm |
Hmm, that *is* wierd. Must be a cache somewhere not getting cleared. OK, added to bug list.
|
|
|
|
Seb Wizard
Joined: 14 Aug 2004 Posts: 1269
|
Posted: Mon Dec 11, 2006 8:09 pm |
Um, if I hadn't pressed save (or clicked on another setting in the Package Editor), I wouldn't expect "pasted!" to be echoed... However, I also wouldn't expect the Save button to get greyed out by the trigger firing. I wouldn't want the act of a trigger firing to cause the trigger to get saved as the trigger might not be in a state that will even compile, let alone be finished editing.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Mon Dec 11, 2006 8:44 pm |
Quote: |
I wouldn't want the act of a trigger firing to cause the trigger to get saved |
Unfortunately, that is unavoidable. When a trigger fires, it needs to update it's state in the database. This is like multiple users updating the same record in the database. To avoid losing your changes, CMUD saves any changes you have made in the editor at the same time that it saves the trigger state in the database.
As I said, this is the reason it's a bad idea to be editing triggers that are running. This could also cause problems in zMUD. In zMUD you can actually get corrupted settings from editing a trigger at exactly the wrong time when it fires. In CMUD you don't get data corruption, but it *does* cause your changes to get saved immediately.
So, the Save button is getting greyed out because your trigger has just been saved. The bug is that, as Fang posted, the saved changes are not taking effect. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Mon Dec 11, 2006 8:55 pm |
What I was able to do for v1.23 is fix this so that it doesn't happen with "normal" (non-multistate) triggers. The database was being updated to save the current trigger's state. The state of a trigger only matters for multistate triggers. So for single-state triggers, it no longer updates this field, so it doesn't need to save the database record.
Still not a good idea to edit "live" triggers, but it should work better. |
|
|
|
Seb Wizard
Joined: 14 Aug 2004 Posts: 1269
|
Posted: Mon Dec 11, 2006 10:58 pm |
Nice. And presumably there is a performance benefit from not updating the state on non-multistate triggers...
|
|
|
|
|
|