Jump to content
The Dark Mod Forums

Search the Community

Showing results for '/tags/forums/petike the taffer/'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

  1. Currently if you are implementing EFX in your map, you need to maintain an .efx file: https://wiki.thedarkmod.com/index.php?title=Setting_Reverb_Data_of_Rooms_(EAX) If you are using presets only, all this is is simply a 1:1 mapping of location entities to an EFX preset. Doing this in a file is kind of tedious and error-prone, as you have to check each location entity in your map, and then check the file to make sure you got the location entity name correct, or didn't leave one out, etc. Would it be a worthwhile feature request to be able to just set the EFX preset with a spawnarg on the location entity itself? Something like: "efx_preset" "WOODEN_SMALLROOM" Also, the location entity has other zone-related information, like ambient sound, ambient light, etc. It would just make sense to have the EFX here as well. This would only make sense for the presets, since you just need the preset name. If you wanted to do anything more complicated, the file could still be used. If both are used for the preset, one could take precedence over the other (the spawnarg pehaps). I don't think anything would need to change in DR either, as it's just a new spawnarg on the entity.
  2. This shows willingness. I will check where we stand today. The goal: players.
  3. I couldn't help thinking of another realism related suggestion, don't know if it was discussed before but it seemed like an interesting idea. If this were to be changed on existing lights by default, it would have minor gameplay implications, but the sort that make missions easier in a fair way. So... electric lights: Like the real ones of the era, they're implied to use incandescent light bulbs... the kind that in reality will explore and shatter upon the smallest impact, and which like real lamps are encased in glass or paper. In any realistic scenario, shooting a broadhead arrow at a lamp or even throwing a rock at it would cause it to go through the glass and break the light bulb inside. Is it wrong to imagine TDM emulating this behavior as a gameplay mechanic? Just as you can shoot water arrows at flame based lights to put them out, you'd shoot broadhead arrows at electric lights to disable them... you must however hit the glass precisely, there's no room for error and it must be a perfect shot. As a way to compensate for the benefit, AI can treat this as suspicious and become alert if seeing or hearing a lamp break, or finding a broken lamp at any time if that's deemed to provide better balance. A technical look at implementing this: Just as broadhead arrows can go and stick through small soft objects such as books, they should do the same if you hit the glass material on a lamp, while of course still bouncing off if you hit metal: Lamp glass would need a special material flag that sends a signal to the entity upon collisions but allows arrows to go through, unlike glass in other parts of the world which is meant to act as solid and changing that everywhere would break a lot of things. When pierced by an arrow, the lamp should immediately turn itself off while playing a broken glass sound and spawning a few glass particles. The glass material should be hidden if the model is a transparent surface, or replaced with a broken glass texture in case the glass is painted on a lamp model without an interior... obviously this would be done by defining a broken skin for the entity to switch to. This does imply a few complexities which should be manageable: Existing lamps supporting this behavior will need new skins and in a few cases new textures, the def must include a new skin variable similar to the lit / unlit skins in this case a broken skin. Any electric light may be connected to a light switch, we don't want toggling the switch to bring the light bulb back to life... as such a flag to permanently disable triggering the light from that point on would be required. For special purposes such as scripted events to reset the world, we should allow an event to unbreak lamps, setting their state back to being lit / unlit while re-enabling trigger toggling. What do you think about this idea and who else wants it? Would it be worth the trouble to try and implement? If so should it only be done for new lights or as a separate entity definition of existing ones, or would the change be welcome retroactively for existing missions without players and FM authors alike feeling it makes them too easy?
  4. The script might not be too far off what I was thinking anyways, because one of the reasons I wanted to be able to do it in DR is because you could then have a test script like 'Check for missing EFX on info_location entities'. So maybe we can just have a script called 'generate EFX file' or something like @datiswous is suggesting. The problem is that if feels a bit like a halfway house instead of a proper implementation. Also I think we all could probably agree the EFX file will never go away in case people want to do more than just presets, so we would have to support both the info_location method and the file method. Just thinking out loud here, and good discussion
  5. Who I am is of little importance, what matters is the job I am offering. Though the item in question may be simple, I can assure you that the reward is anything but. The task, to those brave enough to follow through, is this: During the peak of Braeden's Harvest Festival, break into Lord Alister Squashbottom's manor and steal that which is most valuable to him: his prize-winning pumpkin. This is the very pumpkin he intends on submitting to the judges of this year's competition, and you are to ensure he has no choice but to resign in failure. It may be dangerous, to which you will be amply compensated, but I have little doubt you will be able to weather all obstacles and keep your eye on the prize to complete this task. For those brave enough to accept the job, start here. Cordially, E. Siltstone Gameplay Notes TDM version 2.12 is required to play this mission. Mines are pickable; simply approach them with lockpicks equipped to frob-disarm. A moss arrow can be shot at glass to make it break more quietly. I recommend playing all three difficulties, as they are very different. This FM may be more hardware intensive than normal. LOD settings can be set below "Normal" to improve performance on low-end machines. Download Version 1.0 - This FM is available here via Google Drive, and will soon be made available via the in-game mission downloader. Promotional Screenshots ThiefGuild Release Page Credits A huge thanks to my beta testers Goldwell, WellingtonCrab, Kingsal, Baal, and Rezar for all of your fantastic feedback Voice Credits - Goldwell! Asset Credits Kingsal Wellingtoncrab Goldwell Sotha Bikerdude Refle3cks Arcturus +++And thank YOU for playing!+++
  6. Maybe it's possible to make a script that extracts all the info_locations from the map file and creates an efx file from that in the correct format (run again to update). Then you can simply fill it in. Possibly you could also edit in DR the efx-data as a fake spawnarg for that info_location entity and make the script write that to the efx file. This might also be possible via a script/plugin inside DR.
  7. Do you really want to try? I'd suggest looking at idSoundWorldLocal::MixLoopInternal. That seems to be the only place where effect is found by area index, then by area name, then default. If you manage to add a member like idSoundWorldLocal::listenerEfxPreset and ensure it is set properly, then you most likely can pass the preset name here (perhaps via something like idEFXFile::FindPreset). In my opinion, the location spawnarg should get top priority. If missing or empty, then the ordinary approach with .efx file works.
  8. Hey I just wanted to create a Thread where everybody can post his improvement wishes. I Personally love this mod. There are so many features in it, and because it is a mod created by a community, why not write what could be improved. My wishes are: Some special weapons. I loved T2X and the variety of weapons. Some really hard to find special weapons, like the confusion arrow or a special bomb would be cool. But they have to be very special, for example as a result of a side quest - or maybe a usable torch for easier killing the undead More enemies, I think there will be an improvement, we just got spiders and zombies, but a higher variety is always good. More (custom) conversation. Thats one of the main parts I'm missing - so much flair and atmosphere is getting lost without them. Also some comments from he main charakter would be nice. For example when a guard gets knocked out "hah, now who's the taffer" ... better AI when the hear a voice. They start looking for you, but most of the time I just sneak into another room or a higher area and just have to wait, they should at least get someone with a torch or call other guards for help These are only small parts of the game which could be improved and are only my points of view, maybe it's either not possible to create or it fits not in the design of TDM.
  9. I wasn't aware that you changed the whistle so I am probably using an old version which I like pretty much. I just renamed the internals in the vain hope that our mods can be mixed that way, but there are too many other overlapping definitions. P.S.: I looked closer into it and it seems there was only one other overlap which I fixed by renaming, so now the patch and your modpack can be merged with each other ! As you use x_ as prefix your features will override mine though ...
  10. It would be nice to be able to create your own EFX presets, this will solve that issue. https://github.com/kcat/openal-soft/blob/master/include/AL/efx-presets.h lists all the presets. Here they can be seen in the tdm source file. I think these could be read from an external file instead of inside game code? If TDM reads the presets from an external file, anyone could easilly make their own presets by overriding that file and these could be used inside a spawnarg when that gets implemented.
  11. So path_follow_actor actually DOES work if you want it to follow the player. You just need to target the player entity dynamically in game. It doesn't work if you target the player_start entity. I can't remember if that's what people were doing (or even if that's what I was doing), but that won't work because the player_start entity and the player entity aren't the same thing. You can use a atdm:target_changetarget entity to do this, or a script: $path_follow_actor_1.addTarget($player1); Both can just be triggered by another path node, a atdm:target_callscriptfunction, whatever. Also you need to add the player target to the path_follow_actor node BEFORE the AI gets to it. If the target gets added after the AI reaches that node, it won't work. Video where the AI hits a node that triggers a atdm:target_changetarget entity: https://drive.proton.me/urls/A3DJW5EYFM#0WgYnCVOU6nv test map attached as well. EDIT: I have no idea why just manually setting 'target' 'player1' on the path_follow_actor node in DR doesn't work. I'll try to look into this. UPDATE: It appears the the player1 entity simply isn't there during initialization when the path_follow_actor's targets are evaluated. As a result, the 'actor' is null and the node does nothing. I didn't mention it before, but when I used the script method I just stuck in the map script's main function like so, and this works too: void main() { sys.waitFrame(); $path_follow_actor_1.addTarget($player1); } UPDATE 2: Wiki updated: https://wiki.thedarkmod.com/index.php?title=Path_Nodes#path_follow_actor path.map
  12. I just noticed that the sounds of hitting something with the blackjack or the sword seem not to be audible to NPCs. On the other hand hitting something with an arrow does, as fas as I know. Is this intended to avoid punishing the player for e. g. a missed hit during knock out or is this an oversight that should be fixed?
  13. I have updated my Refont program, to now have a function that can analyze a font DAT file for missing or problematic characters. As part of a broader inquiry, I've just applied that program, individually, to all current 'english' font DAT files. I'm reporting the overall results here. I'm sure this will not be a surprise to some of you, but may be to others. Background As you know, TDM fonts are based a bitmap system, derived from 256-character code pages, of which "English" and "Russian" are currently supported. "English" is actually Latin-1, with additional characters to cover more European languages in a single codepage. This is (in theory) quite good for major European languages, less so for less-prominent ones. For each font, bitmaps are distributed in 3 sizes (12, 24, 48 pt), with the engine doing interpolation scaling. Current Font Findings 12-pt Size for All Fonts Only ASCII (i.e., lower range 0-127) characters are provided, no European. For some fonts (stone, mason, mason_glow), the 12-pt DAT is not distributed, so the engine will substitute a larger size, which typically has better Latin-1 coverage. For Fonts Used in Main Menus, HUD, or Subtitles The numbers shown approximate the number of "characters needing work" Fontname Size-24 Size-48 carleton 20 16 carleton_condensed 20 35 mason -- 33 Since 24 pt is not distributed, engine uses 48 pt. stone 30 83 For Additional Fonts Used in FM Readables, Etc. Except for one font (treasure_map), all the remaining fonts are ASCII-only, i.e., no characters in the upper range. In the lower range, routinely the 24 and 48 pt sizes have equivalent coverage. Most of these fonts are fully or nearly complete, while some neglect certain punctuation symbols. The worst is "everette", with 24 "needing work" characters. Further details are here:
  14. This is a work of fiction. Unless otherwise indicated, all the names, characters, businesses, houses, events, incidents and particpants in this forum thread/fm are either the product of the author's imagination or used in a fictitious manner. Any resemblance to actual persons, living or dead, or actual events is purely coincidental. Hello everyone, I am saddened that my first post here is to bring you all the news concerning the disappearance of my dear friend, wellingtoncrab, which was last seen on March 10 of this year by heading to the woods of northern California . Unfortunately, without trace or tracks, we have no choice but to cancel research. In addition to finishing 1.25 FMS, wellingtoncrab was known as an partner of many famous people and models, and to have the largest animal crossing house. We will miss them a lot. Of course, an immediate concern was devoted to determining the status of their unpublished FM(s). I must admit that the passage through their hard drive has not turned much, but I was intrigued to find a file called "IRI2.PK4". Unfortunately, my computer cannot load the card (too old, lol ), but I will download it here for posterity as well as the text included in the README: https://drive.google.com/file/d/1SdZswFLUh5VwReIq79uFL_ahXyKxg34F/view?usp=sharing ========================================= WellingtonCrab Presents: IRI2: The Totally Unauthorized Sequel to Moving Day: Moving Day 2: Look Who’s Moving Now *For Richard and Linda* “There once was a hole here. Now it is gone.” With enduring gratitude to: Testers: ImaDace Goldfish Kingsalmon Acknowledgments: @Jedi_Wannabe for graciously unauthorizing this sequel to his great mission "Paying the Bills 0: Moving Day." Mr. Squirrels: you know who you are and what you did. The name "Lampfire Hills" originates with the author Purah and now is part of the extended universe of many subsequent Thief missions. Bikerdude and Goldchocobo then brought the name into the setting of The Dark Mod with the FM "The Gatehouse." It then came to me in a dream. @Dragofer for all of his scripting work and support over the years. Polyhaven.com for its many excellent CC0 assets. I recommend supporting them on Patreon if you can spare the change: https://www.patreon.com/polyhaven/ Textures.com "One or more textures bundled with this project have been created with images from Textures.com. These images may not be redistributed by default. Please visit www.textures.com for more information." Google Image Search.
  15. I have never been truly satisfied with the Whistle: it was either too much or too little. The latest version (v4) is so far the best (imho) although I still disagree with some things. Are you up to date or are you keeping a previous version for some reason?
  16. The Frob Helper doesn't work in this mission. I suggest an update of tdm_player_thief.def to the latest version.
  17. I made a small update including the fixed fonts by Geep and also brought Snatcher's Whistle back, because a) I noticed that hitting something with blackjack or sword has not the same effect and b) the name now doesn't look bad anymore because of the font fix .
  18. 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.
  19. This should definitely be possible. The python scripting API has functions to loop through entities and read their spawnargs, and then you could use standard python file functions to write the EFX file. It would be cool to have a proper EFX editor in DR, but writing a script would be a lot less work. @Frost_Salamander if you decide to write a script like this I'd be happy to help you out if you get stuck. You can check out count_loot.py for a minimal example of looping through entities.
  20. If you wanna put together a prototype implementation, we could provide assistance. I think it mostly just requires adding EFX parser parts to the entity def parser. The big wrinkle is what to do if a mission has both EFX and Entity Def args?
  21. @stgatilov @nbohr1more I'm wondering if it would be possible to get this implemented for 2.13? I'm really not loving the EFX files - it's way too easy to miss/forget locations and just a general PITA. I am even considering offering to help implement - any reluctance on my part is purely down to lack of confidence. But with some hand-holding I could possibly accomplish something that isn't a total disaster. Maybe an alternative is to have a feature that allows DR to manage the EFX preset in the EFX file? Basically what I'd like is to be able to manage everything related to a location entity in the one place, preferably in DR. Not sure if that's ever been considered? @greebo?
  22. Thanks for the replies, particularly the reference to the embarrassingly-obvious "Music & SFX" subforum just below this one. I just like the music: I don't have any illusions about creating a fan mission. I messed with Dromed way back in the day, and I remember what a black hole of time and sanity it was.
  23. I'm working in DarkRadiant on a new map, and I'm having something odd I've never experienced before. There's a fire in a stove model on the second floor of a building... walls, floor, ceiling, etc are all worldspawn brushes with appropriate textures, neither player nor AI have any trouble traversing the entire place, so I think it's assembled as it should be. However, if I douse the stove on the second floor with a water arrow, the water splash somehow drips through the floor brush and douses a torch in the same rough area down on the first floor. I tested it on various positions in the building, and it seems to happen everywhere, not just on that one light. Water arrows that impact on the second floor fall through the floor, and if a light is presence in the fall area it's extinguished. Is this expected behaviour? I would have through a solid brush would stop water from traveling any further once released.
  24. For the people eager to play with the latest state of development, two things are provided: regular dev builds source code SVN repository Development builds are created once per a few weeks from the current trunk. They can be obtained via tdm_installer. Just run the installer, check "Get Custom Version" on the first page, then select proper version in "dev" folder on the second page. Name of any dev version looks like devXXXXX-YYYY, where XXXXX and YYYY are SVN revision numbers from which the build was created. The topmost version in the list is usually the most recent one. Note: unless otherwise specified, savegames are incompatible between any two versions of TDM! Programmers can obtain source code from SVN repository. Trunk can be checked out from here: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ SVN root is: https://svn.thedarkmod.com/publicsvn/darkmod_src Build instructions are provided inside repository. Note that while you can build executable from the SVN repository, TDM installation of compatible version is required to run it. Official TDM releases are compatible with source code archives provided on the website, and also with corresponding release tags in SVN. A dev build is compatible with SVN trunk of revision YYYY, where YYYY is the second number in its version (as described above). If you only want to experiment with the latest trunk, using the latest dev build gives you the maximum chance of success. P.S. Needless to say, all of this comes with no support. Although we would be glad if you catch and report bugs before the next beta phase starts
  25. The FAQ wiki is almost a proper FAQ now. Probably need to spin-off a bunch of the "remedies" for playing older TDM versions into their own article.

    1. TheUnbeholden

      TheUnbeholden

      Nice work buddy! 

×
×
  • Create New...