Secondly, I crashed it while adding a new command to a macro. Below is the memory and stack dump. It looks like it died inside a vector object while inserting a new command into the vector for the macro. So far I haven't managed to duplicate it. Does not initially appear to be related to either the number of macros or the number of commands in a macro.
...
Edit: Crashed it again, same place. Have not noticed a pattern yet but it seems to happen only after I've been mucking with the macro system for a bit.
Sadly I can't tell anything from that crash dump. I do have one guess and will see if I can find anyway to make it crash.
Also, if they are not already in your plans there are three features that I would very much love to see.
The ability to name the macro.
The ability to Delete(!) a macro.
The ability to alter the position of commands in the macro.
(Had to delete half a macro because I missed a command.)
They are all in the plans. Currently you can do all 3 by editting the interface.txt. The naming is an optional field on both macros and key bindings. For example [BIND:SELECT:Do the highlighted thing]
Also I would suggest that if you have large complex macros you take advantage of macros being able to run macros, and split the large macro apart.
Edit #2: Just noticed that the scan keys I had saved for my macros did not cleanly load. I was using shift+ctrl+# Where # was 1-4 for the four macros I had saved. The value showing for the key binding on load for all four macro's is Ctrl+None
I will look into this.
Two minor issues:
- One, holding down shift to make the cursor move faster doesn't work on the number pad when number lock is on. Not exactly a big deal but you were able to do so as recently as d11.
I can't change that for the default interface settings. It is an OS level thing to convert the Shift+Numpad# sequences to a number character. The default interface.txt binds the number characters to support laptops and other systems without a number pad. If you remove the bindings that say '1', '2', '3', etc. Then the 'Numpad #' bindings will get full control in both Numlock states, and they will detect the usage of shift without OS interference.
- Two, the keyboard shortcuts still aren't totally working. In particular, I've used "shift +" and "shift -" forever, but even though it looks like you can set in the binding menu using "Add Scan Key," it doesn't actually work.
I think you will have to be more specific about what you think is wrong. I somewhat baffled as to your meaning.