Sorry about falling off the radar there. Finals at school kind of took precedence.
I'm trying to figure out what the current state of affairs is now though. I know there are some bugs in the build code right now, and I am more than happy to help track them down. It seems Gurok has already caught on to the fact that AGS.Editor.Utilities.GetDirectoryFileLi
st isn't returning the values I thought it was, which is leading to some of the incorrect paths in the hard-linking code (however, I would suggest against using hard-coded directory separators, and instead use
Path.DirectorySeparatorChar Path.GetFileName).
Actually, the Editor simply does not copy engine binary to Compiled folder anymore (where it makes game with legacy compiler), hence the game is attached to empty file, or whichever file existed there previously.
I'll take a look at this. It might make sense to delete the Compiled folder when changing this setting, and of course the legacy code should still be copying the engine EXE as it was previously.
I really do not like the inconsistency between Linux and Windows builder classes. Linux builder takes every file from Compiled folder, while Windows one requires to have their names hard-coded. They should work same way. I'd say that probably even builder interface should be changed, because the copying/link of files is a universal operation.
I'm really not sure what you mean by this. Neither the BuildTargetDataFile class nor the BuildTargetWindows class reference any hard-coded paths or file names. As for copying/linking being a "universal" process, I suppose that I could add to the BuildTargetBase class to force the build targets to provide file name, file source path, file destination path, and destination mode (link or copy) for all required build files. Currently both Windows and Linux are parsing the Compiled directory's files directly, so it is only necessary to reference exact file names for platform-specific handling (which is currently only done by the Linux class as Windows doesn't require any platform-specific files). Assuming that the build targets could default some of these parameters, then I could perhaps see some merit to this.
Edit: I do see where the Windows build target is copying/linking the exact files referenced by the previously existing code, whereas Linux is just copying/linking any file from the Compiled directory. This is an inconsistency. Personally I feel that linking any arbitrary files the user has placed in the Compiled directory is a good feature for the end-user. This would allow game devs to put a single README file in the Compiled directory and have it perpetuated to the various platform folders (on build).
I mean that the list of game files should probably be provided by external user.
The entire purpose of having platform-specific classes is to provide the list of platform-specific files, and the platform-specific methods, to allow building that platform. I'm not sure how much further abstracted it could get than described above to where the build target classes tell the base class what files they need, where they need them, and whether to link or copy them.
If a dialog (or indeed other items i imagine) exceed the maximum allowed length then the new data writer throws "Can't resolve import dMyDialogWithALongName" but the old compiler gives the correct error message about the length.
Yes, it's probably worth running back through for error messages that weren't implemented. I was pulling source from dozens of different places, utility classes, subclasses, direct memory access, and so forth, so some of the error messages fell by the wayside as I was sorting out what was necessary to getting the data file in the correct format. These error messages could be nullified by removal of limits, but I should make sure that they respect any limits that still exist in the engine (where the compiled data file is read back in).
