MirceaKitsune

Ah yes: Copying alsoft.ini to an alsoft.conf makes the changes there matter. I've been playing around with some of the settings now. So if I use anything other than "drivers = alsa" I get no sound. ALSA seems to be the only one it will work with, or the others need to be further set up. Preliminary testing shows some great news: I may have found the culprit! The issue appears to go away once I set "period_size = 64". Going at the other end, "period_size = 8192" also doesn't seem to do it oddly, but that causes a huge delay for all sounds. The issue is when I set it to a middle value like "period_size = 1024" to "period_size = 4096", that's what seems to cause it almost constantly... the distortions differ slightly based on this value. I can even add other improvements like "frequency = 48000" and it works! I'll update if I still encounter it with these changes too. In the meantime please consider if based on this results, it might be a good idea to change the default value of period_size to something lower, seeing how this helps solve the problem. Any reason why it can't be 64 by default? The problem only seems to occur from 512 (very rare and brief then) and up (almost always starting from 1024), even a 256 should be safe if a slightly higher default is needed for other reasons.

Thanks, that clears up quite a bit. I now remember reading about those frame commands briefly a while ago. This sort of thing is why I love idTech4... people can point out it's a 15 year old engine all they want, it's still cutting edge tech to me So simply giving the AI an animation with effects using a path_anim node should work, the effects happen automatically for existing ones? Like peeing animation has particles, dice playing animation has the dice roll sounds, etc? I'm still assuming that to override the animation of a specific AI, I need to use a spawnarg on either the path (ideally) or the AI entity. Like if I want the AI to walk using a specific walking animation, can I give the path_corner a direction in that sense? Or like my previous example... if I want an AI to sit on the ground using the beggar animation, can I tell path_sit I want an override when the AI uses it?

How did I miss that? I just tried it but apparently there were no changes, neither value affects the issue. I'm fairly certain some options there should have stopped the audio from working at all though, so maybe alsoft.ini is ignored? It's an ini file after all, those are usually for Windows not for Linux. Digging through my notes from back when I had sound issues with the 32-bit engine (RIP at long last) it seems I was able to add "seta s_driver oss" to Darkmod.cfg instead. However I just tried this now and even when I set s_driver to all of those values nothing happens. To my surprise, if I don't attempt to set the cvar at all but check its default value, s_driver is now seen as unknown when I type it into the console o_o s_device is there though. It defaults to "default". I tried changing it but this does nothing either. I also used tab to look at the other cvars beginning with s_ but nothing relevant jumped to my attention... surprised there's nothing about the buffer length which is where I suspect this might be coming from.

It's a small bug with an obvious feature, no crime in reporting it. Smaller things have been reported over time. Some bugs take years to fix (as a general rule, even outside of TDM) so I'm sure time can be found at the devs own pace. Any thoughts on my last question about complex character animations and effects please? I forgot to add another little question to it last night: Whenever I design the bathroom of a house, I run into having no proper toilet and sink... there is a metal bathtub that's perfect but what about toilets and sinks and maybe even a cabinet with glass doors? I know I've seen them in at least a few other FM's, I think one was Not An Ordinary Guest which had complete and modern bathrooms in its hotel. Also I've seen some FM's with marble floors that reflect a cubemap. What are the reflective types of stone called so I can find them in need? I've experimented with different textures in the Stone directory but never found shiny surfaces.

Thanks: Changing the "gravity" spawnarg in worldspawn does just what I want. Though like many untested features it's not free of bugs: The player remains stuck in the air after setting that to any custom value, they only fall again if they are moving. No idea why horizontal movement is required for vertical movement to work then, I need to open a bug report. I was going to next ask how I can create AI conversations using the existing voices, but I already figured that out easily: You can explore any voice on a speaker, then even point directly to that ogg file from the conversation editor. Something I couldn't find on the wiki still is how to have characters do some more complex animations; I already know how to find an animation in the "md5 animation viewer" then set it on a path. But for example: How do I override the default idle animation, or walking animation, or sitting animation... so when a character normally does those things they use a special override for each one? For instance: When they sit down, sit like a beggar instead of like on a chair. I've even seen some FM's make guards pee on trees (particle effects and all) but how is even that achieved? Also many FM's have characters armed with non-standard weapons, like spears or maces... where do I find those in a format that allows me to def_attach them on an AI so it also changes their fighting behavior? And I'm assuming that if an animation doesn't show up in the md5 viewer, something like it doesn't exist? I was hoping for a few extra ones... such as praying (eg: for builders) or dancing (could have sure used that at the banquet in my FM).

