Splitting Wood textures in two

[Fidcal]

Re: Hollow wood, didn't we decide that it would be way too much trouble to make the surface types try to reflect what's underneath that layer of surface and count on the mapper to apply those correctly and consistently every time? Squeaky board was kind of an exception, but I'm not enthusiastic about adding lots more surface types to try to represent wood under carpet, hollow space under wood, hollow space under stone, etc.

Seems very easy to me - less than one hour's work to divide wood into two types. Doesn't break any maps. Obvious to players. But it's actually far more work for me to get ideas across than actually implement them so I'll abandon the idea.

[Tels]

Seems very easy to me - less than one hour's work to divide wood into two types. Doesn't break any maps. Obvious to players. But it's actually far more work for me to get ideas across than actually implement them so I'll abandon the idea.

 

I am with Fidcal here, the general distinction "boards" and "solid wood" are useful. Hardest part will be deciding which material is which.

 

Also, when I return from my doctors appointment (ugh!) I'll have a look at coding a material types list into the extract-assets.pl and make it repprt what it encounters, and also cross-check it. That way we get a list of things we really used and then can whittle it down to what we really want to support. I'll also rewrite the wiki article.

[Fidcal]

You mean for the player or the mapper? The floorboards are all in tdm_wood_boards.mtr (under wood/boards in the editor) and other wood in tdm_wood_panels.mtr.

 

The wood def could be left as named wood and mean wood in general, solid wood and just create a single new def 'woodboards'. The new one imo should be equivalent [edit - in sound] to T2 wood which is fairly loud and the TDM wood be made slightly quieter. Ideally new sound files, one solid wood and one hollow sounding but the current wood might probably do just slightly quieter on solid wood.

 

~~~~~~~~~~~~~~

How can I tell high alert in T2? Can it even occur directly from sound? I made my guard blind so I can be sure he can't see me. If I jump up and down behind him he whirls round searching but isn't that just medium alert?

[Arcturus]

The floorboards are all in tdm_wood_boards.mtr (under wood/boards in the editor) and other wood in tdm_wood_panels.mtr.

 

That sounds like a good idea. Of course there's a little mess in the way textures were divided into those two categories, but that's a different thing.

Also wooden object should have different sound than boards (same for metal objects - try to stomp on a sword for example).

[Tels]

You mean for the player or the mapper? The floorboards are all in tdm_wood_boards.mtr (under wood/boards in the editor) and other wood in tdm_wood_panels.mtr.

 

The wood def could be left as named wood and mean wood in general, solid wood and just create a single new def 'woodboards'. The new one imo should be equivalent [edit - in sound] to T2 wood which is fairly loud and the TDM wood be made slightly quieter. Ideally new sound files, one solid wood and one hollow sounding but the current wood might probably do just slightly quieter on solid wood.

 

I think the problem here is that panels would be something on a wall/ceiling, so you will seldom walk on one, anyway.

 

However, the wood_boards.mtr contains both things that can be (thin) floorboards, and things that are used to texture large solid beams.

 

We probably need to split them up (also make it easier for mappers to select wood for a beam, currently sometimes you take a board texture and stretch it so it has no visible seems)

 

Edit: Can material definitions inherit from other defintions? Then we could baseclasses like with the entities to quickly change settings of a lot of material shaders.

[Ishtvan]

Also, when I return from my doctors appointment (ugh!) I'll have a look at coding a material types list into the extract-assets.pl and make it repprt what it encounters, and also cross-check it. That way we get a list of things we really used and then can whittle it down to what we really want to support. I'll also rewrite the wiki article.

Isn't it a little premature to say that our small handful of test maps have already used all the surface types that future FM authors will ever need? Or are we just talking about the SL release?

[Tels]

Isn't it a little premature to say that our small handful of test maps have already used all the surface types that future FM authors will ever need? Or are we just talking about the SL release?

 

We need to settle the list of surface types because:

 

* without a definite list, how can our script check that all material contain valid surface types (to distinguish between "starw" as a typo, and "straw" as the real one, you need to know that "straw" is valid, and everything else is not.

* we need to support the supported surfacetypes with sound propagation values. Anything that is not in the list won't have them, so the first time a mapper would use them, it would sound wrong, thus be buggy. So if we have a material with "twigs" as surfacetype, it currently wouldn't work because "twigs" have no proper sound propagation.

* we need to record sounds for the surface types (or reuse existing ones and have it sound slightly wrong)

* having too many surface types is also just confusing, if the player never knows wether the floor in front of him will be "wood", "solidwood", "aged_oak", "hollowwoodwithsplinters" etc. (exceptions are of course ok)

 

Unfortunately, these points above prevents "MyCoolNewSurfaceType" from getting pass in the checking script (and it will have the wrong sound propagation), but we can always add more _later_. Or the mapper can add them later.

 

The list isn't definitive in the sense that it will ever change, but it will be the official list that we implemented, tested and support. And we might add to it later.

 

Does that sound better?

 

(Quick question: The C++ code doesn't have a definite list, it is all in the def files, right? If the C++ code also has a list, it becomes more complicated)

[Springheel]

We need to settle the list of surface types because:

 

This list already exists. You can find it on the wiki. Someone gave you the link already.

[Tels]

This list already exists. You can find it on the wiki. Someone gave you the link already.

 

This list is outdated.(Or at least, it does not corrospond to what we define, use and have implemented)

[Ishtvan]

The list corresponds exactly to what we:

 

define: This list is the same as the definition in gameLocal.cpp

 

use: Do we use anything that's not on that list? We can't, because it wouldn't work.

 

have implemented: Once again, I refer you to my point I tried to make above that we don't have that many full-scale maps. It's not surprising that some surface types haven't been used yet. That does not mean they will never be used and should be deleted. The list was based on an exhaustive thread where asked everyone including FM authors what they might potentially want to use in the future, collected all those ideas, merged the similar ones and put down that list in a design document.

[Tels]

The list corresponds exactly to what we:

 

define: This list is the same as the definition in gameLocal.cpp

 

Ok I will add this list to my script and treat it as the master list (it makes sense that anything on that list doesnt work since it is not parsed)

 

use: Do we use anything that's not on that list? We can't, because it wouldn't work.

 

which is exactly my point. (nobody might know if we use something or not, because we dont have an automated way to check yet, or does the c++ code throw an error if it encounters something unknown?)

 

Edit: No, the code does not error out,because we have a "description" "armor_leather" in a material file

 

have implemented: Once again, I refer you to my point I tried to make above that we don't have that many full-scale maps. It's not surprising that some surface types haven't been used yet. That does not mean they will never be used and should be deleted. The list was based on an exhaustive thread where asked everyone including FM authors what they might potentially want to use in the future, collected all those ideas, merged the similar ones and put down that list in a design document.

 

I never said we must delete something from that list. I dont care how big the list is, or what is on it. All I care for is that we have a _definitive_ list of surface types.

 

Which we seem to have, so everything is peachy.