SS2 Four Hundred (400)

[6744afcd8669cACC]

My point about .INC and .MTL is simply that I'm not sure the engine's supposed to work this way (using parent-directory relatives path -- but well, it does anyway I suppose).

I've to finish a couple of things and fix a problem that occurs sometimes reading the PCX files, then i'll release it.

Cool

I see you use two tabs (one for the MTL file and one for the INC file), do you think you could use a system similar to the one in NotePad++ (where sections of code can be grouped and hidden)? That way, you could merge both MTL and INC in the same viewport (include the content of the INCLUDED file where the include line is, toggle the content when clicking on the INCLUDE function). That would ease readability, it would provide an extensive support for all included files and could certainly prove useful when trying to export redundant scripts to a common INC file...

[6744afcd8699dZylonBane]

My organizational approach for material files has been to create a "materials" folder at the same level as the other major resource folders (obj, snd, etc.), then create subfolders inside it, one for each material mod. For example if I had a mod that made all the windows shiny, I'd put it in "materials\windows". This folder would contain every resource pertaining to the material effect. If the effect is applied to multiple textures, I create the material as an INC file, then have each MTL file point back to it via relative pathing, so I can change the effect on all textures by editing a single file.

This approach reduces the chance of file/mod collisions, and avoids files and folders being spammed all over the resource root.

[6744afcd86da6grittymodder]

My point about .INC and .MTL is simply that I'm not sure the engine's supposed to work this way (using parent-directory relatives path -- but well, it does anyway I suppose).
Cool

I see you use two tabs (one for the MTL file and one for the INC file), do you think you could use a system similar to the one in NotePad++ (where sections of code can be grouped and hidden)? That way, you could merge both MTL and INC in the same viewport (include the content of the INCLUDED file where the include line is, toggle the content when clicking on the INCLUDE function). That would ease readability, it would provide an extensive support for all included files and could certainly prove useful when trying to export redundant scripts to a common INC file...

Yes, i can merge the 2 tabs in one and put a horizontal divider. The top section would be the MTL file editor, the bottom one the INC file editor. The first file has only one line so space is not an issue. Currently if one or the other file is missing an error icon shows in the tab. I'd place them in another way.
Seeing this kind of terrain textures i would have created the MTL/INC/PNG files inside the, for example, DataPermMods\Fam\Hydro_1 folder without spreading them all around. It seems to me that every texture is unique, or almost unique, so there are almost no files shared by more than one texture. At least if you recreate a texture for each old one. If you instead create a texture with multiple render passes probably you can use multiple textures (for example you have a base panel texture, than you have some details textures, you can create a texture without those details and another is those details without merging them in something like Photoshop)

[6744afcd871afZylonBane]

Seeing this kind of terrain textures i would have created the MTL/INC/PNG files inside the, for example, DataPermMods\Fam\Hydro_1 folder without spreading them all around.

What? No. No no no no no no. The FAM folder is supposed to be for terrain textures (and now MTL/INC files) only. Lord only knows what sort of havoc you're causing with the texture manager and resource loader by dumping material textures in there.

It seems to me that every texture is unique, or almost unique, so there are almost no files shared by more than one texture.

Errrhm... yes and no. Yes most textures are unique, but materials are often shared. That's why they're called, y'know, "materials". If all you're using MTL files for is to set a texture's scale, then sure, fine, just drop the MTL in there. But for effects that use render passes to composite additional bitmaps on top of the base texture, incidence maps, masks, etc, get those out of the FAM folder.

[6744afcd87a4aACC]

The top section would be the MTL file editor, the bottom one the INC file editor. The first file has only one line so space is not an issue.

Remember both file actually are the same exact thing, the same synthax and all. Also, an MTL file is meant to contain more than a single INCLUDE, I did it that way because I'm used to Quake III Arena and its shader system.

Seeing this kind of terrain textures i would have created the MTL/INC/PNG files inside the, for example, DataPermMods\Fam\Hydro_1 folder without spreading them all around.

When I began, I grouped textures by families, and noticed how many were actually identical, that's why I gathered every pictures together. I clearly admit it would be a good thing to move the unique textures in their respective directory now (so there would be no need for an MTL + INC, just an MTL)

If you instead create a texture with multiple render passes probably you can use multiple textures

I'm not sure that would be a good idea (it takes an extra rendering pass for every layer, it WILL affect game performances, and not just a little).

[6744afcd87b9cLarkSS]

@GrittyModder: Just thought I'd mention that I have spotted those screens you were remaking scattered around the FM RttUNN.

i.e.
Image: http://dl.dropbox.com/u/14248306/RttUNN.png

[6744afcd885c7grittymodder]

What? No. No no no no no no. The FAM folder is supposed to be for terrain textures (and now MTL/INC files) only. Lord only knows what sort of havoc you're causing with the texture manager and resource loader by dumping material textures in there.