Still dealing with this issue and it's becoming a huge annoyance, would greatly appreciate a suggestion against it! Most of the time when I start up TDM, I have to wait between 10 seconds and 1 minute for the sound shuttering and slowdowns to stop, everything is unplayable while this goes on. There must be some setting related to the buffer or something that is behind it. What do you suggest toying with in the settings for starters?

Had a longer discussion on Discord about the lights (thanks go to @peter_spy for offering quite a bit of help). In the end I figured out a way to obtain what I want... a little hacky if you're strict about the setup, but I looked into every method I'm planning to use and everything seems to be in order not something I'd expect to break in future TDM versions. There was another list of things going through my mind, as I'm trying to take notes for multiple features I plan to use at various points. To count down another question off my list: Is there a map setting that permits me to have lower gravity? Yes, I know this isn't scifi and I'm not trying to make space ships or anything (hmmm... should I though...): I'm thinking of using this for stuff like surreal realms or hellish worlds and that sort of thing. I'm okay with the setting being universal to that map (not area based) but will want it to affect everything including the player (who can jump higher and fall more slowly) as well as physical objects like if you pick up and throw a candle.

So I'm kind of getting the desired result if I first convert my brushes to a func_static then change the classname to light. The problem is that this appears to cause bugs at least in the editor: You need to do this conversion at origin 0 0 0 otherwise the mesh will appear offset. Even if you do this however, the model won't move when you move the light in DarkRadiant, although its vertices appear in the correct position... looks like a bug to be honest. Update: I found a way around this particular problem! What I need to do is the following steps: Create my light brushes and convert them to a func_static. Separately create my light entity somewhere nearby and give it all the needed properties. Look at the model number in the name on my func_static entity. Then select the light entity and give it the property "model func_static_1". Now the light will use my brushes as a model without any glitches! Only problem is that this method raises a few questions: What happens if I delete the original func_static, can I do that or must I keep it somewhere on the map separately? In fact, what if I were to export this light as a prefab, without the original func_static entity included... would the brushes be exported accordingly with it and stick? Update 2: Just answered my own question. Unfortunately the original func_static must also be placed somewhere on the map, if I remove it the light's model turns into a black box. In this case: How can I make the func_static completely invisible and non-colliding, so that it's only there to be referenced but its mesh is only really used by the light entity?

Yes, that is correct: This isn't a flame light, it's an electric light. No particles and the light will flicker ambientally. I already have the light source entity which works perfectly, buzz sound and the light flickering with its intensity and all... the main issue is the light surface being synced with it at all times. So is it official that I have to export the model to ASE to make this possible? No way to make my brushes func_static or another entity then have the flickering light translate its intensity to its texture? Because I really preferred it this way for my use case, I plan on directly using brushes and patches which I'd rather not convert to a mesh. Also where do I find a material ending in _snd useful for a light surface? I'm only aware of the ones in "lights/" but those are intended as projector textures for light sources and not textures to be put on surfaces directly.

Alright, onto a new question. I was going to make an unique thread for this one as it's a bit more complicated, but I seem to have some stuff figured out and only need help with the last part now. I'm looking into how to define an electrical light that flashes and flickers ambientally. The light source itself is no problem: I can create either a plain light entity or an atdm:static_electric_light_nomodel_lit (this works better for my use case) and with the following properties I can customize it to get precisely the desired result: light_center 0 0 0 light_radius 128 128 128 s_looping 1 s_shader light_flicker_104 texture lights/biground1_squarelamp_snd _color 0 1 0 But now comes the complicated part: I want to create the light surface out of brushes. You can think of them as the filament of the bulb, their purpose to provide a full bright texture synced with the light source. The brushes are converted to an entity (eg: func_static); How to make the faces appear fully bright, have the same color as the light, and flicker or turn off with it? First thing first: What texture do I even give the lit face(s) of the brush so it becomes a light surface? I noticed you can hack by giving your brush a texture from "light/", however the texture browser doesn't normally let you browse there when texturing geometry so it's probably not normal. There isn't a fitting texture there anyway, as all light textures are squares or circles fading toward the edge, what I need is a fully white texture which ideally has some spots like a neon. Once I were to solve that, the second and last question comes: How do I connect this brush entity to the light entity, so that it copies its color as well as the texture intensity while flickering with the light source? Would a simple "bind" do, or perhaps a "def_attach"? It should be noted that ideally, this is a light the player can turn off and the AI should notice it's out... therefore the brush texture also needs to respect that and become black if the light source has been triggered off. One last note: I tried to do everything in one entity, by converting my brushes to a func_static then changing the classname to light. However this seems to break stuff: Even after a dmap the brushes are moved and distorted, light entities clearly don't like being given a model. Thus I'll probably need two entities in the end (the brushes func_static and the light source) with the light source telling the brushes how to colorize their light faces.

