http://manual.3dgamestudio.net/

most engine functions will give you some sort of error message and most also have return types you could check before getting yourself deeper in to trouble ,but the errors usually will occur before you get the returned type, if it were a file loading problem .

There isn't really exception catching , but you do have the use of "if" clauses , use them , the engine won't know what to do unless you tell it what to do upon a catchable error , however I agree on some thing in a different point of view :

the development environment doesn't even mean $# because it doesn't really catch THAT much problems to even be of use ,in that regard SED as a debugger or development environment is not really much of anything in my opinion .

I don't know how the engine compiles the code because it does not compile to a exe during the development test runs so I cannot really say much more than ,it is different from other dev environments in that regards as it appears to me , maby it compiles to executable code internally and then runs in an internal process during the test run or whatever which makes it so much different from the published version ,but I wonder if it would have been better to have a debugable exe compiled and ran as it would on publishing ,well good thing I do not use sed/litec

moving on ...

shade-c was made by users for users , so it isn't really that it's a problem originated from the engine developers , however the normal path issues/difficulties seems like something we should not be having in this age and time .

The only error my log is showing is that some materials are undefined. Can anyone explain why this might happen? Whether I assign a material or not, the error always comes up.

I tried changing "D3D_automaterial" to 0, but the error still shows up. I have a feeling that this is not the cause of my problem, but it would be nice to rule it out for sure.

Oh, by the way, I'm not sure if you know this: You can create a log file for your published version if you add "-daig" to the end of the file name in a shortcut to the .exe file. This has helped me find some errors (but not all of them)

Maybe it is too late here, but my following experiences/practices in future could be useful for somebody. Some of them might be bad practices, but works safely for me. If you want to check them, you can get MapBuilder source:

- I try to keep folder structure the same for development and published project, for this purpose I use a project.wdl file that sets subfolders by PATH. This way the project remains organized, and you are independent of the compiler issues (e.g. runtime created entity stuff are not copied to CD folder, if their file name do not appear in your code, only in your custom save-map files).
- if you put your wmb level files in a subfolder, it will find all the other assets placed in more different folders thanks to the PATH settings, but you need to use unique file names, in the other case the 1st found will be used.
- I use my own file_exist function that really checks only the given path (called file_exists_onepath), because the engine function checks all the included folders. It can cause problems when more files have similar names in different subfolders.
- I use a project.wmb file loading on startup, which is an empty level, but sets nexus to a high enough value. I use it for publishing compilation from WED too (requires the main script file to be assigned). So after compilation I have to copy only the exe and dll files from the CD folder to project root folder, and then this whole new folder can be deleted.
- compiler warnings for long file names did not cause problems in my case, but Jcl said it cannot be guaranteed that the compiler will do its job perfectly, so safer to avoid long code and shader file names.
- if you customize the wmb compilation, more exactly when writing out the $$m temporary file, you can store more data in a wmb file.
- in general a custom map loading and closing function is very useful (e.g. to start and stop shader related loops safely).

checking files before loading anything , I think that is a good thing ,you can catch the problem before executing the rest of the application .

writing a file checker for your project and perhaps a little file searcher and copier ,that can find missing files and ask you if it may copy it to a folder (project folder) would be handy indeed .

Why? We paid for a working publish button, again. but yesterday i had this idea in mind too.

edit: Thanks 4 all replys btw. Sivan, thanks for your time and those great general tips.

well I wasn't actually talking to you at that time ,just had an idea about something .

sorry if it caused confusion.

No all is fine. ^^

To clear things, i dont want2 blame shadeC nor Acknex. Love both. Just saying if the project runs fine...Compiler should be able to grab all files, thats all.

totally agree , it's weird to say the least , that ^^; there is standard among development environments