Well, i am NOT doing that way, i say that in a mod system where each texture is ovverriden by a single texture/material i'd do that. Actually i'm just doing like ACC using the ACC folder to put the MTL and PNG files (or i can use another folder at the same level just to separate his files from mine, to not have the possible problem of files with same names being overwritten when merging things)

Errrhm... yes and no. Yes most textures are unique, but materials are often shared. That's why they're called, y'know, "materials". If all you're using MTL files for is to set a texture's scale, then sure, fine, just drop the MTL in there. But for effects that use render passes to composite additional bitmaps on top of the base texture, incidence maps, masks, etc, get those out of the FAM folder.

I understand the need to have a single material shared by more than one object/terrain but looking at the INC files of this terrain mod the 80% of the materials have just a different texture, and the MTL files use mostly one INC file. As i understand from your words and those last ones of ACC probably would be better to have a single INC file for terrain surfaces with no particular effects (no animations, etc) then just define the texture used in the MTL file directly. Would it possible to pass the terrain_scale and texture values to an INC file as parameters from the MTL one?
For example the most common material is like this

Code: [Select]

terrain_scale 128
render_material_only 1
render_pass
{
texture fam\acc\BlackOps03
shaded
}

If not possible the INC file would contain only shared parameters so

Code: [Select]

render_material_only 1
Don't know if it'd be useful to have this INC.. Anyways terrain materials seem simpler that what other things would need in the game, or it's just that the mod actually use simple materials for now?

Remember both file actually are the same exact thing, the same synthax and all. Also, an MTL file is meant to contain more than a single INCLUDE, I did it that way because I'm used to Quake III Arena and its shader system.
...

Now i understand better, so i can parse the MTL file and see the INC files and show them below the MTL editor somehow. If the material is specified in the MTL file directly there will be not INC files shown.
If needed i can add also a popup with a list of predefined materials or parameters that can be added in the script (ex. you click to a terrain_scale menu item and it adds "terrain_scale texture_dim" where the value texture_dim is read from the png file).

@GrittyModder: Just thought I'd mention that I have spotted those screens you were remaking scattered around the FM RttUNN.

OK, if they are used somewhere i'd release them. I need to finish just the last set (the one displayed in the image)

[6744afcd88a00ACC]

Just a very quick explanation of the MTL/INC stuff to clear this up (it's also about the "passing argument" point):

The engine loads a map, notice there's a texture on a surface, before loading the .PCX file, it checks for a .MTL file of the same name, located in the same directory. Then, loads the MTL file if it exists. The MTL file can contain the following code (note: the lines are numbered so you get what happend exactly):

FILE (MTL):

Code: [Select]

01 terrain_scale 64
02 ani_frames 1
03 render_material_only 1
04 render_pass
05 {
06 texture * 4 "picture_01"
07 ani_rate 200
08 shaded 0
09 }
Now, for whatever reason, you would like to share the rendering pass between several textures, so you may break the .MTL file in two parts:

FILE1 (MTL):

Code: [Select]

01 terrain_scale 64
02 ani_frames 1
03 render_material_only 1
FILE2 (MTL):

Code: [Select]

04 render_pass
05 {
06 texture * 4 "picture_01"
07 ani_rate 200
08 shaded 0
09 }
Somehow, you need to link those two files together; The engine can insert the content of a specified file into the current file, starting at the line where the include is. If you move the "include" statement to the top of the file, the lines will be read first, if you move the "include" statement to the bottom, the lines will be read last.

Code: [Select]

"include <file2>"
So you'll get:

FILE1 (MTL):

Code: [Select]

01 terrain_scale 64
02 ani_frames 1
03 render_material_only 1
04 include <file2>
FILE2 (MTL):

Code: [Select]

04 render_pass
05 {
06 texture * 4 "picture_01"
07 ani_rate 200
08 shaded 0
09 }
Wait, I got another texture that could use the same header, let's break FILE1 again:

FILE1 (MTL):

Code: [Select]

01 include <file0>
04 include <file2>
FILE0 (MTL):

Code: [Select]

01 terrain_scale 64
02 ani_frames 1
03 render_material_only 1
FILE2 (MTL):

Code: [Select]

04 render_pass
05 {
06 texture * 4 "picture_01"
07 ani_rate 200
08 shaded 0
09 }
It's the exact same script, except it's in three different files now. But how do I know I'm not going to screw everything up if I modify this or that material? Let's change the file extention!

FILE1 (MTL)
FILE0 (INC)
FILE2 (INC)

You could rename them whatever you want, I think I'd still work (I don't have the time to try right now, but I assume that would work).


