Jump to content
The Dark Mod Forums

Leaderboard

Popular Content

Showing content with the highest reputation on 11/09/24 in all areas

  1. What a wonderful, fun and visually striking map! It has a BUNCH of 1st's for TDM: I hope there are 7 more Voltas' in the works. IMHO: it IS the TDM campaign.
    1 point
  2. aye though the GLSL renderer is wholly unobtrusive and can be disabled completely if anything barks leaving just the ARB2 renderer. Ill see what he says to it .
    1 point
  3. Cool stuff! If you wouldn't mind, maybe submit a PR to the Dhewm3 git repo for the AVX \ SIMD things? ( Not sure Daniel will go for the GLSL changes )
    1 point
  4. That's amazing, thanks: I'll give it a try and see how the prefab elevator does it to double-check. For breakable windows, I can confirm they work well for a horizontal panel you can break to enter buildings through the ceiling. My little church shall be using that as one point of entry. Speaking of elevators, I went ahead and made the windows for my elevator breakable too. Not sure how much sense it makes and if it looks too weird but I'll take it. func_fracture seems to handle itself nicely when bound to other entities.
    1 point
  5. It will still glow in complete darkness a little bit. Plus, fainter reflections look less like metal and more like a clear-coat type of shader.
    1 point
  6. the hybrid renderer could probably be modified to also handle shadows in GLSL . im also using an RAII style depthbounds checker for both the shadows and lighting. the gamma correction works mostly with sikkmod but there is one oddity i noticed. while the world looks fine with it character faces go way bright. not sure what problems the softparticles have but it was noted by the dev himself that some stuff might look wrong with it. the VBO code was also replaced by a more efficient version originally written by michael hiney from insideqc. It is not a total rewrite like the version in TDM that uses the BFG version, instead it uses MapBufferRange and some optimizations. the GLSL hybrid renderer was mainly made to allow older mods to still work and it is quite solid by now having ironed out the last bugs with it years ago.
    1 point
  7. @Dragofer Here are the subtitles for this mission. I completed the mission. I'm very impressed by the quality (even after having read all the praise about it before), although I found the ending a bit abrupt and I didn't fully get it. Maybe it's also possible to do the suggested fixes to the river_fading_materials.mtr as mentioned in the other thread? subtitles_river.pk4
    1 point
  8. I set it up and it works wonderfully! I'm actually not encountering any issue with func_frature on either a plane or brush, it just works without even having to change anything beyond the health spawnarg! Had some fun with it already and might use this in even more places. And it automatically handles sound occlusion if placed over a visportal! You hear outside sounds muffled until you break the glass, then you can hear them loudly which is quite awesome
    1 point
  9. So I use a func_fracture entity to make breakable glass, as I think this gives you a bit more control over things like shard size, shatter sound, etc. You can even trigger things such as func_emitters or lights. For Eye on the Prize, I used it to trigger surface emitter patches to make it look like it was raining inside the greenhouse once the window had been shattered. You are welcome to take a look at that map file to see how it's setup.
    1 point
  10. WIP mission name confirmed: "The Last Offering"
    1 point
  11. Weird! Go to fms/wizt, delete darkmod.txt inside or the whole folder and then redownload the mission.
    1 point
  12. The installer should automatically reset the settings it changes and leave the rest intact. Currently it resets all settings (default) and gives the option to preserve the settings, but no clue if something will break. Apart from that I think the installer should tell you what is going to change before installing, so you can more easilly make the decission.
    1 point
  13. If you are right behind the guard his body should actually block his vision. If that's not the case then I would consider it a bug. But you really would have to stand behind him, not somewhere to the left or right of his back. If I find the time this weekend I'll take a look. Regarding rng: If the player is aware of the head turning, then all it does is to increase the ai's fov, with the difference that there is an area in front of the ai where you are always visible and the area to the sides where you are only occasionally visible. And as the ai doesn't tend to turn their head like a lighthouse tower there should be an area in their back where you cannot be seen. From my experience this is the case, but as stated above, there might be occassions where something goes wrong. However, I wouldn't consider such a setup random. If you stand at the ai's side you know you will get spotted. The only thing you don't know exactly is how long it takes.
    1 point
  14. I think it doesn't hurt to let the default be on low, less challenging levels. However, it might be worthwhile to somehow communicate it to players that they can increase the settings further (and may do so once they played a bit to get the experience the mission authors are aiming for) should communicate to mappers that acuity settings are more or less average values that need fine-tuning depending on the situation/geometry the ai is used in. I fairly doubt that there are a lot of mappers, if any, who actually make adjustments to that values. It may also be a good usus (by mappers) to make it difficulty dependent (even Thief Deadly Shadows did that)
    1 point
  15. The bits are the digits and the byte the whole number (a bit simplified). It basically means that you use a number of which each digit represents a specific state. Similar to how they work in everyday life, where each digit corresponds to the amount of different numbers (ones, tens, houndreds, ...), just that now they stand for different keys. But as stated this level of abstraction is not needed here. Yes, but it is mostly 6 grade maths I dunno if it is bokers, as it depends on what you are trying to achieve. I think I just don't understood exactly that. My interpretation of what you have written was that one key (22) opens door A, the other (47) door B, but having both (69) also allows to open door C. The last part doesn't make sense to me, so you probably meant it differently. Just for learning sake as you implied: The bit approach would be like one key is 10, the other is 100. Having both corresponds to 110. But it also works the other way round, as there is no other combination of keys that lead to that number. Or more in detail: Say you have 4 keys. key 1 corresponds to 1 key 2 corr. to 10 key 3 corr. to 100 key 4 corr. to 1000 So depending on which digits are nonzero, you can exactly say which keys the player possesses. Is the number 1011? Then he has key 1, 2 and 4. The power of two stuff comes into play as computers use binary numbers, not bundles of tens. The math is the same, though. The number bundled is completely free to choose, has not always been ten in the past (just think of the clock or the names of the numbers) and is only ten nowadays because we have ten fingers.
    1 point
  16. The interesting fact is that whenever you pick up an item (even loot), the entity is only hidden and remains in the world, while incrementing a counter in your inventory signifying that you're considered as possessing such an item. You could probably check whether an item is hidden to determine whether the player has taken it. The pitfall is probably when dropping stackable items, since I believe items lose their identity when they're stacked, so when you drop items from a stack new entities are spawned. Well, what we really could use is a robust, in-engine way of determining whether the player has an item in his inventory. You can currently only check the current inventory item of the player.
    1 point
  17. @datiswousTwo thoughts (or cents, so to say): As @Nort stated, the usual approach is to use bits if it is just about whether a key is present or not. So each key would be represented by a power of two. I don't really see why the player should be able to open door 69, just because he can unlock 22 and 47 (as in your example, which I probably misunderstood). The reason for the bit approach are to not waste unnecessary resources. The downside is, that it is a bit abstract. And as this will not hurt performance a lot, the bit approach is not necessary here, though. Stackable items are items like flashbombs. Note, that even though there appear to be several entities in the inventory, it is actually only one. Using it, will decrement the counter, and if it reaches zero, the item gets removed. You can obviously not differentiate between objects if it only one. Now, how will one go about this?! The most straightforward approach is, that if the player frobs a key, it gets removed (not added to inventory!) and a spawnarg is set on the world entity, denoting that the player has the key. Note, that if you readout a spawnarg on an entity that has not been set, it will return 0. So we just add something like "name_of_key" "1" to the world entity. If the player frobs a door, the modified version of the script will readout that spawnarg which is either 0, if it hasn't been set as the player hasn't picked up the key yet, and the door stays locked, or 1, which will lead to the door beeing unlocked. So basically two script functions: // the frobaction script used by our keys void frob_key(entity key) { string name_of_key = key.getKey("inv_name"); $world.setKey(name_of_key, "1"); key.remove(); } // door script void advanced_frob(entity door) { if (door.Locked()) { float unlocking_key = door.getFloatKey("used_by"); if (unlocking_key) { door.ToggleLock(); } } else { door.ToggleOpen(); } } This is without the lockpicking mechanism. I would have to check, whether the immobilization is still correct (as stated above, the number confuses me). Note that this is untested code that came to my mind. It probably includes wrong written stuff and has the potential to destroy the universe. Use with caution
    1 point
  18. This is a mapper decision. By default, doors do not close automatically. However, it is possible to set the to do so and normally used in haunted mission (because it is spooky ) For the rest, like @AluminumHaste said. If it is easy, why don't you do it yourself. If you can't do it yourself, it maybe isn't that easy
    1 point
  19. 1 point
  20. I believe that is Lords and Legacy, it was an optional objective to find his identity
    1 point
×
×
  • Create New...