Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by MirceaKitsune

  1. Thank you, that sounds amazing! If it works well and fits in I presume we may see this make it into vanilla? Feel free to share a video in the meantime, curious to see it in action
  2. I've actually thought of this exact thing as well! It would be both easier to manage and equally interesting as a mechanic. Very easy concept to implement too: Just add a stim that temporarily changes the light's sound shader for a few seconds before reverting back to normal one, give lights an s_shader_wet spawnarg and include a low volume flickering noise... it should make guards a little suspicious but less than the noise arrow in this case. Just remembered this was in fact a plan for my flash arrow, a custom weapon I've been asking to get included in vanilla but so far it's been forgotten. I believe the last version only blinds guards using the flash bomb effect, but one of the goals was to have lights temporarily turn off or flicker before coming back on after a few seconds, though this would require a custom script at best.
  3. Hmmm. I still like my idea of shooting broadhead arrows at fragile lights to turn them off, but I like your idea as well! It's not like we couldn't use a new item, and it's something mappers would have control of by only placing it on levels where we want to have this behavior. But then we'll have to make all lights frobable by default so even this approach would be a little complicated.
  4. Thanks for those fixes! They didn't affect me and any FM's I've been working on, but I'm happy to see a solution was found and you could help those affected so quickly. I like the idea of being able to customize arrow behaviors from cvars! Most open-source FPS's (eg: Red Eclipse) offer the ability to set weapon behaviors with custom configs and create your own unique balance. While I agree it's good to not have a ton of settings, I think the weapon slots should be customizable this way... at least for now as we remain stuck with the old in-engine weapon system and can't turn the blackjack / sword / arrows into items like everything else.
  5. Part of my point was that breakable electric lights could have an interesting contrast: They'd attract attention while also making it harder for you to get caught. When broken they should create a loud popping noise that makes nearby AI walk to them and investigate the disturbance, if they see the broken lamp even draw their swords and do an alert search... however once they've calmed down and moved on, you're rewarded with the ability to sneak there without being seen. The player will have one of two typical strategies: Either wait until there's no guards nearby in order to shoot a lamp, or shoot such lights if it's better to have guards searching but not able to see you compared to the guards being calm but able to spot you in bright light. Mappers would themselves place those lamps in areas where they want to create this particular challenge.
  6. I understand some changes that break backwards compatibility, long as they're kept minimal and hopefully don't render old FM's unplayable unless patched. We should keep in mind some maps may never get updated, especially ones who's authors might no longer be around... at the same time some things can't be easily improved because keeping it backwards compatible is more challenging, I felt a few things were limited for that reason a couple of times.
  7. Oh, some implementations might work a little differently from what I remember the term megatexture referring to. From what I used to know, it meant turning the entire level into a single model or set that uses a single enormous texture. While the concept may have its upsides, there are two major issues that negate any benefit in my view: The first is system resources, you don't benefit from any reuse as every pixel is unique, the only way to do it at scale is with a gigantic image thus a huge performance drop in pretty much every department. The second issue is that level design becomes far harder and more specialized... while here in TDM we only need to draw a bunch of brushes and place some modules to make a level, an engine based on megatextures would require level designers to sculpt and paint the entire world in software like Blender which is far more difficult and we likely wouldn't have even half of the FM creators we do today, even for those that know how to do it imagine the task of manually painting every brick on every home and so on.
  8. Megatextures were a horrible idea for obvious reasons, not sure why ID chose to learn that the hard way. The concept from what I remember is the whole map uses a single gigantic texture... instead of how we independently pick a couple of 1024 px brick materials for a few brushes and surfaces, the whole map acts as one model with one material and a single texture which probably needs to be 1 million x 1 million pixels even for a small level. This is ridiculous from a perspective of system resources with 100's of GB's of storage and huge (v)RAM requirements and hours of loading time, as well as raising the skills required for level editing since you now need mappers to also be texture artists and sculpt / paint their levels instead of just placing stuff. The only thinkable benefit is there's no repetition since every pixel on every part of the world is unique, but who notices any similarity with independent texturing if it's done right anyway? Detail textures have yet another advantage there: Since you scale the pattern independently on top of the original texture, you can make every surface appear as if it has unique pixels like megatextures. Hence why I'd advice having the details be very high-res, 4k or 8k even 16k if we can take it: Yes that's enormous, but remember we'd only have a few patterns probably no more than 15 in total, and can store them as grayscale then use a single image to modify both albedo / specular / normal (heightmap to normalmap): Map the detail in world space rather than the brush or model UV map, and the resulting pattern on every surface in the world will always be unique since the original and detail textures will be out of sync.
  9. Obviously the change will only work in last night's dev snapshot and onward. But missions can already start implementing this: It's just that older TDM versions won't see the debrief screen and only future players or dev users will enjoy them.
  10. @The Black Arrow That's a good analysis. I don't disagree but we're referring to different time periods with different quality aims: In the early days of 3D and low-res CRT screens when we had 256x256 textures, detail textures were used to make surfaces appear as if they have 1024x1024 textures... today in the age of 1080p monitors such texture can appear blurry from up close, we want to make 1024x1024 textures appear of 4096x4096 quality. Back then the goal was to get at least a little bit of perceived sharpness, today the goal is to see those microscopic details on every surface as if everything is real... while the concept of detail textures is old it scales to cover both aims. As you correctly pointed out, the ideal solution would be upgrading the actual textures themselves. Sadly there are two big problems with this that will likely never be possible to overcome: Someone must create or find identical textures to replace existing ones, which have to retroactively fit every old FM. That would be a huge effort for so many images, and will not look exactly the same way so people would complain how "this wall used to be made of small red bricks which are now larger and yellower which isn't what I intended and no longer line up". An advanced upscaling filter may be able to bump the resolution with good results, this would be a lot less effort and retain the exact appearance of textures. The even greater issue is storage and memory use would go through the roof. Imagine all our textures (from surfaces to entity skins) being 4096x4096 which would be the aim for decent quality today: TDM could take over 100 GB of drive space, you'd need at least 16 GB of RAM to run it, and the loading time of a FM will be 5 minutes. Detail textures are a magic solution for both problems: They're overlayed in realtime on top of the standard textures without changing their base appearance. This means you see pixels several times the scale of the image without requiring any image to actually be at that resolution, no vRAM or loading time increase. And if detail layers are disabled with distance you also don't lose FPS in per-pixels calculations when distant lights update.
  11. Thank you for the lovely change! I wonder if anyone can let FM authors know about it: I think this is a great opportunity to update old FM's if their authors are still around and willing to... if anyone does maybe drop a mention here, I'll be happy to replay them for this addition alone.
  12. Interesting! Does it update all default textures so it's used on everything in the world? I should replay it and check that out: It would give us a good view of how the effect will feel in practice. Looking at the page, they seem to do it the conventional way I was thinking of trying out, which is currently supported by the engine but more limited than a proper implementation. It also looks like they're only doing it for the albedo channel, to be effective detail should be applied to all maps... the normal map is where the improvement should be most noticeable as it responds to lighting and modifies everything else. The implementation I'm thinking of should be universal like all effects and work on any FM new and old. It would be controlled by a menu setting, no one needs to enable it if they don't like how it looks or it impacts performance. Each detail pass should fade and be hidden with distance, we don't want to stress pixel lighting by having it compute thousands of dots on distant surfaces each frame. Just like the TDM ambient method, we'll likely need a special segment for materials meant to indicate what kind of detail each texture wants, then based on settings and camera position the renderer must modify each surface accordingly.
  13. There's been talk over the years on how we could improve texture quality, often to no avail as it requires new high-resolution replacements that need to be created and will look different and add a strain on system resources. The sharpness post-process filter was supposed to improve that, but even with it you see ugly blurry pixels on any nearby surface. Yet there is a way, a highly efficient technique used by some engines in the 90's notably the first Unreal engine, and as it did wonders then it can still do so today: Detail textures. Base concept: You have a grayscale pattern for various surfaces, such as metal scratches or the waves of polished wood or the stucco of a rough rock, usually only a few highly generic patterns are needed. Each pattern is overlayed on top of corresponding textures several times, every iteration at a smaller... as with model LOD smaller iterations fade with camera distance as to not waste resources, the closer you get the more detail you see. This does wonders in making any texture look much sharper without changing the resolution of the original image, and because the final mixture is unique you don't perceive any repetitiveness! Here's a good resource from UE5 which seems to support them to this day: https://dev.epicgames.com/documentation/en-us/unreal-engine/adding-detail-textures-to-unreal-engine-materials Who else agrees this is something we can use and would greatly improve graphical fidelity? No one's ever going to replace every texture with a higher resolution version in vanilla TDM; Without this technique we'll always be stuck with early 2000's graphics, with it we have a magic way of making it look close to AAA games today! Imagine being able to see all those fine scratches on a guard's helmet as light shines on it, the thousands of little holes on a brick, the waves of wood as you lean into a table... all without even losing much performance nor a considerable increase in the size of game data. It's like the best deal one could hope for! The idTech 4 material system should already have what we need, namely the ability to mix any textures at independent sizes; Unlike the old days when only a diffuse texture was used, the pattern would now need to be applied to both albedo / specular / normal maps, to my knowledge there are shader keywords to combine each. Needless to say it would require editing every single material to specify its detail texture with a base scale and rotation: It would be painful but doable with a text injection script... I made a bash script to add cubemap reflections once, if it were worth it I could try adapting it to inject the base notation for details. A few changes will be needed of course: Details must be controlled by a main menu setting activating this system and specifying the level of detail, materials properties can't be controlled by cvars. Ultimately we may need to overlay them in realtime, rather than permanently modifying every material at load time which may have a bigger performance impact; We want each iteration to fade with distance and only appear a certain length from the camera, the effect will cause per-pixel lighting to have to render more detail per light - surface interaction so we'll need to control the pixel density.
  14. It could also be that on Linux we have to compile DarkRadiant ourselves, which means it's being compiled against newer versions of packages (GTK, WxWidgets, etc) and a slightly different configuration overall.
  15. Looks great, thank you! That looks even better: It's where DeusEx had its player status screen, feels even more like TDM with DX characteristics now I think I placed it above the light gem as that's where player info was technically being stored, with the new subtitles covering that position the move is a great decision. By the way: If anyone wishes to continue and improve this mod, I'd appreciate seeing your remixes of it. I had it mostly finished last time on my end; I think the main issue was upgrades require items to be placed on maps, augmentations may not work on every FM without a way for them to automatically spawn in random places... my imagined solution was to also offer upgrades based on loot gathered or other achievements but I never got around to adding that.
  16. I also take it the skin editor isn't among the most used parts of DarkRadiant, making this less easy to spot. Hopefully now the team will notice the issue, and it's ideally nothing hard to fix since DR has a history of GUI issues like this that stabilized.
  17. Sorry for the double report, ran into this myself and quickly posted about it so the issue wasn't missed. Currently the skin editor is unusable: Editing the skin name field instantly crashes DR, so does exiting the menu after making any changes, and any changes you do manage to make are immediately reverted and don't stick. The skin editor is a very useful tool and I hope it can be fixed.
  18. I'll try that: I remember now there's an entity used to call script functions on other entities... show / hide are universal events at the core of the base entity, if that doesn't work something must be very broken. Another option I thought of: What if I teleport the atdm:mover_multistate_position entity instead? However I doubt that will work since to my knowledge, dmap compiles elevator positions to some extent so changing them in realtime will likely not work or break stuff, but just in case let me know if that might be safe.
  19. I have an elevator with a button: When the button is pressed it tells the lift move to an atdm:mover_multistate_position entity, which it does by targeting the elevator while having the spawnarg "position atdm_mover_multistate_position_1" to tell it where to go. This works well but I need it to do something special: When an objective is completed, the button needs to make the elevator go to a different position when pressed from that point on. I don't know how to do this: If I target the trigger_relay that runs when the objective is completed to the button, that will only make the button press itself. I can't use an atdm:target_changetarget either since it's not the button's target I need to change but its position spawnarg. I don't want to make a script for something this simple so I'm hoping there's a special entity I can use to get the job done. One solution would be two buttons: Completing the objective makes the first one invisible and unfrobable while making the second one visible and frobable. But I'm not aware of a way to make buttons visible / invisible either. At worst I'll use an atdm:teleport to swap the buttons, that's an ugly solution so making sure there's no better option first.
  20. If that is made an option, it should be done for both the briefing and debriefing screens. Currently in every briefing I've seen, video comes before the text pages: It would be most consistent to do the same for the new GUI.
  21. Oh wow, that is amazing! It must require a custom script I imagine? Didn't think that was possible even with one and the S/R system, that's very impressive. Definitely curious about a few things: Does it distinguish between collisions with the glass and frame? If the arrow hits a metal part it shouldn't do anything, it should only break if the glass in particular was hit. If the lamp is triggered by a switch, does flipping it no longer turn the light on once it's broken? Can you use a broken skin rather than model? With some lamps it would be easier to only change the skin and replace the glass, of course both should be supported based on what works best for each lamp.
  22. A basic little detail we don't yet have is breakable decorations, I was wondering what is up with that and if maybe we can change it. Mainly thinking of new small decorations: I believe breakable crates or barrels were once experimented with, the entity may still be there but I've never seen them used, maybe someday those can be finished too. Just like metal goblets / plates / vases / bottles you can pick up and throw, it would be nice to have alternatives made of fragile transparent glass. The difference being that when they hit a surface past a certain velocity, they disappear and shatter into glass shards... I believe the fundamental system for this already exists with breakable glass panels? Gameplay wise they'd have a particular property: When they break they should make a louder noise, causing a slightly higher alert that makes AI look there for longer, not as much as the noise arrow but somewhere between it and throwing a conventional object. As a potential penalty, stepping on a small glass breakable should shatter it which is hearable to AI, FM's that use them may encourage being a bit extra careful where you're going.
  23. Yes, definitely needs to be distinguishable. Clear glass with light bulb visible would be the best way: You know that if you see clear glass and the bulb inside you can shoot it. The distinction isn't always possible to make without first trying it out though... paintings are the best example, you always need to get close to see if a painting can be looted. As for players learning about this, we should add those lights to the tutorial level where the basics of TDM are taught: In one of the hallways we'd have examples with the message "solid lights can't be shot, but ones with fragile glass and a lightbulb can be broken with broadhead arrows", the player is given arrows and can shoot at different lamps to compare. As for explosive barrels those would be cool to have too! In their case they should already be doable with a script, just that no one's ever done them: Remove the barrel, spawn the same explosion as the fire arrow or mine, and some temporary lasting physical debris if possible. Breakable lights would need support added to the builtin spawnfunc.
  24. That's why last night I went with the idea of making new lamps with this mechanic: They should have transparent clear glass casing and show the light bulb inside, making it obvious they're different and can be shot. Something like this should make them easy to distinguish: Indeed I run into the painting problem myself: I always check every painting to see if it highlights and can be looted. Then again it's the same with doors in some FM's, which don't use a special door handle to make it clear that's a decorative door and not one you can go through.
  25. Mouse look is essential so no. We should use whatever behind-the-scenes solution of messing with the pointer will work... once Wayland or WxWidgets or GTK3 will offer one, it's kind of on them that they haven't up to this point. Until then Jonri's PR works by forcing the X11 backend, which isn't a real solution but in practice solves everything for now. Here's a modified snippet of what I did in PyGame which works. Obviously this code has no effect, just an example to show what works in my project, just in case it's a similar situation here: Maybe Wayland expects us to hide the mouse pointer at a core level before it allows locking, and the reason it doesn't work is DR only hides it visually at top level? pygame.mouse.set_visible(False) x, y = pygame.mouse.get_pos() pygame.mouse.set_pos((x, y)) pygame.mouse.set_visible(True)
  • Create New...