ID:2540306
 
BYOND Version:513.1507
Operating System:Windows 7 Pro 64-bit
Web Browser:Chrome 79.0.3945.130
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
When you use CONTROL_FREAK_MACROS or CONTROL_FREAK_ALL, macros set on .dms files are ignored.

Numbered Steps to Reproduce Problem:
Set client.control_freak to CONTROL_FREAK_MACROS or CONTROL_FREAK_ALL
Define macros on a .dms file
Compile your environment including the .dms file
Try to use the macros you've defined
Fail


Expected Results:
Macros are run

Actual Results:
Macros are ignored

Does the problem occur:
Every time?? Yes
In other games? Yes
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur? Never


Workarounds: None

There is a workaround: define macros in the skin file.
In response to Lummox JR
There is no workaround for the .dms to work and still have control_freak on. There are workarounds that don't involve using them. But then there'd be a workaround for everything: just don't use the feature :p
DMS is deprecated. define your macros in the skin file.
In response to Ter13
So it won't get fixed?
Investigated further. Apparently the use-case for DMS is that there is no way to declare a macro in a library that gets included in the parent environment since you can only have one skin file.

In this case, I'd call this a bug.
The man made a good case. He convinced me.
Agreed that this looks like a legit bug rather than a case of deprecation. Once I have a test project to examine I'll get on it.
In response to Lummox JR
The real fix would be letting us use multiple dmf files in a single environment; just merge them together like maps, let the developers worry about conflicts.

Then we could have interface files just for macro sets and the sort.
In response to Nadrew
No, the real fix would be making it not disable .dms files. This is another issue.
The macro format of interface files is quite a lot easier to deal with, making it fill the niches where dms files are still used for them is a better long-term solution.

As an update on this bug, I discovered it's not as trivial a fix as I hoped. The problem is the same mechanism that loads .dms macros from the client script (compiled-in .dms) also loads old-style local macros, and can't differentiate between them because of how they're handled. So I need to make some more changes to make this work.