Actually I think maybe I (well Peter and I) could get involved in this. I was telling him a little while ago it would be good to have a more helpful TXMT plugin, perhaps a wizard with all the different settings and their maxima/minima that writes out the TXMT for you. We maintain Help for PJSE and that could have a link to whatever tutorials or references were provided here.

But first we're trapped updating the TTAB plugin for format 54. If anyone knows what the new data in that format is, I'd be very happy to be contacted with the info :D

Wow, a new plugin for txmt/MATD, cool...

It'll be good to have a txmt/MATD plugin that can edit multiple txmt files at once whether by check boxes or whatever other means... That'll save a lot of repeitive works effectively. I've tried scripting, but they don't work well in many cases. It's great in some cases where I've saved a lot of work...

A little dictionary with check boxes or else to choose what property parameters to be added or overwrite the original ones in the txmt file(s)

I know that'll be kinda luxurious and show how lazy niol is!
But, that can really speed up the txmt editing process tremendously due to the huge amount of data in some cases, especially for CAS and (now CAP also?) products.

Just a question: if that plugin may be made, may it contain all the txmt properties or just some common ones and the standard ones?
Now, niol is dreaming while doing more on the table for the pool stuffs...

I was thinking the wizard should contain ALL possible settings and then make itself responsible for writing back the used ones in order while suppressing the unused settings to keep the result as small as possible. Better still give the choice to write all or suppress ununused so if during development you want to temporarily turn off animations you don't lose all the animation settings It can have different display options so some people might just want the usual ones for transparency and reflection etc.

Inge,

Ohhhhhhhh...! Now, I feel like a whiny little kid...
Still, the video setting is still a question in my head... Think your Maxoid friend or someone may tell how to use it?

Unfortunately we no longer have a maxoid friend. I think they shipped him off to Spore or something... And Sam ain't talking business with the modders yet.

OK, here I am
As Inge knows very well, every EP that comes out is a nightmare for the modders, and I have to do my assignments... -

Anyway, I was thinking to the best way to share the data between us while the compilation of the TXMT list was in progress; I thought of a private forum with a thread for each Material Type, but it would be too difficult to set up.

We need a place where to post our data, letting to the other member to edit and add their own findings, without overlapping and without duplications; a normal forum isn't suitable for this, because users can't edit other users' posts to add their own findings.

Then, much to my dismay, I realized that the only place where we could do this "free exchange" of data already exists, and it's... the Wiki!.
I've run a quick tour in the wiki, and I've realized that probably it is really the best place where to move this project: there, every project member can create pages at will, and also edit at will all the existing pages.

For instance, Niol could start with a page covering the Floor material, writing a list of all the possible parameters allowed for that type; this list, for instance, includes the "stdMatDiffCoeff" parameter, and therefore Niol creates a page for this parameter.

Separately from Niol, I work on the StandardMaterial type, and I complile my own list of available parameters; in my list, too, there is the "stdMatDiffCoeff" parameter, but I don't have to duplicate the work made by Niol: I just link to his page! And, if necessary, I edit Niol's page about the stdMatDiffCoeff, to include my findings on that parameter.

It's really an efficient way of working: as an added bonus, when we are done, we don't have to reorganize the data in any way: the final result of the project is already ready to be used
Inge and Peter could use the stored data while we are still working on it, without haveing to wait the end of the project.
And the resulting data could be easily browsed by Parameter name, by Material type or by any other key: we just need to create a specific index page.

I'm inclined, after a lot of doubts and afterthoughts, to start my journey into the Wiki. What you think?

I hated the Wiki too, but at 54 I am always anxious to prove to myself I can still learn things, so I even created a little page in it. I think it was the Who Is section about Quaxi, if I remember rightly.

Ehm, where, Inge? Just found Numenor's (oh, nice picture of you, useful wiki, full of required information ) First Page.

The idea of adding a wizard to SimPE sounds sooo great! Will save lots of time...

Numenor, just found out that your great idea using the Wiki has one disadvantage (at least for me): People have to know how to edit something there - and I think I don't. When entering 'edit mode' at this site it looks strange (Java ok, bold, italian, internal link, headline and *writing text* is easy) so no idea about heater layout, necessary content, something like that before I can write... eh, and spreadsheets?
Something to copy/paste or hints without having to learn Java?

http://www.sims2wiki.info/Quaxi

I think I need a break *blinddumbusedup*
THX!

Feel free to add to it, it's not exactly detailed :D

No Java is involved in editing the Wiki; actually, it seems to me a very old textual system.

The basics of the formatting, createing links et al is HERE; some good examples and hints are HERE.

