Dear WindBlower
Thank you for this link!

@ Numenor: maybe I'm just blind and something like that already exists but may I suggest that an overview over the Material Definition (TXMT) can be added to the Modding Info Center? (= a list of the entries, a quick 'translation' of the name of this entry and the range of allowed entries, would be great when even their min/max value behaviour/effect in game can be included to this info)
I know it's quite a lot of work and yepp, I already found the wiki entries but they could be re-written in a clearer list or table for an easy quick access while editing the TXMTs (I think).
As neither JWoods nor you did this so far I suppose that you two thought this wouldn't be necessary - if you do so, well I could write as much as I can (= found so far) as it would be useful at least for me myself to prepare this list/table and you would only have to check for mistakes and add missing so far known entries and, last not least, upload it to a tutorial thread or even the Modding Info Center if you want. If I'm the only one who could need this overview I write it only for me and post it just in The Material Definition ("TXMT", a.k.a. "MATD") just for the case someone might want to take a look at my quoting skills...
Of course I would never say that anything of this text is found out by me but even quoting needs some research and that's why I immediately offer to help while posting this suggestion.
What do you say? Would this be useful enough to be posted in the TXMT-thread or even added to the Info Center?

@blake_boy: nice I could help :D

The reason why I didn't create an InfoCenter article about the TXMT is not because we think its useless; on the contrary, the main problem is that the Material Definition is a *huge* subject, and collecting all the data in a single article is a hard job.
But of course, if we never start it, we'll never finish it

If you are willing to gather the info you have collected by yourself, and the ones taken from this thread, and create a draft of an article, I'll be glad to check and integrate it, and then post it in the InfoCenter (since JWoods is no longer available, I'm the only one that can post in the InfoCenter forum).

Khaibit & Numenor,

May I join if it's good, or probably we can start a thread for collection of open inputs or reuse this thread and openly ask for more inputs?
I've had this thought for a long long time now.
As Numenor has said, txmt is really a HUGE subject...and I can assure you that is no kidding. There're many not well discussed txmt properties and types, even just the ones based on the base game. Be prepared, it's gonna be a "lot" of works... We may ask for more people to join in.