Now, for the passing argument stuff: it is possible to use $TEXTURE as a placeholder for the picture name. $TEXTURE will be replaced by the original material file on runtime. If I get it right, it means that $TEXTURE referenced in "w_zoomba.mtl" would become "w_zoomba" (.png, .tga, .pcx). So it would be possible to do this:

TEXT1.MTL

Code: [Select]

terrain_scale 64
include DUMMY.INCTEXT2.MTL

Code: [Select]

terrain_scale 128
include DUMMY.INC   
DUMMY.INC

Code: [Select]

render_material_only 1
render_pass
{
texture $TEXTURE
shaded
}
illum_map 1.0 fam\lights\lightbulb
It would roughly translate as:
TEXT1.MTL

Code: [Select]

terrain_scale 64
render_material_only 1
render_pass
{
texture fam\text1
shaded
}
illum_map 1.0 fam\lights\lightbulb   
TEXT2.MTL

Code: [Select]

terrain_scale 128
render_material_only 1
render_pass
{
texture fam\text2
shaded
}
illum_map 1.0 fam\lights\lightbulb

[6744afcd88b3fgrittymodder]

i understand, it's like many programming languages work. are there any other predefined variables like $TEXTURE? Or better, is there any documentation about this language? So i can support it better

[6744afcd88eb8ZylonBane]

Look in the "docs" folder that the new patch creates. It's all in there. You specifically want the "material format" document.

Also, an MTL file is meant to contain more than a single INCLUDE

This is a silly thing to say. A MTL file is only "meant" to include whatever the author needs it to include to achieve the desired effect. All an INClude file is for is easily sharing the same effect across multiple textures.

As for "passing arguments", there's no such concept in the material system. INC files are, by everything I've observed, just blindly inserted into the MTL file at the point where the include statement is. Stuff like $TEXTURE should be thought of as an environment variable, not an argument or parameter.

[6744afcd89163ACC]

This is a silly thing to say. A MTL file is only "meant" to include whatever the author needs it to include to achieve the desired effect.

I mean "include more than this", as in "it's not just meant to be a single line starting with include"

[6744afcd89274ZylonBane]

Why not? Say you have a few dozen simple textures, rock or something, with exactly the same material effects. A MTL with only an include would be an ideal solution.

[6744afcd893bbgrittymodder]

I've completed a first version of the application. You can find it here

http://www.mediafire.com/?8y3uy7ewu15k7y7

There's a README.TXT that explains some relevant information.

Now you can see all the images used by a material that mod a texture, and also all the INC files used (if any, or just the MTL file).

If you include a INC file that not exists you can create it in the section where INC files are visible.

[6744afcd89551Kolya]

Since you have upload rights you could attach the program to your post above, but I would suggest to start a new topic for it here with just a bit of explanation and possibly a link back here and attach it there. In the end it will be worth it to have a dedicated thread for your program.

[6744afcd8965fgrittymodder]

I've created the thread here

Please report any problems and request there.

[6744afcd89922ACC]

I just tried this:

Code: [Select]

uv_mod VOFFSET_WAVE SAWTOOTH 0 0.0625 0 500
uv_mod UOFFSET_WAVE SAWTOOTH 0 0.0625 0 1000
rgb func WAVE SAWTOOTH 0.25 1 0 500

Everything seems to be syncing up exactly on-the-nose on my end, even with a second render_pass doing the same thing but backwards. If you still have code left over of when things weren't behaving correctly, I could try them out on my end if you'd like.

I tried again to move two layers at once and get them working together (binary screens), and it works. I have NO idea what I did wrong the first time. If I ever get the glitch again, I'll post it.

(new version uploaded; I don't remember what I added since last time)

[6744afcd89a10Marcelo]

Cool! Thanks ACC. 

[6744afcd89b59Salk]

Yep! Thank you very much for version 11 of your fantastic modification!

[6744afcd89c47Lambda 00]

Wow, this is really amazing.  Thanks so much for putting this up here!

[6744afcd89d93rccc]

What exactly has changed since version 10, ... in laymens terms? Also there's still a note in the first post that this uv_mod thingy won't work. I guess it's working now?

[6744afcd89e6dKyle873]

Excellent work ACC, keep it up!

[6744afcd8a0eeblaydes99]

Trying the latest texture pack #11 and loving it. Nice crisp textures and great use of environmental maps. I especially love the subtle environment maps used in hydrophonics.

[6744afcd8a396unn_atropos]

I know that this mod aims to stick to the original textures but...Today I noticed for the first time that there is no "0" on the keypads except when in Hack-Mode. (Noticed it when some guy in a lets play tried to type in 45100 on the acual world texture. It's funny to watch what strange things people do in this room. Wish I could remember how I got along in my very first play^^).
Maybe the keypad texture can be altered, so that there is a "0" and mabye also a "C"

[6744afcd8a485Alextended]

There is a 0 and C on my keypads just fine when using this and SHTUP.