#define issues part 1

ID:89485
 
Jan 9 2010, 11:26 pm (Edited on Jan 9 2010, 11:36 pm)
BYOND Version:462
Operating System:Windows XP Home
Web Browser:Firefox 3.0.17
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
Descriptive Problem Summary:
When loading a .dme file which has a comment immediately following an #include line (see example code), Dream Maker does not seem to be aware that the filename given in the #include line has ended, thinking the comment is part of the filename for some reason.
As a result, when such a file is loaded, it gives a message saying it'll remove the line. It does not actually remove the line, but I believe this is another, separate bug.

Numbered Steps to Reproduce Problem:
1. Write an #include in the .dme file, featuring a comment at the end, preferably outside the BEGIN_ and END_ blocks.
2. Save the .dme file.
3. Open the .dme file, either via Open Environment or Recent Environments.

Code Snippet (if applicable) to Reproduce Problem:
#include "Definitions.dm" //Should always be included before other files.
// BEGIN_INCLUDE
#include "Creatures.dm"
#include "Game.dm"
// END_INCLUDE


Expected Results:
For no message to be given, and the file to load (and compile) smoothly as if the comment line wasn't there.

Actual Results:
It gives a message saying it will remove the #include line with a comment, suggesting the comment is part of the filename. In the case of the example, the exact message is:
#included file 'Definitions.dm" \\Should always be included before other files' does not exist: removing

Does the problem occur:
Every time? Or how often? It occurs whenever the conditions are right - eg if a comment is on the same line as the #include, in a .dme file. Does not happen in .dm files.
In other games? Unknown. I assume it does, however.
In other user accounts? Unknown, but I do not believe user account is a variable contributing to this bug.
On other computers? Unknown.

When does the problem NOT occur?
When there's no comment on the #include line, or when the #include is in a .dm file instead of a .dme file.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Unknown. It occurred on 461 as well, however.

Workarounds:

Place comments before (or after) #include lines, rather than on the same line.
For example:
//Should always be included before other files.
#include "Definitions.dm"
// BEGIN_INCLUDE
#include "Creatures.dm"
#include "Game.dm"
// END_INCLUDE
Jan 10 2010, 6:52 am
I'll check this out Monday, but keep in mind manually changing the contents of the .dme is not recommended. If you want a file of definitions included before all others, my advice is to use an underscore in front. If that doesn't do the trick (it might not work the same with capitalized filenames; I always use lowercase), a character like ! or - will work since that has a lower ASCII value than any letter, and a number will work too.
Jan 10 2010, 3:17 pm
Lummox JR wrote:
I'll check this out Monday, but keep in mind manually changing the contents of the .dme is not recommended. If you want a file of definitions included before all others, my advice is to use an underscore in front. If that doesn't do the trick (it might not work the same with capitalized filenames; I always use lowercase), a character like ! or - will work since that has a lower ASCII value than any letter, and a number will work too.

Another glitch, that I did not specifically report, is that it seems to re-autoinclude any manual entries upon loading, eg in the above example code, it will turn into
//Should always be included before other files.
#include "Definitions.dm"
// BEGIN_INCLUDE
#include "Creatures.dm"
#include "Definitions.dm"
#include "Game.dm"
// END_INCLUDE

That's not too big of a deal though, since according to the documentation, it ignores any definitions after the first, and that lets you know it's included when you look at the files, so I don't know if it's a bug or a feature.

As for not being recommended - it actually does sort of recommend it in the reference, under #include. It says the only reason you'd want to do it is if the order is important, which it apparently is in the case of #define. Whether it SHOULD be recommended or not is a different story, of course.
Jan 11 2010, 10:01 am
It looks like the parsing done in the .dme is of a very simple nature, and overhauling it is probably more trouble than it's worth at this point. The best option is to avoid editing the .dme and simply use a filename starting with _ or - or a number to if you want to make sure that file goes first.
Jan 14 2010, 4:23 pm
You can't make a file compile before libraries that are checkbox-included that way, though.