SneaksieDave

As long as it's for all of 'em (prefabs, exports, copies...), yup.

It's a good idea; I forget every single time I go to make a prefab or copy/paste to another map or with all of the recent ASE export attempts.

Yep, found it. And it does make sense to have the different modes exclude each other, just wanted to be sure. I will keep feedback coming in this thread, unless we want to start a dedicated one.

Wow. Selection mode group/part is awesome. Trying to figure out the selection sets... don't see a menu item or shortcut yet; still looking. Edit: figured it out -- you just type in the name. Coolness. Would be great if you could delete individual entries instead of all at once, and if they could be saved to the .darkradiant file (realizing that it was stated as "first unpolished version"). Edit: little issue with select group parts mode -- when in it, you can't select anything that's not part of a group (e.g. a simple worldspawn brush). Not sure if that's a bug, or a feature. Thought selection mode was broken for a few there till I realized that's what was going on.

Fixed links: http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.4.0pre1.exe http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.4.0pre1.x64.exe

Very cool stuff, and great attention to detail. The recessed portcullis holes made me grin.

I'll be using it.

As I was mentioning in the other thread I guess there was just some misunderstanding. The only reason I've pursued this type of functionality (and suggested a specialized version) was because it sounded like the intention was to have the DR<->blender ASE workflow be completely seamless. No manual editing of materials in ASE files, for the ease of the users. To do so it would need special treatment of blender materials and TDM materials. If that's not the goal, then I just misunderstood/got over hopeful for it. Sounds like the workflow instead is: A. For DR exports, you can modify shapes some (not sure to the extent of this; maybe you can preserve materials within objects... or maybe if you add new polys you're screwed?), adjust verts etc, and vertex paint, without any ASE file hacking. I don't know how to do it yet but I hear there's a tutorial coming. This is good to have of course. B. For general purpose ASE, this gets us an up to date version of a script for exporting ASE, and then the user can manually hack the *BITMAP lines to work with TDM as previously. A bit scary thing that probably unfortunately keeps many users away from even trying (even though it's probably the easiest step they'll encounter in learning blender). This is good too though. A set of general ASE export/importers for DR and blender is definitely great in itself, so all efforts are appreciated here. At this time I know of a remaining issue, mentioned in the blender export script thread.

Ok, I wasn't sure, as I'm still unable to create a fully useable file. See the problem from above: Since I couldn't yet get it working for general ASE usage, it furthered my assumption this suite of scripts was being specialized to DR work only (since materials are handled differently). Possible remaining bug? I'm certainly no expert, but I've written a few and played with properties over the years, and produced a few ASEs for TDM (including hand editing of materials into *BITMAP). Anyway, to clarify: having working scripts either is fantastic. I simply misunderstood the intention I guess.

I'm confused. This isn't to be a general ASE export script for the Blender community? You mentioned in the other thread that you didn't want to specialize the scripts as people will surely download the wrong version (general version vs. DR friendly versions), but who else will be using them if they're only made for DR users? (Not hostile I assure you, just confused! ) Yep, for me at least. The vertex painting thing is drool worthy, and of course the ability to simply make a (new) model and export the ASE easily (w/o manual material hacking if possible) for use in TDM is the other 50% of the battle. These two things would revolutionize Blender's usage for TDM. The rest of the questions confused me. At any rate, if you specialize your scripts to be "DR<->Blender vertex modeling" only, that's still useful. I just hope that someday there is also a general ASE export script that allows for easy model creation for TDM.

Sounds easier to tell them "you didn't read the link description; download the correct version, dopey", than to require all would-be TDM mapper-modelers to always have to manually change materials within files, no? Well, either way I guess.

I assume there's not really a way to fix this (for now) if it's an engine bug, just wondering if others have had any similar experience. Also to get the topic out there in case anyone else does. I created a door out of 28 parts: the main piece, some frames, hinge pieces, and handles. I wonder if that it too complex for a door (I wouldn't guess that it have a single collision mesh, but must it?) The result is that if I try hard enough, I can step up onto the frame piece and walk right through the door. I tried removing the handles, assuming they were the problem, but no dice. I ended up hopefully fixing it by making a func_solid FULLCLIP brush the size of the door and binding it. Seems to work fine, so far... Anyone have insights? additional keywords: solid non-solid clip wtf

Ugh is this still going on? Aren't there better places for such concerns than the TDM forums? Again, "off topic" only stretches so far, I'd guess. The kindly grandparents who took in their grandchild after their divorced daughter died might also be wondering about the weirdos next door.

The more I worked with it and thought about it, the more I think having separate start-of-open, movement, and end-of-close movements is, while not ideal, the combination of best and easiest. It already works this way, just needs proper sounds (of which we don't have many at the moment). So, more a sound issue than one of code.

Surprisingly, I was going strong until the last two statements. How about a special case of the general scripts, just for DR stuff? Have the main version of the script behaves as it does now, flexible for any ASE imports and exports, and not limited to DR work. Then have a second, specialized version of the script which uses those modifications to use the first channel in this way to make it friendly for the DR<->Blender workflow?

Aha, that succeeded at exporting the ASE. However, on trying to re-import it, I don't see any texture in Textured mode. Seems the image has been erroneously named "Image - 0" instead of the stained glass I used when I exported it. We're gettin' there... Here's the log: found bundled python: D:\programs\BLENDE~1.5-A\.blender\python wmSubWindowSet 0: doesn't exist RNA_string_set: EXPORT_SCENE_OT_ase.filename not found. RNA_string_set: EXPORT_SCENE_OT_ase.directory not found. *** ASE Scene Exporter v0.01 *** Writing d:\blah3.ase Complete. wmSubWindowSet 0: doesn't exist wmSubWindowSet 0: doesn't exist wmSubWindowSet 0: doesn't exist

Trying again but I'm still not getting something right apparently. 1. New. Add cube. 2. Click the 'Material' button. Click New button. Result is Material.001 and some panes. 3. Click the 'Texture' button. A listbox of checkerboard icons appears. Click New button. Result is Texture.001 and some panes. 4. Change 'Clouds' to 'Image or Movie' 5. Under 'Image', click Open. Browse to a TGA and open it. It shows in the Preview box. 6. Under 'Mapping', change 'Generated' to 'UV'. Here's where the steps above get muddled a bit: in the Layer box, there is nothing but a checkered ball, no list of entries. Leave as ball, leave Projection as Flat. 7. In my UV map window, click the picture icon, and choose my TGA. There it is. 8. In the 3D window, go to Textured mode. It doesn't show the texture. Select, go to Edit mode. Spacebar, Unwrap. Now I see the texture on the cube faces. Back in Object mode, the textures remain. All seems well. So, I have a cube, seemingly with a material/texture, seemingly with a UV map and texture assigned, and Textured mode shows it. 9. Select the cube, and ASE export: d:\temp.ase NOTE: here, the export dialog suggests a .blend file. Possible bug or problem? End result: there is not temp.ase at d:\. I've tried other paths, I've tried 'tricking' the dialog into suggesting .ase instead of .blend by exporting a working ASE (from DR) first, I've tried creating multiple cubes, each with different UV mapped materials. None of it worked. Am I doing anything wrong? Here's the log: found bundled python: D:\programs\BLENDE~1.5-A\.blender\python RNA_string_set: EXPORT_SCENE_OT_ase.filename not found. RNA_string_set: EXPORT_SCENE_OT_ase.directory not found. *** ASE Scene Exporter v0.01 *** Traceback (most recent call last): File "D:\programs\BLENDE~1.5-A\.blender\scripts\io\export_ase.py", line 470, i n execute model = gatherData() File "D:\programs\BLENDE~1.5-A\.blender\scripts\io\export_ase.py", line 425, i n gatherData geolist = cGeomObjList() File "D:\programs\BLENDE~1.5-A\.blender\scripts\io\export_ase.py", line 137, i n __init__ geoobj = cGeomObject(object) File "D:\programs\BLENDE~1.5-A\.blender\scripts\io\export_ase.py", line 160, i n __init__ self.mesh = cMesh(object) File "D:\programs\BLENDE~1.5-A\.blender\scripts\io\export_ase.py", line 196, i n __init__ self.cvertlist = cCVertlist(object) File "D:\programs\BLENDE~1.5-A\.blender\scripts\io\export_ase.py", line 316, i n __init__ for face in object.data.vertex_colors[0].data: IndexError: bpy_prop_collection[index]: index 0 out of range

I think that'd be quite welcome. Even if most of the time it just sits there not being touched by the mapper, for those times when it is, it would be very useful to be able to modify it (or add additional, which is arguably even more important). Does that include multiple materials (from DR) or just one? Sorry if so many of these questions are just plain ignorant, but much of this is alien to the point where I admittedly don't understand many of the (I assume basic) references you're making.

It's actually only good for the default doors. If different sounds are needed (metal portcullis, stone door...) we're lacking there (flexible useful sounds). And if those doors need sounds at end of open and start of close, we're lacking (code). If the user wants scrapes, they're further at a loss, unless those sounds exist (sounds), not to mention they'll overlap with open and close sounds, if the code doesn't support a fix for that (code). And the open/close sounds only work if they are of the exact right length for the door movement (code, sound). We could go the route of having "smart" doors, which require code changes: * snd_open plays from start (already works, more sounds needed) * snd_move not needed * snd_close plays from start of movement toward close (needs coding, more sounds needed) (of course there could also be sounds at end of open and start of close...) Or simply get a bunch of new sounds which support the existing model: * snd_open plays from start (already works, more sounds needed) * snd_move plays during the movement (already works, more sounds needed) * snd_close plays when door stops moving (just the klatch; already works, more sounds needed) I favor the second method, as it is most flexible for the mapper. You can have a silent open if you wish, or a silent close if you wish, or a silent move if you wish. The other method isn't so flexible and is IMO messy. However, both methods have significant legwork in the way: Method one requires coding. How likely that is to happen, you'd have to ask programmers. Method two requires a sound department. Good luck with that.

Yep. That's certainly preferable to using snd_move and (klatch-only) snd_closed sounds (some exist, more needed), in conjunction with a code change to snd_open to make it also play only klatch (or whatever) sounds at end of open (sounds needed).

Yep @what grayman said. And it could no doubt be done with script. The button method in the map above suffers the problem where if the player frobs again during mid-movement the sound replays, so you can get multiple movement sounds playing overtop one another. An 'acceptable' method is to use the snd_move property for movement scraping, and then 'silence' out the snd_open and snd_close. It's far from ideal, but the sounds are handled lopsided -- open plays from the start, and closed plays from the end. Both should play from start of movement. The problem this creates is while an open sound can include pre-scrapes and then a klatch at end, the close movement cannot have scrapes at the beginning with a klatch at end... because the whole dang sound plays once the door stops! You can have a stand-alone klatch at end of close, with a _move scrape... but then what about the open sound? Ugh. Maybe I'll submit an issue and see if anything comes of it. This really should be pre-canned behavior.

Couple of door sound questions: 1. What is the correct way (or a clever one) to set up a door to have sounds that play upon start of movement in both the open and close directions? Currently it seems snd_open does this for opening, but snd_close doesn't play on start of movement but rather end of movement (upon closing). Great for a KLUNK! closing sound, but not for a movement/scraping/whatever sound. Devs: if this is currently not supported, can it be? Pretty much a needed property. I might just be missing the correct way though... 2. If such sounds are longer than the actual door movement, the sound doesn't cut off properly; instead it keeps playing for the full length, even if the door is open/closed. Limitation, or am I missing the proper way to implement it? I'm sure it can be scripted, but this should be proper canned behavior.

Possible problem here, or I'm doing something wrong. While importing from DR and then exporting works fine, I can't create something new and export as ASE. 1. New, Add cube 2. go to UV and load an image 3. in edit mode, unwrap 4. in textured mode, this shows the 6 sides of the cube covered with the image. 5. Select and Export ASE -- give it a name and Export. But no file exists (repeated attempts) I also tried applying a material before saving but that didn't work and shouldn't be necessary anyway. Edit: maybe the mesh needs a name? Technical details going beyond my very limited knowledge.

Hm, UV and textured mode seem ok in Blender 2.52, so it's something else... Though quite disturbing is that it seems blender won't open a DDS?

I tried fiddling around but so far no success. [Edit] Okay so as Orb just said, the *BITMAP line isn't a file, but a material (in Doom at least). The one in my model is, for example: *BITMAP "\\purgatory\purgatory\doom\base\textures\darkmod\stone\brick\long_cracked_blocks" I don't know what's with the purgatory stuff. *MAP_NAME is another line that seems useful. it was *MAP_NAME "textures\darkmod\stone\brick\long_cracked_blocks" and I changed it to a file path, *MAP_NAME "D:\doom3\darkmod\dds\textures\darkmod\stone\brick\long_cracked_blocks" But this didn't help either. Well, either that or textured mode and UV mapping is busted in 2.52, which I can't tell or not. Simply using textures has always been IMO the most confusing thing about Blender. I was hoping the *MAP_NAME would be the sharable path between Blender and DR but I guess that would be too easy.