Automagical resources.lua

[FLOZi]

Adds all files in bitmaps/projectiletextures to resources["graphics"]["projectiletextures"] and all files in bitmaps/groundfx to resources["graphics"]["groundfx"]

use link in other post
(Many thanks to lurker for the RegExs)

Basically the point is that you no longer have to add each and every bitmap you use in CEGs into your resources.lua, just stick them in the corresponding subdirs.

Also it cleans up the adding of caustics/smoke/scars, (compare to the base file), speaking of which I'm sure a more competent lua coder could clean this up and add it to base file, so most mods would not even need to override it

[FLOZi]

Improvements, and many more thanks to lurker.

Will now add all files recursively under the projectiletextures and groundfx folders, so you can organise them more. e.g. bitmaps/projectiletextures/ARM/peewee_muzzleflash_front.tga, whilst being SVN safe (ignores .svn subdirectories and their contents)

edit: @ 03.15gmt fixed a bug with adding the default caustics/smoke/scars - but it turns out the engine adds them anyway, so you could just do away with that crap Which is awfully strange, as spring was crashing on me earlier today complaining about missing smoke textures. *aneurysm*

And again at 03.39gmt. Must not code when sleep deprived.

http://pastebin.com/f4e3c65cb

[Argh]

That is really excellent work, thanks for making that available- I'll test it out when I get the chance.

[Masse]

Very cool indeed

[trepan]

One more reason that: Lua kicks the TDF's ass!
(think -- WinAMP voice)

[SeanHeron]

Like I've said elsewhere: huzzah, and include this in springs base lua files!

[Forboding Angel]

can I use this in addition to my resources.tdf?

[FLOZi]

can I use this in addition to my resources.tdf?

No. Engine reads resources.lua only - Your resources.tdf is read by the resources.lua in base content. Obviously this one will override that one. I guess you could hack this one to parse the tdf too if you really wanted to.

[FLOZi]

Something worth considering, as next engine will break many mods, now may be a good time to introduce this and also sort existing base files into the folders so they don't have to have manually inserted. May as well cause all the breakage in one go.

Of course, it isn't really necessary for this. Just an idea.

[Forboding Angel]

Flozi, does this support subdirectories?

That is to say, does it read all the files from the directories below the one you are looking?

[zwzsg]

Will now add all files recursively under the projectiletextures and groundfx folders, so you can organise them more. e.g. bitmaps/projectiletextures/ARM/peewee_muzzleflash_front.tga

That means yes.

[Argh]

Works like a charm.

So... if every game used this, there would not be resources conflicts, correct?

[FLOZi]

Works like a charm.

So... if every game used this, there would not be resources conflicts, correct?

Resources conflicts?? How can one mod's resources.lua conflict with another?

[lurker]

I think he's referring to having hardcoded resources when using dependencies, because only the topmost version of a file is read.

[Argh]

Yes, that's exactly what I'm driving at. I want to make World Builder deployable as a map dependency, and I don't want it to conflict with games / mods that either have an existing resources tdf or which use their own resources.lua.

[Argh]

OK, I'm going to write a variant that will handle a RESOURCES.TDF. I can't eliminate conflicts with projects that use resources.lua, though.

[Argh]

Nevermind, I think that instead I'll do something else... meh, there's only so far I can push backwards compatibility.

[Pxtl]

Argh, I think this is a problem endemic to the engine (the fact that so many of these files are mutually exclusive) and not one I think you're going to solve today.

Fundamentally, all the mod files should be, by default, looking for addenda coming from maps and mutators, and overriding behavior instead of extending behaviour should be the exception, not the rule.

[Argh]

Yeah, I know- it's a fundamental design issue with this engine. I have been pecking at it for awhile, but this code was a real eye-opener for me- perhaps it can be dealt with by most games with a 5-minute alteration of their file structure (move stuff to folders) and even old games could be fixed very rapidly and re-released.

So I've written a rather lengthy post to FLOZi, begging for some additional help. What I think that we need to do (collectively, for once) is to get everybody on this standard for resources.lua, build a similar piece of code for sounds.lua, and that would eliminate 90% of the problems right there.

Then project content could be merged pretty easily, and World Builder could be a purely map-side level design tool, completely divorced from all dependency on other things. We could then fix all the jobjol projects, which would take somebody less time than it would take to download them.

[LordMuffe]

Could somebody explain me how to get this thing to work?

Preferably in a way that someone without any knowledge of LUA (me) can understand?

I added the linked file into my /gamedata folder, but it seems I miss something, because spring just acts like it would not have a resource file.