I've seen that there are optional templates or java-like scripts that add a superimposed thumbnail, or other special effects; but they are not necessary at all.

The odd thing will be to learn simple things, like to get the bold using three apostrophes

Oh... the holy Wiki... (Here comes my white flag!)

I guess I'm too stupid that I feel and find myself getting lost and trapped whenever I visit(ed, ***now it seems to be a past...***) the Wiki.
I never know how others can get to the places they link in the posts in the forum.
I've absolutely no idea of how to view something more technical there coz I just get a message claiming I was not allowed to edit the page while I intended to view and read it only.

So, you see why I don't bother to visit it without necessity.
I don't hate it but am just frustrated with it.
So, my conclusion is "The Wiki hates me...!"

Whines apart, any dummy idiot-proof tutorial introducing how to use the Wiki?


If these infos will be done in Wiki.
I kinda think the descriptions and "how-to-use" of the property parameters should be on the property parameter pages.
A property parameter page should have reference link(s) to the txmt/MATD types the property parameter is involved.
A txmt/MATD type page just has the reference links to the property parameter pages.

But, if in this way, it's really frustrating (probably only to me?) to browse around instead moving the window bars to see more paramters and types with ease. This's just not like having a big table showing the data plainly. And it's hard to analyse the patterns among similar material types. I'm not saying Wiki is no good at all. But in this case and this way, it seems too exhausting / overwhelming to browse around in order to gather or edit the infos coz we may be doing hundreads of pages if we do it in such a way.

There're problems I see of such approach:
1. there're some property paramters are not in any material type and so they may be left out as orphans parameters easily.
2. There're at least 1 or 2 material types have no explicit property parameters, so they may be left out as orphan material types.
3. we can only do the ones that we know possible and impossible. The unknowns are easily left out in this approach coz it demands the readers to at least memorise what hasn't been tried or they've to search everywhere for what's not been tried. This will in turn enervate the process to knowing them all and it's hard to have a full figure of where and what to head on for trials...
So, as you see, there's a fluidity I think that approach is making it hard to deal with.


How about we just dump the cell table files in the Wiki for info exchanges?


Added:
Actually, this post was written after post 158, but was postponed 2 hours to post due to my being away.

lol, just realised there was an updated thread for getting started... That tells how long I've not been there since the last before my getting the previous link from Wiki.

As I don't know Java it looks for me very Javalish Arrgh, Wiki tuts...

The more I'm thinking about this idea (which means give the Wiki a fair chance but I get lost there) the more I think the Wiki hates almost everyone, probably even Delphy but he didn't notice yet???
I want an encyclopedia seperated from the wiki that it's useable without tutorials how to read this tutorial *gripingaroundlikeatoddler*

Isn't it strange to you that even experienced modders like you struggle with the wiki? Did you actually ask yourself how many people would read our wiki-texts as nobody would find it??? Even with a direct link people might still be scared shitless to enter the Wikispace!

OK, serious: The attachment is my changed version of niol's XLS file - I just added the Maxis stuff from your single post- link, niol (hopefully my changes are completely red) and after I made it to read properly (I just had to while comparing the values) I even noticed where it's from :D
Eh, yes, the additional pages (?), my workspace in progress in your file - I splitted your titles in parts, don't know yet if it makes sense... PPC (protein PC) is still working on that, added English translation there extra for you Comments, ideas?

Wiki:
If I would knew how to get this xls-file in there I wouldn't add it as an attachment. Working with real spreadsheets makes it easier than writing immediately in the wiki- pages though the information transfare is easier there.

What about asking Delphi gently if it's ok to get a seperated temporary workspace forum as we don't like the wiki

Serious again (I really try):
Offering language support might become a big problem, too because a) the wiki is so far as I know English only and b) translating and crosslinking correctly and completely (English <--> other language <--> next topic, again English and other language) would be a lot more complicated than just translating a HTML- site/PDF/whatever document so who would like to do so as those who translate are able to understand... Do I have to explain why language support is important?

Hmm, the probs niol sees appear on the horizon while I'm looking around though I can still see Numenor's silver lining...
It can't be wrong to update the wiki-txmt entries (for the few who use it) and it's an easy access to other member's progress, I could even get "my" cross linking - but this kind of cross linking (between pages and pages...) is too uncomfortable so most people don't do it if they don't really want it/ have to. Of course we could just say "it doesn't matter if someone wants to read what we wrote or not as Inge and Peter will develop a wizard, hehehe" but I think noone of us would really like to spend his/her time when it's only for Inge, Peter and... maybe the one who comes there by accident (don't get me wrong, this offer of trying to develop a TXMT wizard IS great - but the benefit of this encyclopedia can be increased a lot when offering it to AMAP people instead of just preparing a programmers guide for another SimPE wizard, it would just be a pity).

