Tels

I know but that did for some reason not work - either the editor textures weren't properly reloaded or I goofed up something else. After a restart of DR and loading a different map it works now

Checked in as revision 3575. The dds/.../rough_wood_fungi.dds is no longer needed, the rough_wood_grey.dds replaces it. Should I delete it? And can somebody please check that the .dds file I created (rough_wood_grey.dds) is well-formed? I am still unsure wether the Gimp plugin works and I used it properly (It works here on linux, so please test the textures

However, DR uses the que_editorimage maps to actually draw textures, and since these are correctly colored, it all looks fine now - DR just doesn't seem to reload them or something, but after a restart, everything works as it should. Will check these in in a minute.

Baddcogg, you might be right about the beams, it depends on the size of the floorarea, and whats on top of it, and it definitely looks a bit "too much" right now. Of course, they are inside and on th ceiling, so performance won't matter there In my case, I think the beams are bit too dense. However, if you look at the photo, you see them sticking out both walls, so there was definitely some criss-cross beam structure. Unfortunately, I do not have inside shots of that house :/ Edit: It is definitely right to have criss-crossed beams: Beams transfer the force from the top-storeys/roof down to the wall. Now, if you have beams in only one direction, then only the walls that carry the beams will take the force, the other two walls would just sit there and not get any force at all. Technically, you can build a house that way, but in praxis you want the force divided between all four walls (and thus make thinner walls) than just spead the force to two walls). What I remember from my castle tours is that sometimes a really huge central beam is used, then all other beams are at 90° to this beam. However, having multiple smaller beams at 90°isn't uncommon, esp. as a big beam is more complicated to handle (massive!) and a single point of failure.

It works in theory, but in praxis DarkRadiant doesn't apply the shaders (at least under linux), so all wood textures look grey :/

For my houses I need different colored "big" wood beams. The current "fungi" texture is nice, but it is a bit green for my tastes So, I had the idea that we could take that texture image, desaturate it so we end up with a medium gray version. Then we could add 3..5 materials all using this texture, but shaderparams like so: red param0 * 0.5 green param0 * 1 blue param0 * 1 to effectively just color the same texture. That would save us texture space. Is this generally a workable way? Should I go for it?

Ah - but only if you set surfacetype15, right?

If this is a TDM addition, couldn't we change it to "editor_usage" for consistency?

Speaking of that, some materials have: "description" "blah" lines, but I can't see how or where DarkRadiant does display them. Shouldn't these lines be called "editor_usage" or is "description" actually right. And is this a bug that DR doesn't display them?

I think it would also be a good idea to "hide" any doom textures in a different folder called "base" like so: + darkmod + stone + common + sfx + base etc. E.g. anything from doom goes into base, anything from darkmod goes into "darkmod" (and no rendundant "textures"). A few critical things like common and sfx nee to be under darkmod, too, This way you won't have to wade through 50 different folders with doom specific missions just to find darkmod/wood. Likewise, this way you don't have to remember if sfx/sky was under darkmod or outside. It would also make the textures hirarchy consistent with the entity hierarchy and consistency is always good in UI design

Have you looked at my glass shaders? They are quite alot more complicated (I admit I haven't tried frobbing my glass, maybe I can (have to) use only one stage as your frob does. I will toy around with this. But we needed "flat" glass, too.

As for window-panes, I am still trying to come up with an effect that shows that the small window panes aren't flat, but bulged out.

I didn't know this and after a quick look, I couldn't find it. Where is it hidden? (Edit: nevermind, I read the thread now) Oh, and I just noticed there is darkmod/sfx/glass_clear and glass_clear_nomorph. Doh. However, after a quick testing it seems that glass_clear reacts quite odd in my testmap when I replace my glass with it. It is way to bright when a light shines on it. Hm.

I just checked in various glass and crystal materials, a glass material base texture and a test map in maps/test/glass.map to showcase what I got working now. The 4 different glass types (clear, yellowish-clear, milky, dirty yellow) all come in 2 sets - non-distorting and distorting. The crystals come in only one set, milky, non-distorting and well, you should check them out Oh, and make sure you also check out the downstairs room

Yes, once I figure out how to generate the proper file for the vertex shader, this can be done. For now, the glass uses a generic "distortion" map, which just adds some ripples.

As far as I know, this is just how it is. Even the ID guys knew this and setup stuff so that the player doesn't have a weapon if he is in front of large glass windows etc. Maybe fixable if the renderer goes open source.

I started to work on crystal/glass textures: I intend to add more versions (transparency can be tweaked) and commit this stuff over the weekend to the SVN.

But I don't think you understand 0121 with out 0003 Here is something more ontopic: http://www.giantitp.com/comics/oots0008.html Now excuse me I need to stop my self posting entire OotS here - you guys should really read it.

Well, this doesn't work as you write, maybe it depends on the client. I never got the .mine files. Likewise, some people get the old content just spliced into the files, etc. (which is even worse than the .mine files as they will usually just blindly commit the garbled files to the repository :/ Trying to resolve the conflict with SVN is only good if you know already what you do and how your SVN client works really - I prefer to move my files out of the way and then merge them manually as to whatever the SVN client might do

Uh, my mind is really bad I haven't even logged in into TTLG forums for years, but I think mylogin there would have been "Tels", too. Maybe my source code archive contains some credits file with a thank you note to you? Must check http://bloodgate.com/thief/pub/cow_023b30.zip Oh, last updated 2000....wow. jdsmith its the "xarax" from my signature. Credits ======= Go to: Mahk and Doug at Looking Glass Studios for their hints and tips. Looking Glass Studios, for making such cool games and creating one of the most flexible game engines in the world! Alex Fung for his help with the listbook script Larson, for his very usefull comments and emails and giving me cool ideas. jdsmith, for finding bux and actually fixing them :) Dan Nightfall, for running the coolest fan sites on the entire 'net O Love, for, you know what :) To all taffers on the Thief Editor Guild's Forum: http://www.ttlg.com/forums/ Thumper for his very usefull hints at the database file format. Tran for the GUI code and the long email discussions. I have learned a lot from you, pal! KFGecko for inspiring dome, Jonquil for the new fireplace idea. All game designers and map makers for their endless inspirations, especially from Thief, System Shock 2 and Unreal. Thanx to some games for their horrible architecture and maps as bad examples. Special Note ============ On May 24th of 2000 Looking Glass Studios died a sudden and unexpected dead. We will all miss you and your games, thank you for all the joy and fun you brought into our lifes! R.I.P. Sorry, I don't see you in there but I might just have forgotten to list you, or worse, this is an old copy. My current email archives go only back to 2004 - maybe I can dig up older emails.

I heard the are just Bigrats....

He probably meant this: http://www.giantitp.com/comics/oots0003.html

You don't mean by any chance these scripts? http://www.gamedev.net/reference/design/features/vworld/

If you still have problems committing your changes, send me a pm and I help you sorting it out. One reminder to all others, tho: If you change something in the tree, commit it as soon as possible! Every day you wait before commiting your changes increases the chance that somebody else modified the same file and you risk a conflict! Resolving conflicts must be done manually, and can be a lot of work. Basically you must move out your modifed files to a different location, run "svn update" to get the latest revision from the server, then manually merge your changes to the files back in. Note the word "manually" here So, make "svn update" quite often, and "svn commit" as soon as possible

Anybody who wrestled with DromEd to create these types of maps is really a mapper - oh, just the memory of DromEd pains me.