Okay, I remember now: There's oddly enough no proper way to change the scale of entities. You do it from the rotation field which I hear breaks stuff in general. Very odd design choice when idTech4 was created, using rotation to define scale and only having that work on static entities.

Character rescaling? I'm assuming it might require some changes to the AI system, since the bounding box and similar modifications could break pathfinding and more. Oh... and joint attachments, not sure how keys attached to the hips and such would behave. Down-scaling an animated model should otherwise work I imagine, but probably not the rest.

Ah. Why would you need to downscale the model in Blender though? It should be simple to just give any entity a different size! Might not be worth the effort in this case, even if I could probably do it that feels overkill... I was hoping to play with the idea using just simple def edits. Maybe I'll try giving an AI the same scale parameter used to resize func_static meshes, curious what that would do.

I've had a question for a while, good to look into while I'm still experimenting with a test map; I was wondering if it's possible to change the size of an AI, even by defining your own atdm:ai_* character in a custom def file. Is it theoretically possible to create midgets or giants? I'm not aware of a "size" parameter that can rescale the entire AI. If it were possible, I'm assuming the path-finding algorithm needs to adapt and understand when an AI is too big to walk through some doors or small enough to walk through spaces not accessible to normal people (eg: vents). It would also be wise to re-scale the damage such an AI can deal, so shrunken characters deal less damage per blow while enlarged ones more. In addition: Is it possible to change the size of the head relative to the body? Would be useful in cases where you want a character with a smaller or larger head. Similarly I'm assuming the head definition must allow some scale parameter.

As a general rule: I think other alternative ideas are very good to consider! For the purpose of this thread though, especially now that I managed to get a working patch, I'd like to focus on the functionality in the pk4 I posted. If such an arrow can become a default feature, extra functionality could be added to it now or later. Like I said I think the flash part of the arrow works perfectly with my implementation, as in it's exactly the result I wanted. On top of this functionality, I agree the arrow could have the effect of knocking out electrical lights temporarily or making them blink. I wonder if for this there's an additional stim I can add to the result def; Could anyone suggest the sr settings I'd need to use for electric lights? If it helps to have it readily available for examination, here's the result def of the flash arrow: entityDef atdm:result_arrow_flasharrow { "inherit" "atdm:result_arrow_base" // Define a new scriptobject "scriptobject" "result_flashbomb" // parametric particles -- temp "model_dud" "flashbomb.prt" // placeholder arrow break sound for now "snd_dud" "tdm_flashbomb" "def_flashlight" "atdm:light_flashbomb" // The spawned light if the flash is not directly in sight "gui" "guis/playertools/flashbomb.gui" "copy_bind" "0" //warning: changing remove_delay cuts the particle off in mid-animation! "remove_delay" "5" "sr_type_1" "24" // STIM_FLASH -> script/tdm_stim_response.script "sr_radius_1" "500" // Radius in Doom 3 units "sr_falloffexponent_1" "1" "sr_duration_1" "100" // stim duration 100 ms "sr_time_interval_1" "120" // fires only once } As far as knocking out robots goes, the only robot so far being the steambot, I think that makes sense too. But for this to work, the steambot also needs to be changed to allow a sr response for taking it down, which my arrow would then need to call (same thing as for the electric lights).

