Dragofer

Found the solution: TDM can't play sounds if they have a sample rate of 48000 Hz, shown at the left of the soundtrack next to 'Stereo' in Audacity. They have to be converted to 44100 Hz by changing the project sample rate in the bottom left of the screen before exporting. All the sounds work now, thanks for your help

These 3 shaders don't work: This shader for example does work: This is the sounds testmap including the originals: https://www.dropbox.com/s/86azsj8x05f8y08/dragofer_sounds.zip?dl=0 I've swapped .ogg for .wav in the shader and moved the original .wav's into the ambients folder but that doesn't work either.

Thanks for helping out Bikerdude The setup works with other soundshaders, but if the speaker uses one of those 3 defect custom ambients nothing happens when it's triggered. Inside DR they play properly. I can't rule out other causes, but my guess would be that there's a property in the .original/ogg files that makes them unreadable by the game engine. Maybe someone else has come across this before? (I'm guessing plenty of Halloween contestants got some custom sounds for their missions recently)

I've been avoiding posting WIP shots, but I have been making a mission named 'Down by the Riverside', taking place in Newfoundland. Development has been going at great speed by my standards and it's reached its full size of 3000 brushes + 2000 patches. But I haven't been able to do any TDM over this weekend and neither on the next. Getting it ready in time will be very tricky. One thing that's been keeping me busy is custom ambients troubles. All work properly in DR, but ingame the majority of them are silent. My workflow: - Audacity: export to .ogg into sound/custom folder - Copy-paste filename into copy-pasted soundshader template It can't be the format itself: i.e. some .wav's work, others don't. Could it be a reason like that the engine can't read sound files if they're mono / if the bitrate is too high too low etc.? It would be a fiasco if the mission didn't have these ambients.

Looks like I'm guily of making that final texture tweak that throws everything out of order. But I've taken the opportunity to make some changes: - shaved off 500 not really necessary polys from the mesh+shadomesh - added a brass skin. It's a much better colour for this kind of lamp, and ingame it's not so blurry https://www.dropbox.com/s/dpgaknj4d7ax44h/dragofer_oil_table_lamp.zip?dl=0

I quite agree, thanks for pointing this out. It's fun to find out more and more methods to come to a smooth and detailed item without thinking so much of how to get it into a game, but in the end your suggestion of working more with the texture instead is a much more effective use of the time. And as you said, you'd need a high-resolution normalmap to see the benefits from the highpoly - the chalice looks very rough if the normalmap is only 512 x 512. Sure, I've prepared a package with the lamp. Unwrapped it, gave it the metal texture from the sphere lamps, set up materials, entity def, Skins, made a shadowmesh. Now normally by now I'd have been in the middle of learning GIMP, baking normalmaps and troubleshooting them, creating specular maps, and turning that photograph into a model-specific UV texture, but as you know that Halloween contest happened... Specs: - 1350 tris of which 360 shadowmesh - Gold, silver and brass skins - Entity under oil lamps, model under non-extinguishable lamps - There's a little bit of a seam with that texture - For some reason inside DR the lit shader (bc_lampglass) has an unlit editor image and the unlit shader (tdm_lampglass_unlit) has a lit editor image. But it's correct ingame. https://www.dropbox.com/s/dpgaknj4d7ax44h/dragofer_oil_table_lamp.zip?dl=0 (same updated link as in a later post)

Great, I'm in for a speedy creepy mission, with a plan and all (now from scratch). Here goes.

I've looked through the video tutorials available - what I was looking for was a user-friendly beginner's walkthrough for making a simple object as that would show many of the tools in action. The best bet imo is to follow the instructions in 'modelling a simple table'. Before starting it would be good to create a .txt file where you can record every shortcut mentioned. From there I'd suggest to make a simple model from start to finish, like a cartwheel. That way you'd learn everything needed: how to manipulate a mesh, how to texture, how to export etc. Whenever you need to know how something is done in Wings3d, Youtube or Google will be handy for a quick tutorial.

Yes, the caulk wouldn't be good to use like this in a real map. I'd use it in this testmap though because that effect lets you see if certain objects are being rendered even though their visleaf is closed. If anything it saves having to type r_showtris.