So my suggestion: what about mixing the advantages of spreadsheets (and their layout possibilities) and the wiki filesharing area?
(Ok, how to upload files there???)
We can write/ work on spreadsheets and write additional/ explaining texts in the wikispace, which is linked correctly (wiki tables can be added at the end of this project, so far xls-.sharing). So even the unknown parameter can be handled in the xls- version and are listed in the final wiki- table (for further texts if experienced) like we can decide how much linking will be required for us to work with without too much cross linking - the final wiki version can even only have some main parameter or effect links while the spreadsheet handle them in a different way (via macros or whatever you guys can do with 'tables' ). Either if you decide to create new links for the definition of some doubled parameter like the "stdMatDiffCoeff" or you decide to use one page for all the double listings you both edit together and when the texts are finished you copy, paste the required parts from there into the spreadsheet(s) the info/data sharing should be quite easy in the wikispace (as long as you don't try linking each other to madness).
Understandable?

EDIT: Looked at Numenor's help- links and found the file- upload (I'm so blind *doh!*), so I think I can manage wiki-writing...
Seems like I have an idea about a beginners- introducion, pixelhate and me can try to write it - and the others can decide to delete it again if it's too tutorialish... So far...

Quaxi's TXMT editor in SimPE loads in the Properties definitions from an xml file, if anyone wants to update it with the information from the spreadsheet.

...\SimPE\Data\txmtdefinition.xml looks like this:

So you define the <enums> for fields with a range of set text values ("none", "auto", etc), then categorise properties, using type="..." to specify the validation rules.

Thanks, I didn't think to transfer the TXMT data to the SimPE's xlm, it's a good idea
Of course, we have to finish the collection and arrangement of the data, before doing that :P

Ehm, I took a look, compared with the spreadsheet... and, guess what: I am confused!
Whenever I thought I understood the structure of this xml-file I found something which didn't fit my 'understanding-trial' so is there a site with explanations how to read in this file somewhere around? Or can you give me one? Thanks in advance

How are *we* making progress with data-collecting, Numenor? :D

I didn't even know about the xml file, and Peter didn't think to look at that at first, so he spent a few days looking at other ways to make a material editor until suddenly he discovered that!

Is that the presets for txmt editor categorised interface or something else?

I've a full faith Khaibit will understand it fast soon if not yet... So, the property type definitions are in txmtdefinition.xsd?

*erm* Yes, of course, 'Tim'
It seems to me that there is also some other stuff listed (like GUID etc.) so this is another reason why I'm still confused - I cannot expect that everything is about the txmt. Didn't have the time to search/google yet...

Do you understand it?

really didn't think about mod-the-simpe (MTS)!
Yes, it's really the preset list for txmt editor categorised interface... just test it out for my convinience...
Now, I haven't to wait for an update to have some of the values I've already known to appear in the simpe... I can do that myself a little bit. :D

Lol, I only understand a little bit of it... not fully understand all the terms or parameters.
I'm no programmer anyway.


added:
I suddenly wonder if there can be a graphical preview for the environmentmap with a set of known in-game values while keeping the blank customisable... That'll further save a lot of work of typing or copy&paste...

for some reasons,
the parameter preset list is kinda random...

I've been wondering where this paramter is from:
stdMatTextureCoordTfAnimTransStartY
I've just found it appear in that txmt list. If it does exist, then it's probably not a standard one.

But you're a Tüftler (sorry, couldn't find a fitting translation... what you do all the time when you're not lost :D) and this stuff is intresting.

It's more MTPe, isn't it? Suggestion: you 2 go on collecting and arranging data, like the Italian guy said, and I'll try to manage this strange listing - in this case I can do something useful, too.

Edit - to Niol's edit:
It's made by Quaxi, right? So maybe asking him where he extracted the data for the file from? Might be helpful...

No doubt... :D

If many presets are already in the xml file, how to add them instead of copy&paste them into the lines@ the categorised interface?

added: sorry... i presumed one knows where it is.

The pic also shows my addition to the preset for the "addressing" by adding them into that xml file. It works.

pljones, I thank your pointing it out...

Ehm, what? can you re-phrase, please? :D

BTW, I added each 1 line in the materials and parameters-talk - might be helpful to be understandable for beginner I thought...

Argh, still I failed to add some texture names there as some enum presets...
I'm too lazy to analyse the xsd file to add in new modified definitions. :P

The string type is predefined too board for my purpose. Yet, a clone of it with a different name should work it out, I bet...:D