ID:1597168
 
BYOND Version:506
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Chrome 35.0.1916.114
Applies to:Dream Seeker
Status: Verified

A member of our crack team of bug testers has verified that this issue is reproducible, and has handed it off to the development team for investigation.
Descriptive Problem Summary:
A winset() edit is persisting between sessions even when the code is removed, dream maker is restarted, the code is recompiled, the code is clean-compiled, the .dmb is deleted and then recompiled, or all of the above at once.

Additionally, the error seems to persist between entirely distinct projects, and has persisted in spite of computer reboots and byond open/closures. I only realized that it was not my fault when I realized the .dmf file in the sidebar was not ticked, and traced it back to the following.

Numbered Steps to Reproduce Problem:
Make an empty test project with the following code:
mob/Login()
..()
winset(src,"input","command=.test")
mob/verb/t(var/s as text)
set name = ".test"
src << "test: [s]"

Compile and run, enter random text into the default input bar to prove it works. Delete all the above code and recompile. Enter nonsense into the input bar and notice that is still trying to call the .test verb, in spite of removing the winset call.

Create a new test project, compile and run it without adding any code at all. Enter nonsense into the input bar and notice that it is still trying to call the .test verb.

Note that the same or similar effects happen if you use an alternate layout .dmf and a different control in the winset (input1, etc); however, it persists only between controls with the same name, eg, input1 will not inherit input .command, etc.

Expected Results:
winset() would observe default behavior when not called

Actual Results:
winset() alteration persists unusually.

Does the problem occur:
Every time? Or how often? Testing suggests every time
In other games? Works on dedicated test project
In other user accounts? Untested
On other computers? Untested

When does the problem NOT occur? When the name of the control differs
It occurred to try the .dmb files in Dream Daemon. The problem seems to persist there. I did not run the "infectious" first program from DD, but instead ran the version of the code that has neither the winset proc nor the .test verb, and the second, clean project. Both still gave the "Unknown verb: .test" error.

When I first tested it, it was running the .dmb directly from DM, without logging into BYOND. Running it from DD required logging in, so I can confirm that the change persists after logging in. I am not sure whether it is the .dmb/a compilation error, or something internal to this install of byond (a configuration/cache error?)
Have you tried deleting the saved.txt file located in your Documents\BYOND\skins\yourkey\yourhub directory?
The input control might have command in its saved-params.
I do not have a byond/skins/[mykey] directory, probably because it was a blank test project.

BYOND/skins/BYOND/saved.txt does indeed have the following:

mainwindow.input.command = ".test"

removing that line seems to remove the error. I don't know why the command attribute would be saved at all; I still consider the expected behavior to be as per default untill changed.
That means your skin has command in mainwindow.input.saved-params.
Yeah, I am going to take immense issue with this being considered 'not a bug'.

It is not a custom skin. I have not modified anything, in fact I only recently reinstalled my OS, wiping existing BYOND configuration. This is default, out of the box behavior, and one is to assume it occurs with any project that does not know to overwrite that setting.

It is inappropriate default behavior and should be changed.

If it is *not* default behavior, and some random thing I did caused it, then it should be cleared when a project is clean-compiled, or something to that effect. It makes no sense for that to persist.

To reiterate: I have done nothing except run a command, and that command is persisting between sessions. All you are saying is you know where the bug lies. I *have not changed the skin* or any of the files in that folder, and there is no reason why it should be there. It is not an error on my part, which makes it a bug.

I *have* compiled .dmf files into projects, but if the skin file does not get restored to sane defaults when the interface is recompiled, again, that is a bug.
Alright, I think I can say that it is not default behavior, because I think I have figured out which project's compilation caused it to happen.

However, I maintain that it necessarily needs to update the skin file if the compiled version is different.
Open the skin in notepad, or preferred text editor, and get rid of the "saved-params" line in mainwindow/input.
I figured that that was the workaround, yes.

Needing a workaround indicates that it is a bug.
I agree that this would be a bug, the default interface should not be saving parameters like this. However, using winset() on the default interface is unexpected by the system, there may be a legitimate backtwards compatibility (with games made pre-4.0) reason for that input to save its command.
The default skin saves input's command value for legacy purposes, because it uses the alt and chat buttons. Considering how far back that goes, it seems like a good idea for us to revisit this.

For now, I would recommend as a workaround that you just remove command from saved-params as you have.
Tom changed status to 'Verified'