Yes, that would be a very simple photoshop if any mapper ever wanted to work with a different order of the religion - maybe a seclusive sect, or a town so distant from Bridgeport that religious practice follows an unfamiliar doctrine. Just as Rome and Constantinople were opposing centres of religious authority. It could go further still and be a difference on a level like Catholicism and Protestantism (Calvinism). In the colder northern regions you could find a Builder order whose followers wear grey or black, live strict and simple lives and who build plain churches with no adornments. No golden builder symbols or candlesticks. Although closer inspection of the Bishop's chambers by a thief might reveal a sizeable stash of valuables. I'm sure there were long discussions of having several orders in the core assets, for example if there should be Mechanists. The concensus turned out to be one order, which looks to me like it's midway between Hammerites and Mechanists - their symbol is a hammer and cog. Mechanically very capable, but not really into steambots, cyborgs or automated surveillance. Yet.

That makes sense - I haven't seen any patch func_statics leak when they were well inside the room, touching no walls. If I had my mapping tools to hand now instead of in a couple days I could send you a large selection of problematic beams & co from my WIP. I'd set up the testmap as two rooms separated by a caulk wall with a door, the player on one side and the func_statics on the other.

Something that's been bugging me for a while is that some patch func_statics like roof beams get rendered although I'm in a different visleaf. For example, r_showtris or giving the walls a caulk texture shows that even though I'm standing outside the house, a lot of the beams inside the house are being rendered. (Visportals all closed) Did anyone else have their architectural patch func_statics leak into other visleafs - and did anyone find a way to stop it? Things I've tried so far are to: - make sure all verts are within the room or flat on the wall - make sure the func_static origin is inside the visleaf - make sure no visportals cut the func_static These don't seem to make any difference though.

Something of a ‘What are you working on’ status update after watching countless Blender vids and memorising even more Blender shortcuts. I’m pretty sure by now that every possible combination of ctrl/alt/shift and letters has a function in that program. Here’s a brass lamp Taquito posted in the Inspiration Thread a while ago. I quite liked the style of it so that became the first thing to make a high-poly model for, minus the steampunk modifications. The low poly is at 1300 tris at the moment. The next learning curve is to figure out how to use GIMP to turn photographs into flat model-appropriate textures. Although it didn’t really turn out that bad when I just tacked on the reference photo. The next high-poly was this chalice. The low-poly is at 920 tris at the moment. Just pasting the reference onto the model worked quite well again. They made the bowl with a wavy pattern, but recreating that in a model would cost a few thousand tris. Maybe a normalmap would help, but I've been fiddling for a long time now just in attempts to get the plain bowl normalmap to look... clean without triangles? Also, strangely enough some of the trim details only show up as lone black pixels in the normalmap. Thinking that my DarkRadiant modelling days were over, I tried importing a horse to make a properly fitted harness for my stagecoach that could follow the horse’s animations. But the importer turns up with this error (other md5meshes had no problems with being imported). Google doesn’t recognise this error unfortunately. I'm guessing Blender isn't reliable enough to work with md5's at the moment, so back to my patchwork harness (870 tris including inner faces, no long thin tris). The close fit in this screenshot is slightly on the optimistic side though. Did anyone notice the saddles as being strange for horses pulling a coach? The thing I'm interested in is the headpiece, but all the horses with headpieces also have saddles.

I'm a big fan of the way you... diversify the existing AIs

Ah right, that sounds like the solution. If the normalmaps overlap they could be merged, which avoids having to use the addnormals line.

I'm pretty interested in the implications of this thread - if I wanted to make a model that: - uses a normalmap from a high-poly version - uses a stock texture, which also has a normalmap Would it be right to say the only way to solve the normalmap conflict is to: - duplicate the stock texture shader and let the new one use my model's normalmap - and therefore adapt the high-poly mesh so that it also models details in the texture Also, as far as I know every face needs to have its own place on the UV-map in order for hi-poly normalmap baking to function, which can be a problem with stock textures that weren't designed to fit the model's UV-map. So it looks like stock textures are fairly unsuitable for models that have a normalmap from a hi-poly version.

Thanks - yes there's a sequel underways. Like the first it has adventure and survival themes, and then more substantial gameplay. At the moment I'm getting more involved with Blender to make more sophisticated lamps, clocks, silverware and other objects that would fit into the scenery snugly. Fireplaces too - I can't imagine a mission of this sort without a warming fireplace as a centrepiece of almost every room, but the stock models aren't so great to work with and could really use an overhaul. I'd make a stately brass oil lamp in exchange for a comfortable fireplace. Also, I appreciate your ghosting vid on Youtube, well done for such a thorough completion.

Yes, that's what I was thinking of. My plan would be to either update the prefab with suitable existing lantern models or make a model out of a modified exterior lantern to keep the same style.

