the game files are actually hardcoded in the code

[BielBdeLuna]

one can't add new files to the scripting even if one includes the file with "#included" the new file gets ignored and the code doesn't result in failure (the "#included" function should return then an error isn't it?)

all the scripting files are hard-coded in a new function that doesn't appear in dhewm3: idFileSystemLocal::BuildOrderedStartupContainer() in the directory framework/FileSystem.cpp

it seems to create the "_orderer.resources" file, there seems to be the same problem with the defs, as if one mods the defs the changes doesn't seem to work

do you guys know if that function can be modified so it accepts any new file that is laying there connected with the rest of the scripting that gets actually included (so those script files that aren't #included don't get builded)

[BielBdeLuna]

I can confirm it happens the same with modified def files, new def files doesn't work either

I guess def files are read from the base folder not the fs_game folder?

[BielBdeLuna]

materials though isn't the same, I see my new textures defined in those new materials in game and those get builded in _Ordered.resources as well...

[BielBdeLuna]

why not compile the scripting and then store the compiled data in _ordered.resources so the compiler would already sorted out those files needed and those that don't?

[BielBdeLuna]

one generates a "_common.preload", a "_common.resources", and a "_ordered.resources" with the function "buildGame" in the console, but one has to be careful as it seems it can erase the original files, I guess "buildGame" uses the declarations (all kinds of declarations not only defs) available in the "fs_game" directory so, if you don't have anything relevant there, you could create those files without the relevant info which would make the game unplayable!

[BielBdeLuna]

_common.resources and _ordered.resources share a lot of files in common, they seem to be somewhat sort of the backbone of the game, with them you should have all the needed def scripts, materials, soundefs, newfonts, skins, fx, and afs that one need to create a mod.

they contain all the generalist functions, then other resources files that are specific per map load the resources specific per map, including the sounds, models and the textures.

_common.resources though seems to have more content than _ordered.resources, it contains more generated content as well as some pre-loadings for the maps, and the guis. This leads me to think that _common.resources is used in every instance of the game, even in every map in conjunction with the map's specific resources file, while that _ordered.resources might only be used when loading a mod. I don't know f this is actually true and why they chose this way of doing things.

I would find it more useful to have a _common.resources that contained whatever is important for a mod and a normal game, and a _common2.resources with the pre-loadings, the guis and the extra generated content for playing the game, so incrementally adding new needed info, if the system works how I described above is damn wasteful.

[BielBdeLuna]

extracting both _common.resources and _ordered.resources in a single folder and convining their resources together, then building those same files ( with the command "buildGame" ) ends up with new files that doesn't have the same size.

buildGame
Writing resource file _common
Writing resource file _common.resources

Writing resource file _ordered.resources
Writing resource file _ordered.resources
.

buildGame also generates a _common.preload (which actually comes form _common.resources, and it seems to be the first file written (the one without extension))

in Linux those files are generated in the .rbdoom3bfg/fs_game directory in home directory if one copies those three files to the real fs_game folder, one can play the mod as normally one would, without hitches, but if one substitutes the two files in the base folder ( _ordered.resources and _common.resources as there is no _common.preload in that folder ) by the three files or even by just the two of them. the game will not crash but will render wrong.

so some quick conclusions:

1 _common.resources and _ordered.resources, as well as the _common.preload get ignored in the fs_game folder

2 buildGame either doesn't work well or needs more content to work with (it might need all the content form resource files extracted and integrated in order to generate again all resource files )

3 if one could generate a working _common.resources and a _ordered.resources would he be able to use them from the fs_game folder? if not, then d3BFG can't do mods which sucks big time!

4 if one needs to extract all content, integrate it, add new files, hard-code one's additions files and then build new resources files. this makes moding BFG a pain in the ass, and an unnecessary one given how d3 used to work in it's old way of working, because the gains of a resource file are again?

[BielBdeLuna]

5 the best solution: if there is scripting or defs files or any kind of accepted declaration in the fs_game add the on top of whatever is in the resource files

6 another solution: if we have all the resource files extracted in a fs_game directory with our own addition, don't load any resource file and use all the non-binary stuff in the fs_game, that a solution one could settle easily

[RobertBeckebans]

The game files in a fs_game mod directory don't need to be in resource files. Simply use +set fs_resourceLoadPriority 0 +set fs_game

2014-09-30 10:45 GMT+02:00 Biel Bestué de Luna notifications@github.com:

5 the best solution: if there is scripting or defs files or any kind of accepted declaration in the fs_game add the on top of whatever is in the resource files

6 another solution: if we have all the resource files extracted in a fs_game directory with our own addition, don't load any resource file and use all the non-binary stuff in the fs_game, that a solution one could settle easily

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/169#issuecomment-57283835 .

[RobertBeckebans]

That should go into the README somewhere

2014-09-30 11:09 GMT+02:00 Robert Beckebans robert.beckebans@gmail.com:

The game files in a fs_game mod directory don't need to be in resource files. Simply use +set fs_resourceLoadPriority 0 +set fs_game

2014-09-30 10:45 GMT+02:00 Biel Bestué de Luna notifications@github.com:

5 the best solution: if there is scripting or defs files or any kind of accepted declaration in the fs_game add the on top of whatever is in the resource files

6 another solution: if we have all the resource files extracted in a fs_game directory with our own addition, don't load any resource file and use all the non-binary stuff in the fs_game, that a solution one could settle easily

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/169#issuecomment-57283835 .

[BielBdeLuna]

that's a big time saver!

[motorsep]

wow, someone should have used my mod launcher and saved a lot of time.

[BielBdeLuna]

wow, someone should have shared their knowledge, specially knowing that kind of problems, and then I could have considered using the mod launcher, and saved me a lot of time!

[motorsep]

That's what the launcher is there for - to use it. I am not sure why you are digging so deep into the code to get mods working. It's all in cvars/cmds. That's how I got mods running long before I made launcher.

[BielBdeLuna]

oh, now see it's still not on linux and proprietary, no, I prefer knowledge rather than something that might solve it ( or might not, I don't know, I can't test it ) it but it's a black box. but thanks anyway on the heads up Motorsep.

anyway, thanks Robert for the real knowledge, now it works!

[BielBdeLuna]

added a pull request

[BielBdeLuna]

added new commands that Motorsep e-mailed me

[BielBdeLuna]

4 days ago I made another commit with some more commands that Motorsep e-mailed me, it could be interesting to have them in the readme.txt also