ID:1951862
 
Resolved
The "Automatically include FILE_DIR" option in build preferences used the user's global config option (which is meant to only affect new projects) rather than defaulting to false when no .int file was available for the project.
Applies to:Dream Maker
BYOND Version:508
Operating System:N/A
Web Browser:N/A
Status: Resolved (509.1307)

This issue has been resolved.
Currently, every time any user decides to start contributing code, one of the first questions they always ask is "Should I commit the dme?", to which someone then have to explain to the newbie that they have to turn "Automatically include FILE_DIR" off in Dream Maker. We don't need it or even allow it because it slows compilation down.

Unfortunately the setting to not include FILE_DIR is saved as a user preference when it should really be a project preference. Either the project needs it or it doesn't; there's no instance where user a will want it on but user b will want it off. All I'm asking is that it be saved to the .dme the same way DEBUG is so that we can turn it off once and for all and never have to bother with this instead of literally every single time anyone new uses DM for the first time.
I'll take a look into this.
Isn't this literally just moving the setting to the environment .int?
Baystation12 has the .int with an 'AUTO_FILE_DIR: OFF' setting. We also ensure people don't accidentally commit changes to it by failing CI builds where the md5sum doesn't match the "correct" version.

Would be nice to have both settings in the .int possible to have in the .dme instead, so we could just set the .int to be entirely ignored instead of trying to make sure it never changes.
oh ya, Mrp, this is saved in the .int file, that we .gitignore

Easy fix. we un-gitignore, commit a good version, then re-gitignore.

Edit: this doesn't work like I thought it would. there is no way to include a file in a git repo, but ignore all changes afterwards. meaning by default, unless you manually de-stage the file for commit, the info on opened tabs would get commited and would conflict with all other pending changes. We have enough new to git users for that to be an issue
My point still stands that this being a user setting instead of a project setting is ridiculous. So bump.
For a more general idea of what we are requesting:

There should be a file separation between things that might be universal to a project (like if file_dir is enabled) and things that should only apply to a given copy or user of the project (like what tabs are open)

Otherwise we can't change these per-project settings without having to worry about committing every change somebody makes to the opened tabs list, giving merge conflicts up the ass.

I'm mid-release on 509.1306 but I'll look into this soon.
I think I found the problem here, and IMO what we're looking at is actually a bug.

DM maintains two separate config settings for this. One of them is user-specific, which is used on new projects and is set any time you create a new project. (This is maker-auto-filedir in cfg/maker.txt.) I'm not sure that one's wrong. The other is project-specific, read from the internals. (AUTO_FILE_DIR in [project].int or [project].dme)

The bug is that when you read from an existing project, if the internal value isn't set, the user's existing global setting is used as the default--even though it should really only be the default for new projects. The actual default should be false.

So this makes perfect sense to me now. The problem only happens in projects where the .int is not committed to the repository.
Lummox JR resolved issue with message:
The "Automatically include FILE_DIR" option in build preferences used the user's global config option (which is meant to only affect new projects) rather than defaulting to false when no .int file was available for the project.
Thanks Lummox, this was causing problems