Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Dragofer

  1. As it stands, it seems the majority of the FMs with custom .gui files listed in the OP only made very minor changes of a technical nature, i.e. self-help with avoiding a blank briefing screen after skipping a video. It should be realistic to reduce the list of FMs that *must* have custom GUI files to a much smaller number. After that's done, if the devs make a GUI change it should be fairly reasonable to test whether the GUIs of those missions still seem to work as intended, i.e. contact the authors or else ask betatesters to work through a list of FMs with custom GUIs. If one of those FMs has problems that can't be resolved, then I'd see a 5th solution: add all the GUI files from the previous TDM version to the FM, so that it'll forever live with that GUI state while all other missions continue to benefit from updates.
  2. I find this incredibly vulgar. Whatever your views may be, there's no excuse to deliver them with such obscenity. I understand we have lax forum rules that permitted Kurshok to start this thread on equally inflammatory premises, as we rarely come into situations where we need such rules, but at this point any civil space on the web should draw the line.
  3. @Apiai Yes please, it looks like this might be another case of black skins on FM-specific non-extinguishable lamps since 2.08.
  4. @Obsttorte good to see how you'd shorten it and what alternative methods exist to achieve this. Regarding how it affects all lights of that type, Destined could add a custom spawnarg to all lamps that he wants to be affected i.e. "power_source" "generator_basement1" and then let the script search for that instead: lamp = sys.getNextEntity("power_source","generator_basement1",lamp); He'll probably want only the generator to control their lit state, because otherwise the script will need to make the switches become ineffective for as long as the generator is off.
  5. A motion lamp should be quite feasible if I can get trigger_multiple brushes to inform the script who activated it. Trigger_touch has such a function (pass_activator and pass_self spawnargs) but I don't see that for trigger_multiple. Surely that possibility exists? For making stim-triggered presence lamps, a problem will be that the radius of the stim is defined on the humanoid and not on the lamp, and any existing stims might be too short-ranged for general use. Would likely need to put custom stims with a large radius on all AIs and the player and only let the lamp react if the humanoid is within a certain spawnarg-specified radius. Alternatively each lamp lamp could check every second whether it can see someone, though then it'd frequently switch on/off when the player or AI moves around objects that provide cover. Another potential problem is that the AI might be very close but on a different floor/in an adjacent room. Visibility checks can't be used to identify this because the humanoid might be hidden behind cover, so it'll have to be location-based: each room should be its own location. Looks like this is a more involved route than the trigger brush method.
  6. Posted to the bugtracker: 0005319: Trigger_multiple stops working if AI stops moving
  7. I can see that also The Painter's Wife overrides 2 guis without permission: - mainmenu_background.gui: looks like this was only to point to a custom background image. Could've avoided this by overwriting the default image file. Doesn't look like there's any place in the customisable guis to change the menu background, only the title image (maybe that's the same thing?). - mainmenu_briefing_video.gui: this was taken from an existing mission that had a briefing video, so I don't know exactly what's going on here. It looks like a lot of missions that have briefing videos overwrite this file. IIRC it's something to enable skipping a briefing by pressing escape without seeing a blank briefing page. When you click to skip you still see that, though. Some things to note: mainmenu_custom_defs.gui says it's the only customisable file, but mainmenu_briefing.gui also gives permission I think a problem with the custom guis is how long and full of comments they are, making it difficult to find something specific. For example, it currently has blank definitions for 10 and sometimes even 60 briefing/debriefing videos. I think by default there should only be 1 definition and if the mapper has more he can copy paste them and increase the number. If necessary the excess definitions could be moved to mainmenu_custom_defaults.gui. The comments are informative but could be condensed, something I could do at some point. If the custom GUIs are going to be extended a lot it may be a good idea to split them up into i.e. briefing, main menu, loading screen etc.
  8. Could call a script like this from the switch: entity previous_entity = $null_entity; //assign a starting value to this variable void lamps_toggle() { float i; for (i=0;i<30;i++) //repeat this up to 30 times { //look for all lamps with a specific classname entity lamp = sys.getNextEntity("classname", "atdm:lamp_type_a", previous_entity); previous_entity = lamp; //store the search result so the next search doesnt start from scratch //if the search has found a valid lamp, trigger it if(lamp != $null_entity) { sys.trigger(lamp); } //otherwise terminate the search else { return; } } } (Haven't confirmed that this is formatted correctly, might be that I use previous_entity incorrectly. There's probably a way to automatically determine how many times the script needs to repeat.)
  9. Wasn't able to find a bugtracker issue for it, but I found the thread where it was discussed. The changes took place around the 21st of March (i.e. rev 15880-15882). I'm not even sure whether the code or only the assets was changed, but I've never seen this black lamp issue before 2.08, and now it comes up regularly and is fixable by adding quotation marks. This is even though stgatilov found a piece of code in the linked thread that suggests this shouldn't have an effect ingame.
  10. I can confirm that trigger_multiple brushes stop firing triggers if an AI stands still within them. So I see 3 options: Report this for 2.09 so it hopefully gets fixed, or keep both mechanisms so we have both motion sensors and presence sensors. Develop a different presence mechanism that doesn't (wholly) rely on trigger brushes Turn this into a feature and rename to "motion lamp" instead of "presence lamp". Change the script so the lamp only responds to player movements that exceed a certain velocity.
  11. This tends to happen with all models that have non-standard characters in the file paths in their skin definitions and haven't put these paths into quotation marks. In this case it's a hyphen in "non-extinguishable". As of 2.08 skin files are read differently in order to address another issue, resulting in a black (missing) skin. All skins in the core assets were updated with quotation marks, but not the ones in FMs. The immediate solution would be to reupload the FM with quotation marks in its skin definitions, but @stgatilov or @duzenko would be needed for a permanent solution for the next TDM version.
  12. It's the regular trigger brushes that only react to either AIs or the player walking into them, trigger_touch works differently by checking for all entities that are in contact with it (within or "touching"). I always only activate it for a single frame before deactivating it. I suppose a clean & flexible way to check for entitities in a volume would be to use getNextEntity and check whether its origin lies within a certain volume(s) demarcated by 2 points. If it needs to be more precise, you could maybe use getMins and getMaxs to find the dimensions of the entity's bounding box to check whether it overlaps with the volume, or else use a trigger_touch brush to do this for you. Btw, I found findActorsInBounds(vector mins, vector maxs); in the TDM script reference, that could come in handy at some point depending on what kingsal is doing.
  13. The new HotReload feature by stgatilov in this latest build is a big one for any mappers. Now you no longer need to reload the whole map in TDM if you changed an entity's properties in DR (origin, model, light colour/radius, skin etc.), simply save in DR and enter reloadMap into TDM's console and the changes take effect ingame. This should save a lot of time in things like getting the lighting right, well worth getting if you're a mapper. Even easier is to bind this to a hotkey by typing the following into the console (in this case binding to j): bind "j" "reloadMap"
  14. I find the skill in blackjacking should lie in maneuvering yourself into a position where you can knockout an AI and hide the body without getting detected by other AIs. Once you’re in that position, the blackjack should always function reliably as long as you aim at the head from behind - you shouldn’t have to worry about things like hitting the nape of the neck (without a crosshair) or standing at a certain distance, which I wouldn’t label elements of difficulty but rather potentially frustrating inconveniences. It’d certainly be a case where realism should give way to gameplay. The Thief games take this too far in that hitting any bodypart from any direction will knock them out, and they don’t get alerted by you running up to them, but that aside I think they’ve got it right with respect to my previous paragraph. I only rarely hear someone complain that Thief’s blackjacking is too easy, but it comes up again and again that TDM’s blackjack is too unreliable.
  15. I think it's perfectly fine to make posts for any FM in this forum, regardless of when the last post was made. It's always good to hear thoughts and feedback. Regarding not being able to frob anything, that's typically associated with trying to read a readable that has no text defined (a mapping error). Seems strange that you had that from the outset, though.
  16. By system memory I did mean main system memory ("system-wide"), and that line was directed primarily at thebigh. VRAM doesn't seem to matter too much. I've had no problems loading & running the mission on an Intel UHD 630, which has no dedicated VRAM and instead draws from 8 GB of main system memory on that computer. This ran at 20-30 fps in the streets.
  17. In terms of system memory, it seems 4 GB is the requirement for Painter's Wife. No reports of anyone with less memory being able to load it. Also, Freyk's comment wasn't pointless: many users report being unable to load the mission with the default 32-bit client, usually failing after about 25% progress. If the 32-bit client does succeed, then it might cause other problems. Anyway, he probably hasn't seen that you stated in the TPW thread you use the 64-bit client. All that said, there's a trimmed down version that just barely can be loaded by the 32-bit client, which can be downloaded manually from the release thread. Maybe that version of the mission is more manageable for your PC.
  18. On that screen you always see a closeup of a texture near the player's starting location. Usually ambient brightness is fairly dark so it looks almost black, but if the light is brighter you can clearly see that texture.
  19. Big congrats on the release! And, the mission is now available in the mission downloader.
  20. I think it's the nature of a community-driven project like TDM that people should be the change they want to see. Implementing a character takes a lot of steps and it's rare that a single person has the knowledge and time/motivation to do all of them. So if you have - or can reasonably learn - some of the skills needed to get some of those steps out of the way, then that's the best thing you can do to make it happen. In this case, that'd probably be completing & exporting the animations, and sticking around to make the modifications that'll inevitably be necessary. That way, whoever should pick up this character doesn't need to be both a Blender-based animator and an asset manager or coder. That's basically the approach we're going for with the dragon, too.
  21. As my custom assets work has increasingly shifted from models towards scripting, I'll open a new thread here to contain any scripts that I write which can be reused in other missions, starting with the A ) Presence Lamp This is a Lost City-style lamp that brightens and dims depending on the presence of the player or an AI. It fades between 2 colours and can trigger its targets whenever it switches fully on or off, so it should also be viable in various other situations. The standard setup consists of the following: - a trigger_multiple brush. The spawnarg "anyTouch" controls whether AIs, too, are able to activate it - a presence lamp, highly recommended with a colorme skin - one presence light, or any other light with appropriate spawnargs The targeting chain is trigger brush -> lamp -> light When the player or an AI stands in the trigger_multiple brush, the lamp switches on and starts a short timer. Subsequent triggers reset the timer. If the timer runs out because no one's standing in the trigger brush anymore, the lamp switches itself off. Notes - Multiple trigger brushes can target the same lamp, and one trigger brush can target multiple lamps. However, each presence lamp can only target one light, so if you want i.e. a bouncelight you'll need to hide an additional silent presence lamp somewhere and target it from the same trigger brush. - The lamp and the light use their own colour spawnargs respectively, since setting 0 0 0 on a lamp would make it appear pitch black. - Technically the trigger brush can be exchanged for anything else that triggers the lamp every 0.5s (this number can be changed via "update_interval" on the lamp), i.e. a trigger_timer. - This was originally named the proximity lamp and was one of many scripting jobs for The Painter's Wife. I've renamed it to "presence lamp" because the mapper may place the trigger brush(es) wherever he wishes: proximity to the lamp is not a factor. Credits go to Bikerdude for putting together the crystal lamp models. Download Presence Lamps - Google Drive Place or extract the .pk4 into your FM archive, then look up the presence lamp prefabs. If you already are using other custom scripts, remember to add the presence lamp's .script to your tdm_custom_scripts file. B ) Teledoor This is a Skyrim-style door which opens just a bit into a black_matt "void" before teleporting the player to a different area of the map, which may represent the other side of the door. This is used for connecting physically separated map areas with each other, such as when there's an exterior/interior split of a building or ship to allow for more mapping freedom. [Full Thread] C ) Mass Teleport This is a teleportation setup designed to seamlessly teleport the player and any moveables between two identical-looking areas. This allows the mapper to link 2 physically distant areas with each other while maintaining the illusion that they're connected. The teleportation zones should be free of AIs as they can't be teleported like this. [Post]
  22. I've seen a similar error message when trying to export .lwo or .ase models while in edit mode or on a Blender version the exporter isn't made for. Could be that your selections are off, or you aren't using 2.80? Otherwise could try to talk to Samson on the TDM Discord.
  23. Some more progress: the map is actually happy to load if I place a dragon AI in it. At first it was static in a T-pose, though still with random head turning, but this tweak to the animation channels has solved this: channel torso ( *pelvic_1 ) //all joints associated with pelvic_1 go into the torso channel channel legs ( *origin -*pelvic_1 ) //all joints except for those associated with pelvic_1 go into the legs channel So I gave him a path node: he plays the walk animation, though he never leaves his spot and spins in place. So, new notes: The game wants an af_pose for the dragon. This is simply the static T-pose (what you see when you search for "dragon" in DR's Create Model list), but as a single-frame .md5animation with a key set for each bone. It's very likely the dragon doesn't move forward because the walk/run animations don't move the origin bone. This wiki article describes how speed varies within a walk cycle. I'm wondering whether all the bones are making it from the .blend into the .md5mesh. For example, I can see "breast" and "pelvic_2" when I open the .blend file in Blender, but not in the .md5mesh opened in notepad. Maybe those are a different kind of entity? Edit: they're only controller bones for the benefit of the animator, it seems. Foot bones are always misspelt as "food" 8x is actually quite huge - a human could easily ride a dragon that size. Would probably choose 4x for now. You only need to rename the 3 default materials on the dragon mesh from dragon_body to i.e. dragon_body_black etc., then update the skins. There are no TDM models that I'm aware of that require a skin in order to work.
  24. In general I'd try to keep it manageable at first, as per your earlier suggestion to make it ~1.5x a horse. In the end a larger version can be made, though it could help to see the WIP animations on a large model. I can imagine that down the line it'd be much easier to work with setting up all those joints for the skeleton/IK if they all adhere to the same rules. In the worst case some of those defs could be case-sensitive, which would be a pain to cross-reference.
  25. I've done some more steps: Fix up the materials and skins so they're properly usable in TDM and DR. This included compressing to dds, creating editor images, moving to the right folders, renaming etc. This has also reduced the .pk4 size from 110mb to 70mb. Create the first .def: the model. This defines which mesh is used, which animations are available for it and which events should happen when during those animations (i.e. play footstep/attack sounds, disable/enable IK). This is enough to make a func_animate. I used the horse as a base and looked up the werebeast and human base defs for further animations that may make sense for a dragon. Make a FM archive out of it with a test map named "dragon" containing 4 func_animate dragons looping various animations. They can be triggered, i.e. via script or lever, to toggle their animations between those specified in the "start_anim" and "anim" spawnargs. So now you have a test map with functioning animated models to work with in order to get the assets into a polished state: Dragon v0.4 - Google Drive While working with the files I noted down various things: As you can see the dragon is only about knee high currently. Some joint names are in German. I've included a .txt file with translations in the download so you can change their names. I've had to comment out the animation channels (torso and legs). Idk which joint(s) should be chosen here - here's a list: Some joints have abbreviations which don't make sense to me, i.e w1_L, ACT_neck_1 or back_S_1_R. Either that's animation jargon, or maybe you can work out their function and find better names? There are already a lot of IK-named joints. I guess this might facilitate implementing IK? Some consistency issues with some of the joint names that would be good to solve in order to avoid potential problems in the future: IK isn't always capitalised: ik_ACT_tail_5, ik_tongue, ik_underarm_L, ik_underarm_R These joints contain full stops: paunch.002, w_C_L.001, w_C_R.001 Apart from the German joint names, some are capitalised: Bone, Hand_L, Hand_R, The model should use one of the colours as default and the skins be updated accordingly. The model def contains a lot of additional anims, commented out, that don't exist yet but could imo make sense for an AI dragon: The sleep_down anim seems to be broken, the .def stops working if it's included. I'd suggest making the colours less vivid to make them fit TDM's world. Skyrim's dragons would make for good inspiration for the colour palette imo. You'll need to know which frames should be accompanied by sounds (footsteps and attack sounds). The archive contains a start for the AI entity def. To make it more realistic as an AI, it'd help if the wings stayed closer to the body throughout the animations. Speaking of wings, those spikes sticking out of each wing seem way, way overdimensioned. Samson has actually updated the md5 importer/exporter for 2.8.
  • Create New...