Or, we can have a general standard txmt properties discussion first, then the rest one by one gradually. I kinda doubt everything can be kicked out without compartmentalisation/ segmentation/ chopping/ sub-categorisation unless we're crazy enough... and the resultant post or thread is gonna be really long like a research journal paper if I'm allowed to say so. (At least, that's how I vision it.)

I just checked the wiki http://old_wiki.modthesims2.com/49596978
If those're the only listed ones in wiki, then they're just the aerial part of an iceberg.

txmt is unnecessary to have to deal with material properties all the times despite most of the cases I've found so thus far. In other words, txmt is like a collection file for graphical parameters including materials and others.

When txmt is touched, I tend to think that material shaders have to be discussed as well. This is also a "big" "highly related" subject coz many txmt types and properties are predefined in material shaders...

To tell you all the truth about my understanding so far, there're many of them I still don't know how to properly use yet.
Guess, we may need some Maxoids or people from different fields to gather infos and/or explain some of the most puzzling ones...

So, the most pragmatic approach for the whole overall things I see of is to have a collection thread like this to gather different data and experiences from various people first.
But if a list of general standard txmt properties is so wanted more, it's quite easy to do actually.

May check out this post

Niol (and Khaibit ), I don't think that we need a thread like this to collect info, because this thread has benn online enough to collect valuable data; and we ourselves, in the meantime, have experimented and increased our comprehension of the MATD.

The info in the Wiki are very old and somehow inaccurate (for instance, there is confusion between reflectivity and actual reflections).

My personal guideline, in the last year, was a file created by an unknown user: when the base game came out, he was so crazy (and kind) to create a small program to scan all the existing MATD in the base game, and extracting the values that the various parameter had.
Then, he compiled a list, grouping them by material type ("StandardMaterial", "BaseTextureMaterial", ecc...).

I don't know if I ever posted this file on the forum, but anyway you wil find it attached to this post. Inside the rar there is also an Excel sheet, where I started categorizing and organizing the data, but I never finished my job :P

I think that the subdivision by material type is a good approach, also because will let us to keep separated types related to objects, types related to skin, to floors, to wallpapers etc.

I think that we can't exceed in the info, and we shouldn't, at the moment, include info about the shaders: the subject is already too complex and we risk to abandon it once more, if the work to do is too much.

Also, we should keep in mind that people will come to read our notes in search of info on a specific subject (for instance, how to add reflectivity or transparency to a piece of furniture), and therefore we shouldn't ovewhelm the readers with tons of info.

That said, welcome aboard to everyone want to give his contribute! As Khaibit has wisely said, this is no subjet to claim credits for ourselves: we'll collect and organize data in a pure "community" spirit (that was the original meaning of this thread btw ).


PS: you will excuse me if I still call the Material Definition "MATD": I never got really accustomed to call it TXMT, and still sometimes confuse the TXMT with the TXTR - Posting on this old thread doesn't help, either!

Thanks for the attachment, Numenor. That will be useful.

So, this thread will be re-used to collect further infos.

As for the wiki info page, you're right, some infos are no longer valid.




From what I've seen, in the attached excel file, they're most of the common txmt/MATD property parameters and a few less common ones.
By the way, where to get that pogramme, I'm curious. you know, back to the days, I knew nothing, and I guess I really missed it.
In the txt file, are those all the occured instances in a particular type from the base game?
After checking out many txmt/MATD files and glimpsing some material shaders, I realised even just the amount of types are already amazing, but they do serve their functions mostly. Yet, some were dropped and/or broken.

Using data sheet for a big huge table seems the simplest.

Should they be categorised in a 2-sided xy-table
1. property parameters on the y-axis in the middle of the table
2. txmt/MATD types on the left x-axis.
3. digital type, known possible value ranges, default values, functions (how can be used), notes, object instances, etc will be on the right x-axis

So, the most significant infos will be alphabetically ordered and can be fused into one table for easy searching.
If people are finding infos through the object categorisation, there should be a categorisation list for objects, so people can get the terminology used for the object instance in the table to do a search.
If people are looking for infos through the txmt/MATD types, they can skim through the left horizontal x-axis alphabetically.
If people are seeking for the property parameters, they can check out the vertical y-axis.
If people are hitting at some in-game effects, there should an effect list to state out the possible txmt/MATD types and/or property parameters. Or, segmentise the categories.

While some highly specific materials or graphical settings can be made as some scattered tables of its owns. Yet, integrating them into the big one table is still just fine.

Let's start it with the common standard property paramters and the most common txmt/MATD types first... coz they're the most widely understood and used. As for the more specific ones can be done later gradually.

I assume these're the most common types, yet surely removal and addition are welcome.
Sims: SimSkin, SimStandardMaterial
HPC products: (CelShadedMaterial)[although there're some guidelines but not not well experimented, Floor, FloorPool, Wallpaper, WallpaperBump, WallpaperPool
objects and others: StandardMaterial, TextureAlpha, WallMask

The more specific, custom, and/or uncommonly-used (***updated to clear the confusing phrase***) types and properties parameters and especially the material shaders may be done and added later.

I kinda think additions of transparency, reflection map, bump/normal map can already be handled in simple tutorials rather than a more comprehensive info data sheet for various references.
Or, maybe there'll be links to those simpler tutorials for these common usages. Then, more types of users can be fulfilled.

Lol, some of the credits belong to all the info-sharers and all the Maxis staffs who left out some hints. I wish I could list them all out if I could know all of their names and efforts. And I regard this is a community-based project for info collection, organisation and presentation. Thanks in advance for the work.



No doubt... as you saw the need for more infos...


As I use both terms more, they become stuck together in my memory!


All,
just a quik note:
stdMatDiffCoef (1,1,1)
The RGB can be > 1, so it can be something like that (1.2, 0.5, 2.3).
The resultant in-game coloration (colorScalar) is gonna be like a multiplication of the textural values and the stdMatDiffCoef values, so regard stdMatDiffCoef as a monochromic filter where the colourational value is set by the users. So, one can make repository recolours by such means. Just do some simple maths and you'll get your desired recolours.

The 4th value is for the Alpha channel transparency, where 1 means opacque for the input texture while 0 means complete transparency for the input texture.

As for "stdMatUntexturedDiffAlpha", it's to decide the whole transparency of the resultant in-game coloration.

Numenor & Niol:
Yepp, we don't need another thread like this again but a result
As I was moved by you, Numenor, (I suppose you noticed) there was a reason why I didn't immediately post my request here though it would have made sense, too (and yepp, I already knew the original meaning of this thread - I was already referring to this with my more or less "wise words" )
To remind/ tell you: I'm a math sucker who don't know any programming languages and I just started to work with SimPE again about 2 weeks ago (as I found out that the things I imagined are possible now so it's time to get started) so believe me: I'll write my part of this info as easy and understandable/comprehensible as possible - and already useful for other "beginners" (definition: someone who creates his first package with more changes than only the mesh) who just realised (like I did) that the TXMT (MATD for Numenor ) is not only very confusing but even important as you can do lots of fine tuning there.
I started with cloning Maxis packages that seemed to be helpful to compare their TXMTs with mine and just copy some values (e.g. the fridge, car and glasstable only for metal- surfaces to get a nice reflectivity) which takes not only lots of time, is impractical and frustrating - and it takes a while until you find out on your own that the lower the value the more the reflectivity. So this was the idea I've had to write this info- collection and how I would start it as this would fulfill the needs of those who want quickly specific info and those who want to have a more detailled helpful overview as they not only want to change a certain thing but even want to know what they are doing.:
1. Starting with a simple quick overview table, listing the possible parameters with their known value/range - like you started your Excel table as a short introducion to everyone like "and with the TXMT (MATD) you can do these changes but not those".
2. Easy access to specific changes, listed by subjects like "for instance, how to add reflectivity or transparency to a piece of furniture" as I think it's easier to take a look at one table instead of searching for the right tutorial and there for the important step where you find out which parameter are required and which values you should take to get the best result for your effect.
3. Detailled infos: I think as it is thought to become an overview it can't harm to list even the one or another custom-uncommonly type as long as it contains something that's worth to mention - or just listing other useful topics that are related to the TXMT to let the others know what can be important for them, too (called 'skim- reading'?! (Ger: quer lesen)) as a reference for related topics.

Niol, seems like we all agree starting with a table and listing the most common types Maybe you can start a little introducion about material shaders (I myself don't know even what they are), not detailled or complex but a short description in a few sentences: what they are and what they are good for as a hint for the ones who still want to know more.

As I already have had an idea about the layout when I suggested to collect the infos this is my part so far (hopefully I can be helpful at all) and if I understood you right, Numenor and Niol, you were thinking about the layout of this info in a quite similar way. And the differences, I don't think it'll be difficult to find one way it's done best in our opinions.

Here at MTS2 are a lot of modders who already have a great knowledge (because of their jobs, talents, interests, whatever) and lots of people who just start to learn the necessary skills just because they have an idea for a package they want to create - like me *ehm*. Of course it's complicated to fulfill the needs of the beginners group without boring the others to death and you can easily want to write too much detailled stuff that is hard to understand for beginners. Finding the right mixture may be helpful to finish this info collection and help as many as possible people in the community out. So I think it can't be wrong when enough of "Hey, when you want to go further into the matter research about this next - information" is included as it may help saving lots of frustrating "what am I actually looking for to go on fixing this problem" so I think it can't be wrong to integrate a short definition about the shaders - when they are really so complex (as I said: shaders, what's that?) they might be worth a new topic anyway...

My primary concern, just like the two of you, is to create a table that would be easily searchable. But I'm not sure if Niol's suggestion is suitable, or perhaps I sisn't understood it fully.

Obviously, we are bound to 2D tables; since there are some parameters used by several material types, we know that we *must* have something repeated: if we choose as primary search key the parameters (as suggested by Niol), then we'll have in the first column many occurrences of the same material type. If we choose to order the list by material type, we'll have several occurrences of the same parameter.

So, the first question is: which should be the primary search key?

Niol suggests to use the parameters, and to start from the most common ones (leaving the list incomplete, until we finish this job, if ever we finish it )
But I still think that ordering the data by material type is better: this would allow us to organize the data, and publish it, "on installments": we can start with the most common materials types (the ones listed by Niol sound good), and then we can go on, explaining, if we can, the more unusual and less used ones.
We should also consider that many parameters are active only for some file types; and therefore, if a user wants to edit a MATD, he's bound to refer to the list of parameters allowed for that material type.

Of course, nothing prevents us to post two different lists, one searchable by material type, and one searchable by parameter name.
In this case, we can publish several 2D tables, one for each material type, each containing all the parameters for that type, the allowed values and info; and then one long list of parameters, with the references to all the types it is allowed into.

An example:


This layout is more readable and understandable for less experienced users (we don't want to put our knowledge into an ivory tower, right ).

Anyway, just to be clear, I don't disagree with Niol's layout: I just think that it would be more (too?) technical...

Kahibit's opinion on this subject will be valuable, having an "average user" point of view...

I realised I didn't present the 2-sided table clearly...
I see confusions with the table I suggested. Sorry, I'm bad at expressing things sometimes...

1.
The relationship between the material type and the parameters can be dealed with on the left-hand-sided x-axis of the table. So, the material type listing can be on the left. We may use some simple words or symbols to tell the readers if certain material parameters are "known to occur" in certain material types. Symbols or words are to tell what are "known to occur" (+) and "known not to occur" (-) while leaving blank for those unknowns.
The parameters can be in the middle along the y-axis linking both tables together coz the parameters are the common subjects of the 2 tables.
The descriptions of the parameters can be on the right-hand-sided x-axis.

(Material types) - (Property parameters) - (Parameter descriptions)
(Left-hand-side) - (Middle) - (Right-hand-side)

For example, check out the attachment.

So, in this idea, we can even reuse Numenor's excel file and add the material type on the left hand side of the parameters while we may leave a column for both their left and their right to make them visually distinctive from the material types and their descriptions.

For those who want to see the overall pattern and/or relationship, they can see these in one whole table.

Addition of specific property paramters can be done below the common standard ones and others. Basically, segmentise the y-axis where the property parameters are located and group them according to their known specific usages.

Surely, This same idea for the table can be altered like the following as well.
(Material types) - (Property parameters) - (Parameter descriptions)
(Top/y-axis) - (Middle/x-axis) - (Bottom/y-axis)

2.
Yet on the second hand, if the above type of table is not easily understandable, I think a few more simpler tables can be made instead. Besides, if they're done in what Numenor did in the excel file, it's not hard for people who want one big table to integrate them together while people who are more comfortable with tables in that format can readily understand them... Then, I tend to believe that may be a nice balancing point.

Addition of specific property paramters can be done below the common standard ones and others. Basically, segmentise the y-axis where the property parameters are located and group them according to their known specific usages.

3.
On an another hand (Yes, niol has >2 hands!), the format Numenor showed in post 133 is clear and neat, too. I can see its modularity and flexibility which are really suitable to this project. Yet, it takes many repetitions of data but copy-and-paste can ease the typing job.

So, there're 3 type of presentations here unless I've missed something.
1. the format of a left and right (or top and bottom) bi-table.
2. the table format used in the excel file.
3. the format in post 133

Ok, I've chosen my weapons for the duel me vs table descriptions: a) a dictionary (to make sure I can follow these table descriptions), b) pencil and several sheets of paper (to try and realise if I can follow these table descriptions), c) a rubber (to try and correct myself while trying to follow these table descriptions) and d) some brain (unfortunately out of order because of these table descriptions)... let's see who lost...

More or less seriously serious: I really tried to follow your table construction suggestions so if I understood you two right the tables should either look like:
- post 133, which refers to Numenor's Excel table (uses this order) but lists everything sorted by material type and again by parameters and has an useful index for quick access where to look for the values/parameter
- or a right/left bi-table which is niol's suggestion... though it refers to Numenor's Excel table, too (technical challenged says: it is easy to understand). The technical challenged thinks that the top/middle/bottom listing on x and y- axis at least sound complicated (my drawing even looks like that)
I never felt like being one of the technical challenged but obviously I am: what is the difference? I mean both of you want to use the same 'input' (parameters, values etc.) and you are still discussing the layout, right? And you still try to decide which layout/ way the table is sorted (and what to start with/ primary search key: parameter vs material type) is best/ easiest to use, right?
Maybe this may be helpful for the discussion as the technical challenged tries to explain to you two, which seems to be important for me/ how I would get along best with the table - and maybe this makes it easier for you to decide which way is best or maybe even how to combine the different ideas to the best result - but before I get started I do have a last technical challenged- stupid Q: can the user read them like an ordinary table you have to scroll or do you want to create tables with hot linking included, I mean is the index just an overview or an easy acces portal to get started (at least I suppose to know that it still could be offered as a PDF as it should support the hot links *start feeling really uncertain*)? If so (I know it's easy with html *proud as punch* ) a table with hot links makes a lot of work while linking everything correctly but the user should have an easy to use table and in this case it doesn't matter if it's one big one or if the table is splitted in parts/ smaller seperate tables.

OK, the technical challenged would be able to manage a table that starts with:
- the parameter when the table isn't more detailled so that I have to know the material type on my own or have to know at least the value I want to change
---> advantage: the parameters are listed alphabetically in the TXMT so the right one should be easy to find in/within (great, even my grammar troubles increase...) the table.
---> disadvantage: if I don't know which paramers have to be changed because a) I couldn't find or even didn't look for a tutorial for this kind of changes I want to do or b) if I don't look carefully enough at my TXMT and compare every parameter with the table I might not find every value I would have to change

So the technical challenged would prefer a table that starts with:
- the material type and for each of them the parameter are listed alphabetically or you can choose (index!) to start with the parameters and ignore the material type
---> advantage: I immediately know which parametrs have to be changed how - when I know in which material type I actually do the changes in my TXMT. If I don't want to take this offer (material type) I don't have to.
---> disadvantage: when I'm unsure if I'm looking for the right material type I might be concerned - but in this case I can just look for the parameter

For the technical challenged a table that supports easy access to the wanted ingame effect would be the ultimate, of course it is still listed by material type or even just parameters, too - you can make your decicion via the index:
- either if you know which material type or parameters you have to search for you can take a look at the wanted effect (listed in the index) which can be found in the one or other material type so you know where to go next
---> advantage: either if you know the material type or the parameter you can find the right and best fitting entry in the table easily (e.g. bump mapping for 1. floor, 2. object or 3. clothing?) as you should at least know what sort of file you are working on/ cloned in SimPe.
---> disadvantage: hmm, maybe someone could eben be confused by this decision, unable to answer but in this case the one should redo some tutorials...

Maybe that's what you suggested with the y top and bottom stuff, niol (as I said "eh?") but if you find a way how to prepare a table like the 3rd one it might be lots of work but the most effect for the users, either if they are really technical challenged, average or even advanced.
Reminds me of a commercial slogan... It says "Make the most of now" (don't ask me what product it is made for) but "make the most of a table"... maybe my post could help you to decide... the table... at least... at last...
It was about how the table should look like, wasn't it???

Sorry, the reason why I'm not 100% serious is just the point that a decission like this is surely important but somehow funny to me, too (strange humor) - like discussing if you want to pick the honey from the bees either with your naked hands, with the help of smoke, naked hands + smoke, what about a protective coat, or even a protective coat + hands in gloves + smoke, or just killing the bees (if so, which method would be best to kill the bees without affecting the honey?)? You want the most honey (= best effect) with less pain (= as clear, understandable and easy to use) which is necessary but my strange humour just freaks out when reading this so could you please come to one way you want to create the table?

As much as I see and as well as what I've read,
1. There'll be a part to tell what Maxis object types use what effects to familiarise users with what known/confirmed effects they can try. Why to choose Maxis object categorisation? coz most people should be familiar with it. So, when they're looking for a particular effect, they think of what object(s) or content(s) may have the effect. After all, there should an alphabetical listing for the effects, so users can skim through it first, and probably copy and search for the word or phrase among the whole part, article, or even thread.
2. Then, a part for what effects use what material types and/or property parameters.: Say, additions of transparency, reflection map, bump/normal map can be handled in simple tutorial table/listing/else in this part.
3. Table(s) or listing(s) or whatever presentation(s): This's the part to show what known property parameters a given material type is known to have. Also, this part will show the property parameters' description (inlcuding the value type, the value range, etc...)

I don't care which format will be chosen eventually as long as a set of database can be established in the end.
It's not hard to do other presentational formats once a set is already done.
The hardest parts of the project should be the data collection, organisation and confirmation.
What really matters about the presentational format are whether it will be widely understandable and easily used.

I thought one big bi-table for part3 may be able to fulfill plural usages, dependent on where people start to search. One can seek
1. from the material types to the property parameters;
2. from the property parameters to the material types;
3. for the corresponding property parameters settings
(left)<-->(middle)-->(right) [for bidirectional browsing]
or
(top)<-->(middle)-->(bottom) [for vertical browsing predominantly]
Yet, it can be challenging to those who are not comfortable with it.

Oh well, I noticed *gg* This time your post was easier to understand, thx!
It's fun for me to learn all the necessary skills I need to create objects in the way I imagined them and I suppose that many other creators started for the same or at least similar reasons: an idea that became a 'goal' and fun! But you can do those things without having to learn programming languages (if necessary it's enough to understand SimAntics well enough that you're able to do some changes and you know what you're doing), you don't have to be able to write working databases or programs and you don't need your bachelor or even master in math, computing science or something like that (if so the TXMT might just be properly discussed in this thread and that's it) so please forgive me that I don't want to learn the required background for the writing progress of the TXMT info for Everyone. I try to help you two as far and as well as I can and I hope that we reach a point I can really do something - as long as you two want my help. At least I can translate it into German

to 1st 1.: Using Maxis object categorisation and listing the effects which belong to the category seems to be a good start/ introducion (good idea!) but wouldn't this mean that all the Maxis objects have to be listed as e.g.
Surfaces -> Tables -> Milano Royale Dining Table/ Talking Table (and so on)
the Milano Royale Dining Table has a glass surface so it referrs to the 'reflectionkitchenhighcontrast-envcube' while the Talking Table doesn't - so grouping the effects only by categories wouldn't be detailled enough I think as this could be confusing to list effects in generally for categories. In this case all the addon- objects would have to be updated again and again? A more detailled grouping by categories would be easier - or was this what you meant?
An alphabetical listing for the effects is helpful for a quick search, good idea!

to 1st 2.: As a sub- or stand alone part? Good idea again though tables or lists should be enough as it's only about the necessary changes within certain parameters of the TXMT - one short "how to change the values, add or delete lines and correct the File List if required" should be enough as the progress stays the same. (We should add this though it is already explained in some other tutorials - reminds me of Numenor's "Lights and LGHT files" 'somehow-tutorial' - stupid me was thinking of what text list you were talking about until I got it *ggg* so it can't be wrong to repeat this quickly as it's easier to skip this when you already know it)

to 1st 3: So when the effects are described well enough that the user knows what he has to look for in the 'main table/ listing presentation' the bi-table will be easy to use. The technical challenged one is now fine with this kind of table

to 2nd 3.: Can you give me an example what you mean with vertical browsing, please? I guess I did it already but eh?

As we're already making some progress it seems to become widely understandable - and quite a long presentation. We should keep in mind to collect as much as possible infos (for various porposes/ needs) without getting lost in details which seems to become tricky, too.

Sorry, I left you two discussing alone... -
I've been busy (and I still am) in these days: things to post, things to fix, the Pets are coming...

I was thinking to the "Object categorization"... Yes, my intention is to give to modders an instrument to better edit their object, but perhaps that is *too* "tutorial-ish"?
This should be a reference table, not a tutorial, so we shouldn't explain "how to make a surface like the glass of the Milano table"; if one wants such a surface, grabs its TXMT, like all of us do
And once he has grabbed the right TXMT, he can understand its meaning reading the table (in this case, the table for the "StandardMaterial").
And while reading the table for the StandardMaterial, he can notice that it contains some parameters for the texture animation, or the reflectivity, and he may suddenly have new ideas for editing his object.

That's the way I imagine this "TXMT Encyclopedia".

A more complex table, with cross-references, would be more compact, but would scare the people, I think. BTW, if Delphy reads this, he will yell at us that the Wiki was *purposely created* to show cross-referenced data; but unfortunately I hate the Wiki, and I think it's reciprocal

So, my suggestion is: let's start collecting data for the various parameters, and then we'll decide *how* to connect the parameters with the various Material Types
Once the data is collected, we can think to a descriptive text that would explain how to manage specific [/I]groups[/I] of parameters (for instance, a small article that explains as a whole the group of parameters related to the animated textures, or to explain the relationships between the various "blend" parameters: this additional info won't be included in the table of course).

I like to help in a way or another. I always wanted to play with the MATD but I felt too unconfident to start.
So if you think you could use someone to type, compile, read, layout, transfer text in xls, etc I'd be happy to do so.
If you need a total noob to tell you if your guides are understandable, I can be that one!
I can already tell you that the TXMT_values.xls helps a bit to understand what this is all about as the txmt properties guide.txt let me feel that I have to understand a few things before diving into it.
Just by the way it's presented...

Lol! Don't think that I myself understand *all* the TXMT properties listed in that text file!
Thanks for your offer, you are appointed Beta Tester for this project
And your contribution is always welcome: if you - for instance - realize that you have always misunderstood the usage of a TXMT parameter, tell us; this will help us understanding what can be the most common mistakes people do about the TXMT.

/me smashes a bottle of champagne against the side of this project

txmt/MATD-project members,

To me, these sound like the format will be like the table used in the excel file...? Please correct me if I got it wrong. N, surely, I'm fine with all 3.

Maybe, there can be a separate section in a follow-up post listing some simple effect tutorial links or else... So, certain users can know where to look for some available tutorials related to this txmt/MATD.

As for the arrangement of the property parameters, they may be grouped according to their specific functionality. This may lose the alphabetical order, but one can use "find"/"search" to seek out the propery parameters from the table.

So, how do other txmt/MATD-project members think about adding pixelhate into the team?
I'm definitely happy with that.


pixelhate,

Thanks for your offer...I'm definitely delighted... To tell you the truth, I'm confused with the part about the standard material in the txt file, it seems it can have almost all the property parameters! But, in the standard material shader sheet, there aren't that "many". It has propery parameters from the cell shader, pool shader, etc... Maybe, they work in the type "standard material" while some may appear non-functional but stable. Gotta check them out... I don't know how to use them all either, and that's why more people are welcome to join and input into this community project...


Khaibit,
Sorry, for my terrible terminologies... "vertical browsing" = "scrolling vertically"... I'm from Wonderland, so words I may use can be so different that confuse people.


Added: now, niol's drunk and falling asleep...!

Cheers, niol!
First of all: Vertical browsing... is just scrolling vertically?!? That's all? niol, can you actually imagine what I started to suppose what this could be and how it could work? You're a nutty fruitcake from Wonderland though you more felt like a mushroom to me... just for the case you confuse me again (so far I could do it myself perfectly) may I call you "Alice" in a case of actual confusion? (I'm not so confused, it's the wrong sex)

Ok, from bottom to top to bottom again:

Numenor,

too tutorialish? As this project should end up in something that is an instrument for modders to better edit their objects/files/packages (this was my intention to ask you ) it might become either somehow tutorialish or most people start to feel like a complete idiot - so they would ask Pa Smurf for help with the help...
Maybe, no, obviously I didn't express myself clearly enough as I'm from Endlesslongandhorriblynestedsentenceland.
A bit more detailled grouping that makes it easier for the one who works with this reference should be tutorialish enough (as it should be required up to a point) to use this 'encyclopedia' while explaining every single object (that's why I listed the diningtables) would definately be too much = transfer job is required while reading/working with it to make the most of a table because this is the only way to make the most of your skills (I guess I shouldn't try to write explaining parts in English... anyone around who speaks German well enough to translate me?) The reference tables I've had to work with so far were all written in a way that you get the required infos you need though they aren't listed - as it's not necessary when you have enough information about "x" and "y" so you know how "z" behaves, it's just simple transfer. I guess quite a lot people already noticed that you, Numenor, can write explanations that are somehow tutorialish though it isn't a tutorial at all just because the 'understanding-factor' is what makes the InfoCenter threads, and the other stuff you wrote so far explaining things, so useful so why do you worry about creating the reference too tutorialish? Either this baby will become a tutorialish table or a cross- reference chaos it will contain some traces of Numenor so even if we would prefer to write unnecessary simple tutorials to avoid doing really complicated things we struggle with - I think you would tell us, wouldn't you?
"Do or do not... there is no try."

Cross references would scare people? I myself think they make it a lot easier... when the references are crossed well (nope, the Wiki is a horrible crossing so if Delphy reads this: it could need a tutorial how to use a cross reference data base that doesn't like crossing, in this case without crossing references please to avoid frustation because of constant noncrossing )
@Pixelhate (and niol), your opinion about cross- references: scary or helpful?

Numenor: what about a quick organization of the data collectors (who which parameters/material types/effects) or should everybody try and find what he/she/it gets? Could become some cross collecting of references... which isn't always wrong.
EDIT:
Just have had an idea how I might really be useful for the data collecting progress: I can search several English and German speaking foren for 2 points: 1. search for some new things someone found out about the TXMT he posted somewhere in the www and 2. keep an eye on the questions, problems that are reported/ ask for help as this might be useful to decide about the style/ detail- depth of the final result... yes/no?

pixelhate: Hello and welcome! Great that you want to help us - but you don't think that I know more than an itsy-bitsy bit about the TXMT yet, do you? So don't worry about this. We'll see, when the mixture is correct, we 2 will become TXMT editors who feel quite save when editing around :D


Ehm, Alice, how many members habe been in this this project before pixelhate entered? I can be wrong but I thought it was a threesome *confused again - did Inge join?* and as Numeon already agreed... especially because I'm definately the "other txmt/MATD-project member" who knows less... my nick isn't too complicated to you, is it?

No I just gave it my blessing by launching it like a ship with champagne. Since I am not helping, I can't really offer an opinion but I'd like it best if it was developed openly so people could use the information in one unfinished form or another while it was being accumulated, rather than a closed development process that suddenly appears for the first time as a finished product in several weeks.

As some people are good at listing technical things in a technical way, and others are good at extracting some of the more popular settings and writing beginners tutorials, it's good to have the basic facts available to many people all the way through, so they can use them in their own presentations.

I noticed so hopefully this launching won't end up in a sunken project.

Sounds like extreme cross linking to me As I don't expext that I can do much technical stuff during this developing progress I don't know if several other members of this txmt/MATD-project ( ) would agree with me but if they are fine with your suggestion - I would be fine with it if these people offer their opinion to the progress (understandable/ too detaild/ clearer please/ I have a hint/ whatever) though they aren't helping as niol is right, it can't be wrong to have more input and another point of view can offer possibilities... passive helping in an extreme cross linking multifunktional support preparing/ offering community project (as you know this"TXMT Encyclopedia" is just one point) makes sense, doesn't it? ANd this already happens

Lol... Just one more thing to suggest... after reading and re-evaluating the previous posts...

As for the object type thing, we can just talk about how the glass, metal, furniture surface is dealed with probably in some simple tutorials linked in the additional info section or post...


Khaibit,

We've got 4 members now... (Or am I mistaking, too? )
anyway, I'm getting openoffice 2.04 to work with the excel file...


Aded:
jokes apart...
I've started to complie a few of the previously linked standard material infos into Numenor's excel file using openoffice... coz I want to have something started... I've finished the texture animation inputs, but surely, more may be added as more inputs are gathered. Besides, more infos may be gathered from JWoods' cell animation tutorial... I'll leave the rest of the standard material definition for other members to do first..., Here's my editted version of that excel file...

I plan to do the pool definitions using the same format right now, and if the format is to be in another one, I believe the conversion will be easy.

I suggest we can use that format and make own pieces of spreedsheet and, then do the integration after we've finished our discusion on how to arrange the property parameters and/or the material types. The tables for the property parameters and their descriptions are kinda unidirectional, and that's why I think they can be started without much discussion except the parameter types, note and helps.

As for the parameter types, I'm unsure what [sort] is what type, so I just add them all together.

Regarding to the notes and helps, I'm just confused what should be for what... so, I just added some other titles there just for my convinience, and it's definitely alterable after we get a mutual understanding on how to deal with them.

Thank you all for letting me be part of the adventure. Just hoping I can really help and not being a dead load
For sure you 3-4 knows a bit or some bits about TXMT. I don't, I've never dare to change only 1 parameter! It looks so vast, where to start ?, what method to follow ? what result to expect ?

This is how I understand it: SimPE is like a gigantic mixing table in a sound studio.
The parameters are the adjusting/tuning/add effects knobs. (like bass/trebble/fx, etc.)
Some knobs are independent.
Some knobs are "masters" other depends from masters (the sub one). If you cut a master knob all his dependents/sub ones are also cut.
Some knobs are interelated and any change made to one, affect also the related knob(s)/parameter.
The file/package is the input instrument. Each instrument/package has his own typical feature (a bass is not treated as a piano) a wall is not treated as clothe.
Some adjustement are valid for all kind of instrument, some are specific to the genre or the tone of the instrument.
So, depending of all the tweaking made to the parameters/knobs the output file can be quite different of the input.

The mixing table (SimPe) is avaible but there's no complete "owner's manual". There are bit and pieces of "how to use that feature", "what happens if you do this" comming from people who have a technical understandment of its functionnalities (it looks like something else they know), or others who have a practical/empirical aproach (they are are not afraid to try and see). There are also mystery zones.
What is tried here is to collect all these bit and pieces and put them together, in hope to have an, as much as possible, complete owner's manual, accessible to everyone.

Does this analogy make any sense ?

Hmm, the math sucker tries to calculate: Numenor + Alice + me = *counting fingers* 3 + pixelhate makes 4... right?! 3 men and 1 'quota woman' (When we made it to agree at least in this point we might become experienced in agreeing in TXMT- project related points... )

Ok, I took a first look at your file... looks alredy very well. I'm already thinking of some things (like the Notes and Help list) and I could do a bit in the standart material- part (will try around tomorrow, too much wine tonight) but 2 questions: 1. The spreedsheet is the table, right? 2. Pool definitions are definitions of the data (material types etc.)?
As I'm completely unsure about technical terms in English it would be easier to understand them correctly if you either rephrase them extra for me immediately or you just go on writing like this and bargain for a 'technical term correctly understood- check- PM (and answer in this case of course ) as this is not required to be discussed in this thread, I think.

pixelhate (Four of Four ) your analogy makes absolutely sense! See, you already know what the TXMT is good for - and why an 'Encyclopedia' is complicated to write but required.
It will take a while until the owner's manual will be finished but we (al least 2 of 4 are able to do so) want to write a chapter that is written by someone who is really able to speak the language it is offered (instead of one of those bad translations which only make you laugh but don't make any sense so you have to fiddle on your own).

Looking at the XLS file make me suggest to add a column with links to related threads or articles.
If it's ok for all of you, I like to give a though and then propose improved layout for that file (like a printable version and computer readable one), see what uses of macro can be done etc.

Lol, just my re-stating the post with the stand material properties, here
If anyone wanna do all or parts of the rest of it, you can try to figure the patterns of the above updated excel file and compare that of the infos in that post... (the bottom "texure-animation" property parameters I did can be viewed as some examples...) Surely, questions and suggestions are welcome... May pm me (certainly) or others (I believe) about them... Thanks... Let's get the party started...!


pixelhate,
Yay, I like your analogy... and it makes sense to me...
Inexperienced? From now on, you're NOT...!
I also don't know how to use all of the features SimPE offers..., there're just many...
As for the linkage thing, I also have this in mind to add a column for references, how do other members think?
With regards to the layout idea, I don't see why not try a pilot of it out to see how others think?


Khaibit,
Yeah, the spreadsheet is the table.... I think we can talk about how to divide the work through pms by pm-ing one another in the team...
I'll start to do the pool part which is a specific part first coz I've had fooled around with it before.
When it comes to terminologies, I've to admit I'm not good at them either, but hey it's all about communications here..., so to pm me (surely) or others ( I think yet I can be wrong ) is fine ...
Wow, it sounds cool to have language translations...