Search the Community

I've mostly used Cubase earlier, but have switched to Reason for it's midi capacities. I was wondering if any others use Reason, and maybe if you have any general or specific advices concerning making ambient music in this program? Let this be a thread for us (I presume there are more than me) who use Reason and who want to share our thoughts, tips and tricks about it with the other contributors/team members. Since I believe most people that make ambient music use Reason, I thought this thread justified in the DarkMod forums. One thing in particular I would like to know is recommended patches for bass ambience, like the one in 'Outside the Mansion' and 'Defiled Church'? I've tried a lot of patches, but can't find any that really has the right Thief-sound, not necessarily like in the aforementioned tracks mind you. (I may just be picky, but that's better than sloppy methinks) /K

The model lights/extinguishable/hlamp.lwo has an origin WAY outside the visible model. This wound up costing me some time as it caused a leak in my map that I couldn't track down. I suspect the same thing could happen to other people, so I would like to move the model so the origin is somewhere that makes sense. Problem is, this is a popular model and it will no doubt mess up a lot of maps. Another option is just creating a new version of the map (which has the added benefit of allowing me to name it properly) and we could move the existing model to a map_specific folder (so mappers could just do a text search and replace). Opinions?

Ah, uploading at the forum doesn't work. The files are in my folder in the bm repo now. I used standard settings to save them (something like dxt1 rgb no alpha). I had to expand some of them a few pixels cause their dimensions were not multiples of 4. Could that be why the compressonator couldn't handle them? Hope this was not something I should not have done. Let me know if they are ok.

So....how many of the changes I just finished making to the mesh two weeks ago are now obselete? http://forums.thedarkmod.com/index.php?s=&am...st&p=151102

I think there is some misunderstanding about my problem with the entity list size in my post @ http://forums.thedarkmod.com/index.php?showt...st&p=142541 It's not the panel size (though that needs saving as well) but the entity list itself (see the image of waste space in the picture in that post and the tiny entity list.) So this problem is still present in the latest snapshot. I only see 2 or 3 lines of entity properties with a very large empty panel. Does nobody else see that?

You were right, the texture looked completely flat in fast ambient. I added some kind of filter stage now to darken the edges that is only present in fast ambient. This is with standard (rebb's version) and fast ambient: We also have some other textures that look too flat in fast ambient (especially in the stone/sculpted folder, I can add something similar there. The more technical stuff: I took the blue channel of the normal map and inverted it, also changed brightness/contrast and scaled the image down (no need for a large image, 256x128 was sufficient here). Then I added a stage to the shader that inverts the image and scales the brightness with the globals, so that the edges will become darker the brighter the ambient is: { blend gl_zero,gl_one_minus_src_color map textures/darkmod/angua/protruding_bricks_filter red global2 * 10 green global3 * 10 blue global4 * 10 } One drawback is that it also darkens the edges in areas which are not only lit by ambient, but this is not really a problem in this case.

Yes, that was fine, though I thought if there are going to be a lot of nominees, a longer hallway with labels might be needed. Based on the results of that map, the whitish one should be deleted, with Dram having a chance to move it to his map_specific folder. The other one should be posted in the texture forum and see if anyone is willing to update it (or did someone volunteer already?). If there is no one willing to update it, then remove it as well. I'd like to see a big long list of nominees rather than do one or two at a time, however. It's too easy to quibble over one or two textures, where if we post twenty, people will generally agree on at least a dozen.

You're right. Consider this permission from the Art Department Lead to proceed in the following way: 1. Ask for nominees. Anyone who wants to nominate a texture for removal can post it here. 2. Make a testmap of all nominated textures--preferably a hallway where people can walk down and gaze at examples of any nominees (perhaps with texture name or a number added for easy discussion). Would you be ok handling this Sneaksie? 3. Post somewhere clearly that the map is ready and people should check it out. People should ONLY respond if they strongly disagree with a texture being removed. 4. After a reasonable period of time (two or three weeks, perhaps), any texture that has NOT had someone speak up on its behalf will be deleted from SVN. If a mapper still wishes to use it they must add it to their map_specific folder. 5. Any textures that get an "I'd like to keep it but it just needs a little work" response should be posted in the texture thread. If someone volunteers to fix it, fine--it can be recorded on the bugtracker. If no one volunteers to fix it, it should be removed from SVN. Unless there are strict objections to this method, just DO IT.

Which demo do you have installed? Saintlucia or Thief's Den? For the former, you need to point the fs_game path to the "saintlucia" folder, for the latter to "thiefs_den".

Yeah, if /map_specific isn't part of TDM distribution (and it shouldn't be or else it's pointless), then keeping the texture in question for blackheart, or making a blackheart.pk4 to go along with the map distribution, lets the author (Dram in this case) keep whatever texture they want. It's no different than for example Gleeful coming back, working on a map, making a bunch of textures for himself, and then including them with his package instead of giving them to the mod. We just have to make sure the /map_specific folder and such pk4s are not part of TDM distribution. The tag proposal is also interesting; if I understand correctly it would show us what isn't being used at all, allowing us to decide easier.

Yeah I think I agree with all lights (source, fixture, moving) being kept in subfolders under one master /lights folder.

From a still confused and fresh viewpoint, it seems that "light sources" and "lights" could be merged. The former includes candleflames and the latter includes lamps. Close enough. They're still both sources, and both "lights". Then we can hope that if users want something that moves, they'd check the moveable dir. Gets rid of one folder at least. I dunno, the whole thing is confusing as hell. I'm not sure even why we still have "atdm:" prefixes, as they don't help in this type of case one bit, and in fact make it worse. Our stuff is separated off from unusable D3 stuff, and our stuff is not consistently named anyway. And the "a" is just about sorting, but it doesn't help when you have an "atdm" item next to a true "a..." item. There's a current DR issue requesting within-string search for the type-ahead stuff, which is currently defeated by "atdm", and the prefix will become even more irrelevant if that request is fulfilled.

Since these were sorted by me, I defend it here: "Light sources" - lights without any models "Lights" - static lights with models "Moveable/Lights" - models moveable lights Now I admit I was equally confused the last time I looked at them. But then, how would you sort them? If you put "moveable lights" under lights, people will look for them under moveables. etc? However, feel free to resort them so that it makes more sense, usually you only need to sort the base class into a new folder with editor_DisplayFolder and it is done Btw, I moved the Arrows to "Internal" so only "Weapons/Ammo/Arrows" remains and the mapper can't accidentily put the arrows that are attached to the weapon into the map

Two textures are currently nominated, and displayed in test/texchop.map. I somewhat favor the suggestion of chopped textures which are in use and still wanted (e.g. Dram's one) being moved to a /map_specific folder. The only misgiving with that is, I am not sure it helps the situation. The maps using these textures right now are in a sense "core" maps, in that they're being developed along with the mod, right now. So the textures sit on SVN anyway. They're still taking up space, and they're still available to all connected for use. It doesn't really cull the texture at all.

Yes, removing them without warning is not necessary. I've already suggested what I think makes the most sense: Add any nominated textures to a chopping block map, let people test it and give feedback. If no one speaks up on a texture's behalf after a reasonable time, it can be removed. If someone speaks up that they are using it, but it is terrible (like the one Dram is using), then it can be moved to a separate texture/map folder (which already exists for this purpose) so the mapper doesn't have to retexture anything, but the texture is essentially out of the repository (it would be distributed with the map, not the main mod).

Fidcal also has been working in this, you can see his thread in the member forums below

I think that's to be expected when a department cruises along without a head for about two years now. I think Dram's suggestion makes sense. Nominate all the textures that are questionable. If there is no loud disagreement, and they aren't being used by anyone, delete them. If they are being used by someone, then they could potentially be removed from the main texture folders and put into a specific texture/map/ folder. That way they're out of circulation but it doesn't wreck anyone's map.

Anyone had any luck creating this cemetary folder?

Now that I think of it. A decal that makes surfaces look fungi might be useful. That might eliminate the need of making special fungi textures like the ones in the wood tex folder.

Why would we make new ones when the D3 ones work perfectly well? (though there are at least a dozen ones in the our decal folder as well)

Uninstall Doom 3 first, delete the folder c:\games\doom3 (backup any saved info you want to keep first). Install Doom 3 again, apply patch. When you browse to the proper location with the patcher make sure it doesn't add "Doom 3" to the end, if it does delete this.

Not sure how that works, but just a single parent folder outside I'd guess. Almost like a wastebin.

It would solve the problem of people not putting all the files in the right place (since the installer would do the right thing for them), which seems to be what has caused your problems. Extracting the Saint Lucia package directly into C:\games\doom3 (not into a subfolder) is the correct procedure and should have avoided at least your original problem (and possibly this one too). Could you show us your Doom 3 folder structure?

Ok I managed to find the Devill.dll file and put it in the system32 folder. But the same problem occurs. Any other ideas?

Oh on the Doom3 forums they said that parallel lights should be at least twice the size of the map link Relevant part: This also tends to make parallel lights dimmer than their point light counterparts, so you often need to increase the physical size a parallel light's volume well outside the area of a map you want to influence in order to get an equivalent brightness to that of a point light. Keep this in mind when designing maps that have outdoor and indoor areas, you need to keep and eye on light volume overlaps.