Thanks for your comments Sotha. It seems you've had just the experience that I was thinking of when I made this mission, even down to the cabinet under the stairs, which I'm very glad to hear. I think that's one of the best things a FM author can hope for.

Most carriages have external lights, but I haven't seen interior lights myself. Maybe travelling in the dark was considered too dangerous when holes and rocks on the road, let alone the road itself, can't be seen, so the constructors probably didn't see a need for lights on the inside. The exterior lanterns were probably only for decoration because they would be too weak to illuminate the road in front of the horses. Still, interior lights would make sense to allow the occupants to generally see what they're doing. Some might want to read their notes when the coach isn't rocking them about. There's also a gameplay side. It might be more interesting if the player has to consciously stay crouched to avoid being spotted through the windows, rather than being in an easy safe haven. As for what they'd look like, they should be closed and firmly fixed to avoid the risk of fire. Small lanterns like Bikerdude's would fit that description.

Regarding optimising, I used standard textures for parts which were already simple enough to be a shadowmesh, and for parts where it would've been difficult to make a shadowmesh that uses significantly fewer tris. Examples are the undercarriage beams and the curved body panels of the stagecoach with an interior. The closed stagecoach on the other hand allowed for a very simple shadowmesh, so most of the shadow tris there are from the wheels. I've mostly used patches to make the coach so there was less potential for hidden faces than with brushes. If a patch beam is on top of something else I used SteveL's patch splitter to get rid of the hidden side. When converting the stagecoach to a closed version I deleted any faces that could only be seen from inside - much easier with the patch splitter. I did spend some time caulking unseen faces in the sidelanterns because they're made mostly of brushes - very fiddly and could've been avoided by making those out of patches too. That's what I've done, though I'm always interested to hear of other ways to approach optimising.

Great, I appreciate that you looked so closely at it. I also do like that testmap, much more going on there than in mine. It should work to allow AIs to enter and sit inside the stagecoach. Imagine seeing the lord arriving and stepping out of his stagecoach to take up affairs at his estate. Or spotting a noble from afar through the window of his stagecoach, travelling through the streets of the city. Kind of like a crow. The elevator system could be a place to look for a way to transport AIs. The stagecoach would stop - if it stops - inside fitting monsterclip brushes. Then the map would have to prevent that the player alerts/shoots an arrow/gets in the way, physically or with objectives.

Next up The stagecoach in model format. Using the stagecoach is more straightforward and no longer increases the map’s number of patches by close to 1000, which would be noticeable in loading and dmap times. It also allows for skins. Download: [bsolete] What’s in this package: •Models: complete stagecoach with or without interior, also front and rear wheel models, left & right door models, and a version each of those stagecoaches without wheels attached (i.e. if the stagecoach lost a wheel) •Skins: seats in 4 colours or leather for the stagecoach with interior. Windows as default unlit or colorme for the stagecoach without interior in case the default windows should be darker. •Prefabs: stagecoach with or without interior, setup with doors or windows as I’d have intended them. Also 2 unlit candles inside the lanterns. •Materials: noshadows versions of dark_rough, beam_rusty_victorian and the 4 armchair skins. I’ve put the first 2 where the other model textures are to avoid adding clutter to the wood and metal textures menus. You'll find them at: Create model -> darkmod -> misc -> carriages More technical details:

To get a diagonal brush what I do is to make a large normal brush, then use the clipper tool to make a diagonal cut starting from one of the corners. You'll need to carefully count out the squares up and to the side, because making random slopes like 3:17 can cause a mess with the engine. I've restricted myself to slopes of 1:1, 1:2, 1:4 and 1:8 squares. Slopes of 1:3, 2:3 and 1:6 only if there's no other way and if the line can end on a whole number of squares both up and to the side. The .ase exporter in DR is meant to take a group of brushes and patches you made and turn them into a model. That makes it easier and more efficient to use again if you need to use it many times.

Here are the finished sphere lamps: [Obsolete] What's in this package: smoothed models in .lwo format with gold, silver and brass skins, and a steampunk skin that uses a different UV map so it has its own model. They are all available as lamp entities. You will find them in: Create model -> models -> darkmod -> lights -> non-extinguishable -> sphere_wall Create entity -> darkmod -> lights -> model lights, static -> switchable -> electric -> indoor -> sphere_wall The light bulbs can be recoloured with _color - the standard appearance is white. I think the tdm_glare_lamp_01 particle goes very well with a white or yellow bulb. Christmas lamps Steampunk skin More technical details: