Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Dragofer last won the day on July 17

Dragofer had the most liked content!

Community Reputation

1211 Deity


About Dragofer

  • Rank

Profile Information

  • Gender

Recent Profile Visitors

1360 profile views
  1. The black lamps are unfortunately a bug, not an install/asset problem. 2.08 seems to read skin files differently so now it matters when there are non-standard characters in file paths, most prominently the hyphen in /non-extinguishable/ for lamps.
  2. 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.
  3. 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.
  4. @Apiai Yes please, it looks like this might be another case of black skins on FM-specific non-extinguishable lamps since 2.08.
  5. @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.
  6. 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.
  7. Posted to the bugtracker: 0005319: Trigger_multiple stops working if AI stops moving
  8. 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.
  9. 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.)
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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"
  15. 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.
  • Create New...