I figured white would be a better color in the end considering that's the colorization of the flash itself. I improved the material and textures slightly so the arrow tip looks bright and like it's blinking, as well as creating a proper GUI icon that represents the aspect of the tip correctly. In addition I figured I'd mix things up a bit from a gameplay perspective too; I made the tip glow so the arrow will also draw a bit of attention. While having the Flash arrow selected, you'll become more visible similarly to holding the Fire arrow, but to a much lesser extent (only 3 lightgem levels instead of 15). This means that using it will ever so slightly make you more noticeable if a guard is standing nearby, though it won't completely blow your cover if you're hidden in complete darkness. Anyone here a FM developer? I'd like to see this added to a mission to be tested in practice. Perhaps share a video if you do that, I'd love to see how the idea works! flash_arrow_1.1.pk4

Aaaand here's a working pk4! Super easy as expected, just define a new arrow then give it the same result def as the flashbomb. I edited in a different arrow model and texture too, the little details and effects still need tweaking... since this color is unused and common to describe lightning I went with purple / pink for now. From my testing the arrow works exactly as intended, and this could just be considered the final functionality as far as I'm concerned: It temporarily spawns a bright flash, making the guard say "ah a flash" rub his eyes and cease searching for a few seconds. Note that it can in fact blind the player too... however this only happens if the player shoots it right in front of them, if you shoot it in front of something over 3 meters away (as you always will) it only causes a short white haze. flash_arrow_1.0.pk4

I don't plan on editing the default flames, that might mess up what was done in development. That also sounds a bit more complicated... I'd have to rewrite the particle definitions as well as re-texture the flame images to use color maps. And since the red tint of the texture applied on top of the particle color looks nice, I would rather leave it as is for now. It's good to know this is a possibility in general none the less!

New update. I didn't quite like how the pink flame looked, too unrealistic and illogical for a fire. I thus converted it to a purple flame which I feel looks a lot nicer! Violet flames are common in magic too so it's a better choice for this reason as well. color_lights_1.2.pk4

Nice, I didn't know you could do that. Perhaps I could use it to have a single colorable version of each flame type? How do you do this though, as in allow the color of a particle to be specified from the light def rather than coded in the prt file? I ask most questions in Newbie DarkRadiant Questions. Usually I only start a new thread if it's an idea that warrants its own discussion or something I produced.

Thanks! I'll wait for that to make it into the master branch then pull and compile again.

Updated to use better naming and editor folder paths. color_lights_1.1.pk4

Following the release of my first FM I wanted to offer a little surprise to the TDM community. I've implemented a little feature I wished to have for a while: Colored flame lights! This covers all fire based light entities, meaning all torches and gas lamps get versions with colored flames. They work the same way as the normal flames in terms of functionality, meaning you can move candles around and water arrows put them out and the player can relight them with matches. Colors include: Red, green, blue, pink. The implementation is very flexible: Each color variation inherits its original entity and only changes the light color or particle definition, thus changes to the base def will automatically reflect to the colored versions during development modifications. The colored entities replicate the same DarkRadiant tree structure as the normal lights directory except in their own subdirectories. I'm eager to hear what you think and if you like them! My goal is to offer this submission for vanilla TDM, ideally as a new feature for 2.09... I think they would look very nice for many fantasy setups! And of course, here are some screenshots of how each color looks in-game (red, green, blue, pink): The pk4 is attached to this post as it includes only particle and entity definitions so it's ridiculously tiny. You can install it in one of two ways: Either unpack its contents inside the directory of your fm, or copy the file as is inside the darkmod folder next to all the other pk4's... both should work just fine. color_lights_1.0.pk4

I'll be honest: I never once used either the Flashbomb or Flashmine, always saw them as pretty much useless. Nothing's ever motivated me to use them, I just pick them up and forget them in my inventory. A flash arrow on the other hand I would definitely use, it's an item I can see myself making practical usage of. My idea is combining this EMP arrow with the flash arrow; When the arrow hits a surface, it will blind any AI looking, while also making electrical lights go out for a limited time. We could also disable the ability of the player blinding themselves as they can do with the flash mine / bomb, if it's proven that this is an annoyance. Which BTW I remember didn't work anyway when I tested this... the arrow made the AI rub their eyes, however the player didn't get blinded when seeing it explode. Anyway turning off electric lights will likely require gamecode / script changes which I don't know how to do. What I think I will do in the end, because it's so simple, is adding the new arrow definition with the same effect as the flash bomb: Anyone with a FM can download my pk4 and temporarily add it to test its practical effects before we make those funky variations. I'm currently working on another little asset addition I'm thinking of proposing so perhaps after I finish that.