Jump to content
The Dark Mod Forums

Dragofer

Development Role
  • Posts

    2626
  • Joined

  • Last visited

  • Days Won

    157

Posts posted by Dragofer

  1. The weapon hack is something that IIRC forces a model to render in front of everything else. It's limited by the fact that it can only apply to .md5mesh models, currently, such as the viewmodel of the player's arm and any weapons attached to the arm.

  2. There are a few ways to state the version number:

    • Inside darkmod.txt, included in the .pk4. The version number in here is what should be shown ingame in the mission downloader.
    • Mappers can write whatever they want inside the readme.txt included in the .pk4. This is the same as writing a version number into the release thread.
    • There is also the internal version number, which always has to be a whole number. It's entered directly in the admin interface, and only team members can see it.

    The existence of the last, internal-only number has led to some confusion among mappers. I think I used to put whole version numbers into my darkmod.txt (i.e. v2 or v3), but declare a decimal update (i.e. v1.1 or v1.2) on the forum thread and in the readme.txt.

    It's also possible to have different version numbers in the darkmod.txt and readme.txt. This is something that should be caught during beta testing.

    • Like 1
  3. 4 hours ago, Ansome said:

    Originally, only the windows facing the moon were lit up and projected moonbeams, but Dragofer remarked that following purely realistic lighting practices often results in an under-lit mission.

    Yes, I've been working with a mapper who ardently adheres to the principle that only moonfacing windows should cast moonrays indoors (so about 1/4 to 1/2 of all windows), even though this is a powerful tool for creating an atmosphere and for maintaining some gameplay challenge. I found that this approach often ended in scenes that had only dim and uniform ambient_world lighting, which meant players couldn't really appreciate many of the details.

    Something I've seen in things like Dishonored is the use of sourceless lights to add highlights to scenes that otherwise contain no lit lights. That could be an especially viable approach in a mission like this which has a haunted theme.

    • Like 2
  4. It occurred to me that, by now, this package goes well beyond mere bugfixes by including a range of gameplay changes (i.e. adding the ability to frob-extinguish oil candles, which isn't a bug that was patched). Maybe players would have a better idea of what this package does if it had a more fitting name, similar to how Snatcher calls his work a modpack?

    In other communities the term "unofficial patch" is typically associated with collections of community fixes to bugs that exist in the core game and were never addressed by the devs. Most players would therefore expect an "unofficial patch" to provide them the same experience as originally intended by the devs, but without technical problems.

  5. On 10/15/2023 at 10:14 PM, Melchior said:

    Could a special Monster-AI be added (or modified from an existing one); that are Photo-phobic? a 'Morlok' type creature that has great physical strength and aggression - but is totally blinded by even moderately bright light sources (oil lantern / carbide lamp? ect...) and forced to flee ( actually around corners / to dark spots).

    Would be far more interesting than watching slow moving zombies lumber towards the player...as usual.

    Sure the lantern is a neat prop - but what use is a screwdriver with no screws to turn?

    Yes, the stim/response system allows for this kind of thing. Easy enough to emit a custom stim around the lantern and put a response on all photophobic AIs to that stim. The response script would check whether the photophobic AI is within the lightbeam, then call a flee function on it. The main problem is that the flee function is unreliable if the AI is already busy with something else.

    • Like 2
  6. On 3/8/2024 at 9:14 PM, snatcher said:

    Find attached to this post v0.5 of the Player Lamp, updated to 2.12 standards.

    • The Lamp can run in parallel with other mods
    • Updated tdm_player_thief.def from 2.12

    Download the pk4 and place it in your TDM folder. Launch a mission and cycle through the weapons. Nothing else and nothing more.

    Playerlamp.jpg

    Enjoy!

    z_handheld_lamp_v0.5.pk4 189.53 kB · 1 download

    Nice - did you find a solution for how to avoid it clipping into walls or other solid objects when coming too close? Off the top of my head there was also a need to handle its behaviour in case the player gets submerged, and various other ToDo's.

  7. 36 minutes ago, wesp5 said:

    This sounds easy, but wouldn't it be overruled by any pk4s in fan missions or e.g. your mod's pk4? In what order are these pk4s processed, alphabetical, date, ... ? As far as I know the current solution makes sure that my patch is active all the time.

    Assets in FMs always overwrite assets in the TDM installation, regardless of whether either of the files are within or outside a .pk4.

  8. My impression was that the unofficial patch has become a large collection of various tweaks and features by various authors, or at least that's what it was being marketed as. Making it modular has significant advantages for those who might want certain parts, rather than the exact same combination as the one you endorsed. It also makes your patch collection more futureproof in case you add stuff that not everyone wants to have.

    In any case, it's advisable to at least adapt the file structure to the new addon conventions so that players are able to install other addons alongside yours.

  9. Some changes were made to the training mission, but this process began while 2.12 was already in beta testing, and it became too extensive. To my knowledge this mainly consisted of adjustments to the messages in order to match the new 2.12 control scheme, addition of a vine arrow training area, some minor gameplay changes as well as major visual changes. A last minute major issue caused the mission to be reverted to its 2.11 state except for the adjustments to the popup messages. The training mission is slated to undergo proper beta testing of its own later on.

    • Like 1
  10. On 2/22/2024 at 5:01 PM, nbohr1more said:

    If the problem cannot be solved in a reasonable time-frame, we may need to revert to 2.11 turret features and suggest completing any needed additions via local changes to your mission (... pretty unlikely, as we are highly motivated to retain the 2.12 turret improvements).

    In fact, there are no 2.11 turret features since it's a completely new thing for 2.12. Unofficial script versions of the turret also rely on code changes that were made during turret development for 2.12.

  11. 15 hours ago, Uncertain Title said:

    What causes a brush to go from being considered 'sealing', to 'needs to be sealed?'

    Generally speaking, solid + opaque materials like wood or stone will seal, while nonsolid ones like materials meant for dirt decals won't. Some exceptions, for example caulk is a popular solid + invisible sealant, unlike i.e. all the nodraw and nodrawsolids which won't seal.

    Another thing that helps a lot is to use a large grid size like 8 or 16 units sealing geometry. This way you can more easily align parts and see gaps. Details can be done with smaller brushes or with patches.

    All of your detail pieces should be entities instead of worldspawn due to compiler reasons. This has the extra benefit that you can use the "All entities" filter to hide entities and only see your sealing worldspawn geometry.

    • Like 1
    • Thanks 1
  12. 2 hours ago, JackFarmer said:

    The problem does not show up with all related dev builds. However, I cannot test with the last build (16854-10518), which I simply cannot start and get the report

    image.png.d68833e6ea295ea514ad41ac9c0e7097.png

     

    Summary:

    • 16842-10488: no problems
    • 16854-10518: cannot test (see above)
    • beta 1: problem appears

    You can work around this error by putting a completely empty file called tdm_turret_scriptbased.script in your script folder, and temporarily removing all turrets from the map. Would still be interesting to see whether 10518 is the first build where the problem appears, or beta1.

  13. New script for mappers: my flavour of a fog density fading script.

    To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it.

    Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast.

    Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436

    • my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later
    • more than one fog light can be controlled (however, no per-fog-light level of control)
    • adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg
    • in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3
    • smaller and less compactly written script

    fogfade.scriptfogfade.map

     

    • Like 2
  14. @MirceaKitsuneThanks for the playthrough and feedback! In recent memory my mapping efforts have gone to new projects that I feel more inspired for - I think they would probably also be more interesting to the broader TDM community.

    The fix to Linux users getting stuck at map start was fixed in 12-06. The FM update only covers datiswous' new subtitles and an early attempt to fix the stuck bug by moving the player start a few units.

    The ship was made from scratch for this FM with an exterior and interior. It's my first ship asset and I've made a lot more ships since then and which have gone up in build quality progressively. You can send me a PM if you need to get sorted out with a ship for an FM.

    • Like 1
  15. As of v3.8 and as reported in 5467, DR only supports prefab tooltips for prefabs that contain a worldspawn entity (at least one brush or patch that's left as worldspawn) with an editor_description spawnarg.

    This is problematic because most prefabs don't contain such an entity, so if a prefab creator desires to include a tooltip something like a brush cube needs to be added to the prefab (see for instance 6267). This is a little messy as the mapper might not understand its purpose or forget to remove it after placing the prefab.

    It's also tricky to create a series of prefabs with descriptions in a single map because there can only be one editor_description spawnarg in the map at a time, so the creator has to store each tooltip in an external file like a Notepad .txt.

    I think an ideal solution to this would be that DR prompts for a description when exporting something as a prefab. The prompt window could already be populated if the mapper is overwriting an existing prefab with a description, or if the selection contains a worldspawn entity with an editor_description spawnarg. More flexibility in making tooltips for prefab would imo certainly be a valuable quality of life improvement.

    • Like 3
  16. 9 hours ago, nbohr1more said:

    Thanks!

    I guess that was a red herring. The problem happens due to a change made in source rev 10498:

    Thanks for tracking down the issue. I've created a new version of the FM with the player start about 8 units further into the centre of the cabin, and datiswous' subtitles. Should work now?

    https://drive.google.com/file/d/1tb0wm-8P57y_yZZ5aHbBX2mOyzeOYOw4/view?usp=sharing

    • Like 2
  17. 9 hours ago, nbohr1more said:

    @Dragofer I was trying see whether the immobilization event is somehow leaking \ executing at the wrong time.

    When tracking down the parts, I see a bind to "MoverLookSkelly" but no corresponding entity in the map?

    // entity 1040
    {
    "classname" "target_null"
    "name" "target_LookSkelly"
    "bind" "MoverLookSkelly"
    "cinematic" "1"
    "origin" "6772.01 -1056 6660"
    }

    The target_null is a focus for a func_cameraview entity used in the cutscene (the latter immobilises the player when activated). Looking at idEntity::Event_SpawnBind in Entity.cpp, nothing happens with regards to binding if the bind entity can't be found. Target_null also works without being bound.

    In the original version the cutscene featured a platform (StormFadeMover) that moves the player down a very long corridor with the aim of fading out the cutscene's sound (my self-taught scripting was very rudimentary). In the updated version I do it properly by calling fadeSound on the relevant speakers.

  18. I don't notice an issue with moving at map start. Do you mean you can't move at all? There are a few small furniture pieces around the player that might cause you to be unable to move further in certain directions.

    The only time I immobilise the player in that FM is when a cutscene camera is activated, long after map start. I didn't know about immobilisation flags back then.

    Thanks for the subtitles!

  19. 2 minutes ago, Fiver said:

    Say then we have a small fan mission that is entirely libre, built entirely from libre assets and created to intentionally avoid using any of the current 2.3 GB media/gamedata. If we wanted to play that mission using only the source code, what media/gamedata components would be missing to do that?
    * GUI graphics and music?
    * HUD elements?
    * Any in-game sounds?
    * Inventory objects?
    * ... anything else that can neither be included in the mission's own media/gamedata, nor avoided during mission design?

    Yes, all images, models and sounds would be gone. Even if you made a barebones replacement that only provides a very limited selection of assets you would need to create thousands of files just to achieve basic game functionality (movement sounds, guard clothes and speech, menus, tools and weapons etc.). It's probably orders of magnitude more work than when TDM got rid of all Doom3 assets for going standalone in v2.0.

    Technically it's probably possible for an FM to contain a full game's worth of assets, except for the code itself. IIRC some Doom3 mods had custom .dll's to extend the base code, though.

    • Thanks 1
  20. You can probably do most things with setups of relays, targets and other entities, and at first glance your setup seems to be reasonable. Past a certain (not high) level of complexity a primarily scripted method will give a much better overview and be more powerful, though. If you're a coder that's what I'd have recommended.

×
×
  • Create New...