Dragofer

@stgatilov I don't think that effect/method is meant to use inventory items for the player, it would not be possible for lockpicks anyway because the player needs to hold down his key for those. It's more meant to simulate that items are frobbed by the player, i.e. pressing a button as if the player had pressed it. My main use case is to make func_static items that, when frobbed, call a frob effect on an item in the blue room. This way I can give the player moveable inventory items like keys without risking that an explosion or other force has pushed the item to somewhere where it can't be found anymore.

Being able to pack licensed assets in the FM is the main one for me. Ideally it could be done without restricting mappers’ access to the rest of the archive by having locked archives within the unlocked FM archive, otherwise the rather cumbersome approach with separately uploading archives would have to be used. In any case, that should be an enrichment for TDM and benefit all mappers. I’m not enthusiastic about the prospect of homegrown files being prohibited from being modified or opened, because an important part of mapping is modifying assets to fit the FM and inspecting other people’s work. But fair enough if that’s what it takes. I must say I hope it doesn’t become a wider trend. The author’s not been seen in over 2 years and you've written that you thought it might be as good as finished, so it’s not unreasonable for someone unfamiliar with the creative process to conclude that it might as well be released as it is rather than never. It’s wrong, of course, but most likely not with ill intent.

Well, I can see the merit in having a locking mechanism in that it prevents modifications by those who don't know that the author wants no changes. They'd have to actively circumvent the lock somehow, which they won't do if they respect the author's wishes. If they intentionally want to ignore the author's wishes, then previous posts have already established there's no effective safeguard. (Though that was from the DR side, it'd probably be more effective from the TDM side). If the existence of such a locking mechanism allows work to be submitted that would otherwise not be submitted it's probably all good, but on the other hand if it became a widespread practice to lock one's work I think it'd be very negative for the mod as a whole. That said, I don't think there would be many who feel they need to use such a locking mechanism, so it's maybe more a question of the effort:reward ratio for the devs to implement it. In any case, I don't think is a DR discussion anymore.

Restricting and locking isn't the right direction to take TDM or DR. For me the atmosphere would become one where we can't trust each other, and I think that would do irreparable harm over the long term. It's unfortunate that you feel such measures are necessary "especially in the context of this community", but I believe there's in fact no active mapper here who would knowingly ignore a modeller's request not to alter their work. Unknowingly is another matter, and there will probably be another bad apple in the future or from off-site, but that's a limitation of uploading your work to a project like this. As was already established, you couldn't control this even if you wanted to, and any attempts at doing so anyway would have to be weighed against how this would alter the character of TDM. Personally I think there are a lot more contributors attracted to TDM's openness than there are contributors who want to lock their work away from others.

@Geep Can you confirm that the same FM does not have these problems in 2.08? Seems odd that such basic events would not work anymore.

I'm not a programmer so can't suggest what the reason is, but sometimes it has helped to revert to 2.08 ("Get custom version") and back to 2.09 with the tdm_installer. That should go reasonably fast.

Yeah, if you have basic knowledge of how .pk4's work in TDM, are told exactly what to enter into the console and have access to an HTTP server, then it can be done very easily. I've written out explicit step-by-step instructions for laymen on what exactly to do, based on your wiki and my experience: 1. Pack all your files into .pk4's: If you want your files to be merged into existing .pk4's from TDM's base install, your .pk4's must have the same names as the existing .pk4's. If you want your files to overwrite existing files from the base install, name their .pk4's so that they sort lexicographically later. An example is z_camera.pk4. Unfortunately you can’t delete files with the patch method. To do that, you should use the differential patch method. Things that are not usually in .zip archives, like the .exe's, should go into a .zip archive called tdm_shared_stuff.zip. They will automatically be unpacked at the user's end. 2. Move the archives and zipsync.exe into an empty folder, i.e. C:/games/darkmod/packaging. 3. Start the command prompt (search for the program “cmd” on your system) and enter the following commands: cd c:/games/darkmod/packaging This makes the command prompt navigate to the folder containing your patch files and zipsync.exe. Adjust as necessary. zipsync analyze -cn *.pk4 *.zip This runs zipsync.exe for the first time, generating a small manifest of your files. zipsync patch -b http://update.thedarkmod.com/zipsync/release/release209_from_release208/manifest.iniz This runs zipsync.exe a second time. It downloads the full manifest of the 2.09 release and combines it with the manifest of your files. If successful, your manifest should grow to upwards of 2 MB. If you wanted your patch to be based on a different release, simply adjust the URL to point to a different manifest. You will also have a slightly smaller temporary manifest in your folder, representing the original 2.09 manifest. You can delete it. 4. Upload your manifest.iniz and your archives to an HTTP server. This can be either your own or one of the TDM-affiliated servers, if you have access to them. 5. To let users download the patch, you will need to tell them: the URL of your manifest.iniz the version of TDM on which the patch is built upon These download instructions can be provided to users (adjust to fit your own case): Start the tdm_installer, select "Get custom version", click on "Next". Click on release209 Paste this URL into the "Custom manifest URL" box and start the download: http://darkmod.taaaki.za.net/zipsync/dragofer/sec_cam/manifest.iniz When the download is done, you can click on "Restore old darkmod.cfg", since no graphics changes were made. Saves can only be loaded on the build they were made on.

Edit: nevermind, looks like the problem was that I should use the above line without "start". I've started cmd and entered: cd C:/personal/darkmod/packaging Then zipsync analyze -cn *.pk4 *.zip Edit2: the main problem now is that there's no 2.09 equivalent of this manifest: release208_from_release207 So I can only base my patch on 2.09b6. Shouldn't really matter since 2.09b6 is identical to 2.09, but still - I wouldn't have been able to follow the wiki instructions without looking into taaaki's mirror. So the 3rd command is currently: zipsync patch -b http://darkmod.taaaki.za.net/zipsync/beta/209/beta209-06_from_beta209-05/manifest.iniz Edit3: got it all established, now anyone can easily download (or undownload) the current state of my reworked security camera by doing the following: Start the tdm_installer, select "Get custom version", click on "Next". Click on beta209-06 Paste this URL into the "Custom manifest URL" box and start the download: http://darkmod.taaaki.za.net/zipsync/dragofer/sec_cam/manifest.iniz When the download is done, you can click on "Restore old darkmod.cfg", since I made no graphics changes. Saves can only be loaded on the build they were made on. Still got some more plans with this camera, but that's the distribution aspect sorted.

Wellingtoncrab wrote about his experiences with fx on Discord, reposting it here so it doesn't get buried: Looks like there are some flaws in the system. Would be good to know what they are, maybe they can be fixed. Making the func_fx repeat at random intervals and stop repeating when triggered is probably something I can do.

@wesp5 Usually the last beta build (release candidate) becomes the release build unless something major has broken. I think this is mostly a tradition from the tdm_update.exe days, since packaging new builds and sending them to tdm_update was a ton of work. I think this has become easier now with the new update method, but I don't know how much work it still is.

I like to think of that as a little murder mystery for players to find... not even I know the circumstances. Maybe he just stumbled over a loose plank in an unfortunate way?

@graymanNo, I'm not aware of anything dedicated specifically to the fx system on the wiki. I've just written this not long after seeing that the security camera code looks for "fx_damage" and "fx_destroyed" spawnargs (which don't exist in the current entityDef). Several search functions later it turned out that several other entity types also have code to trigger fx in specific situations (like the "fx_collide" spawnarg on moveables), and that only very few fx exist so far across core assets and all FMs. The main one is thunder. The iddevnet article will pass as documentation until we have the fx system wikified.

[Just posted this on Discord, but I think it'd also be good to post here since the FX system seems to be almost unknown.] I've just (again) come across the fx system, which is quite a neat way of coordinating a sequence of particles, sounds, lights etc. to appear without having to script or make a cascade of trigger_relays. All it takes is an fx definition like this: fx fx/sparks { { delay 0 duration 0.5 restart 0 light "lights/sparks_sound", 1, 1, 1, 96 offset 0, 0, 0 } { delay 0 sound "security_camera_spark" duration 2.5 } { delay 0 duration 2.5 restart 0 model "sparks.prt" //fadeout 1.5 //particle "sparks.prt" } } This goes into an .fx file (renamed from .txt) in the fx/ folder. A func_fx entity with an "fx" "fx/sparks" spawnarg can be triggered ingame to play it. Oddly, TDM only has a total of 11 fx (+1 if you also count all FMs), of which half are thunder-related. The system has barely been used for anything else than thunder, even though there are in fact quite a few entities, other than func_fx, that support calling fx: - moveables can have an fx_collide spawnarg - AIs can have fx_on_death and fx_on_ko - func_fracture entities can have fx - security cameras can have fx_damage and fx_destroyed - anims can trigger fx on specific frames with the fx keyword - respawning items can have fxRespawn (might be a Doom3-exclusive thing) - the player's view can have fx applied via script, i.e. an fx with a shaking effect There's seemingly no documentation of fx on the TDM domain and no real support for fx in DR. But documentation can be found in this article on iddevnet, and in a way this post could be considered a nucleus for TDM-specific documentation. Edit: iddevnet.com has gone down, but you can find a backup on the TDM server: http://ftp.thedarkmod.com/backup/iddevnet.zip P.S.: what probably goes well with fx_collide on moveables is the script_collide spawnarg. Could maybe be used to make a fragile object? More examples of fx in the spoiler:

@Frost_Salamander Yep, AIs can only come within 16 units of an MC wall, and I believe it only affects movement possibilites. If a path node is closer than that to a wall, I believe the reason it usually still works is that the AI comes within the node's tolerance zone, but you ofc don't really have tolerance left for anything else then and could easily get an AI walking circles.

You can make models invisible to AIs by giving them the "noclipmodel" "1" spawnarg (also makes them nonsolid, so would need nodrawsolid brushes if the model is large enough to be noticed as being nonsolid). It's worth seeing how applying this spawnarg to surrounding models, such as the switch casing, affects the switch.

Another possibility might be that the AIs can't see the origin of the switch because it's within the module wall.

I'd make a simple brush-built test map containing only the lamp, switch and AI, to rule out that it's an issue with the lamp.

@Zerg RushOfficially it's probably going to stay as it is (at least by default), but for yourself you can always download this .pk4 and place it in your base install. It'll turn the loot counter into a current/total counter as well as your current stealth score. Got to be logged in to get it. https://forums.thedarkmod.com/index.php?/topic/20245-view-stealth-score-during-gameplay/&do=findComment&comment=443437

If it doesn't actually work in campaigns (can test in Down by the Riverside or NHAT), then you'll probably need to workaround by using a persistant inventory item with spawnargs representing the state of the implants.

Nice work - I'm in particular curious how you were able to get persistant args to work, since I recently heard of them not working.

Seems a few things are available as both buttons and impulses. UsercmdGen.h lists buttons: Then impulses: Strangely I can only find a handful of the above names in other source files, i.e. IMPULSE_WEAPON12 in Player.cpp. You'd think that something like UB_LEAN_LEFT and UB_LEAN_RIGHT (_impulse45 and _impulse46, bound to q and e) would show up somewhere else.

I've found a translation of impulse & button names in UsercmdGen.cpp, with the outwardly visible name (like in DarkmodKeybinds.cfg) on the left and the internal name on the right. Not all impulses have given names, since some are for engine internal things like showing pathfinding areas. userCmdString_t userCmdStrings[] = { // self-explanatory names { "_jump", UB_UP }, { "_parry", UB_PARRY_MANIPULATE }, { "_creep", UB_CREEP }, { "_weapon0", UB_WEAPON0 }, { "_weapon1", UB_WEAPON1 }, { "_weapon2", UB_WEAPON2 }, { "_weapon3", UB_WEAPON3 }, { "_weapon4", UB_WEAPON4 }, { "_weapon5", UB_WEAPON5 }, { "_weapon6", UB_WEAPON6 }, { "_weapon7", UB_WEAPON7 }, { "_weapon8", UB_WEAPON8 }, { "_weapon9", UB_WEAPON9 }, { "_weapon10", UB_WEAPON10 }, { "_weapon11", UB_WEAPON11 }, { "_weapon12", UB_WEAPON12 }, { "_reload", UB_RELOAD }, { "_weapon_next", UB_WEAPON_NEXT }, { "_weapon_prev", UB_WEAPON_PREV }, { "_ready", UB_READY }, { "_center_view", UB_CENTER_VIEW }, { "_objectives", UB_OBJECTIVES }, { "_crouch", UB_CROUCH }, { "_mantle", UB_MANTLE }, { "_inventory_grid", UB_INVENTORY_GRID }, { "_frob", UB_FROB }, { "_lean_forward", UB_LEAN_FORWARD }, { "_lean_left", UB_LEAN_LEFT }, { "_lean_right", UB_LEAN_RIGHT }, { "_inventory_prev", UB_INVENTORY_PREV }, { "_inventory_next", UB_INVENTORY_NEXT }, { "_inventory_group_prev", UB_INVENTORY_GROUP_PREV }, { "_inventory_group_next", UB_INVENTORY_GROUP_NEXT }, { "_inventory_use", UB_INVENTORY_USE }, { "_inventory_drop", UB_INVENTORY_DROP }, // legacy names { "_moveUp", UB_UP }, { "_moveDown", UB_DOWN }, { "_left", UB_LEFT }, { "_right", UB_RIGHT }, { "_forward", UB_FORWARD }, { "_back", UB_BACK }, { "_lookUp", UB_LOOKUP }, { "_lookDown", UB_LOOKDOWN }, { "_strafe", UB_STRAFE }, { "_moveLeft", UB_MOVELEFT }, { "_moveRight", UB_MOVERIGHT }, { "_attack", UB_ATTACK }, { "_speed", UB_SPEED }, { "_zoom", UB_PARRY_MANIPULATE }, { "_showScores", UB_SHOWSCORES }, { "_mlook", UB_MLOOK }, { "_button0", UB_BUTTON0 }, { "_button1", UB_BUTTON1 }, { "_button2", UB_BUTTON2 }, { "_button3", UB_BUTTON3 }, { "_button4", UB_BUTTON4 }, { "_button5", UB_CREEP }, { "_button6", UB_BUTTON6 }, { "_button7", UB_BUTTON7 }, { "_impulse0", UB_WEAPON0 }, { "_impulse1", UB_WEAPON1 }, { "_impulse2", UB_WEAPON2 }, { "_impulse3", UB_WEAPON3 }, { "_impulse4", UB_WEAPON4 }, { "_impulse5", UB_WEAPON5 }, { "_impulse6", UB_WEAPON6 }, { "_impulse7", UB_WEAPON7 }, { "_impulse8", UB_WEAPON8 }, { "_impulse9", UB_WEAPON9 }, { "_impulse10", UB_WEAPON10 }, { "_impulse11", UB_WEAPON11 }, { "_impulse12", UB_WEAPON12 }, { "_impulse13", UB_RELOAD }, { "_impulse14", UB_WEAPON_NEXT }, { "_impulse15", UB_WEAPON_PREV }, { "_impulse16", UB_IMPULSE16 }, { "_impulse17", UB_READY }, { "_impulse18", UB_CENTER_VIEW }, { "_impulse19", UB_OBJECTIVES }, { "_impulse20", UB_IMPULSE20 }, { "_impulse21", UB_IMPULSE21 }, { "_impulse22", UB_IMPULSE22 }, { "_impulse23", UB_CROUCH }, { "_impulse24", UB_MANTLE }, { "_impulse25", UB_IMPULSE25 }, { "_impulse26", UB_IMPULSE26 }, { "_impulse27", UB_IMPULSE27 }, { "_impulse28", UB_IMPULSE28 }, { "_impulse29", UB_IMPULSE29 }, { "_impulse30", UB_INVENTORY_GRID }, { "_impulse31", UB_IMPULSE31 }, { "_impulse32", UB_IMPULSE32 }, { "_impulse33", UB_IMPULSE33 }, { "_impulse34", UB_IMPULSE34 }, { "_impulse35", UB_IMPULSE35 }, { "_impulse36", UB_IMPULSE36 }, { "_impulse37", UB_IMPULSE37 }, { "_impulse38", UB_IMPULSE38 }, { "_impulse39", UB_IMPULSE39 }, { "_impulse40", UB_IMPULSE40 }, { "_impulse41", UB_FROB }, { "_impulse42", UB_IMPULSE42 }, { "_impulse43", UB_IMPULSE43 }, { "_impulse44", UB_LEAN_FORWARD }, { "_impulse45", UB_LEAN_LEFT }, { "_impulse46", UB_LEAN_RIGHT }, { "_impulse47", UB_INVENTORY_PREV }, { "_impulse48", UB_INVENTORY_NEXT }, { "_impulse49", UB_INVENTORY_GROUP_PREV }, { "_impulse50", UB_INVENTORY_GROUP_NEXT }, { "_impulse51", UB_INVENTORY_USE }, { "_impulse52", UB_INVENTORY_DROP }, { "_impulse53", UB_IMPULSE53 }, { "_impulse54", UB_IMPULSE54 }, { "_impulse55", UB_IMPULSE55 }, { "_impulse56", UB_IMPULSE56 }, { "_impulse57", UB_IMPULSE57 }, { "_impulse58", UB_IMPULSE58 }, { "_impulse59", UB_IMPULSE59 }, { "_impulse60", UB_IMPULSE60 }, { "_impulse61", UB_IMPULSE61 }, { "_impulse62", UB_IMPULSE62 }, { "_impulse63", UB_IMPULSE63 }, { NULL, UB_NONE }, Names for keyboard keys on Windows can be found in win_input.cpp: For completeness, here are the full contents of my DarkmodKeybinds.cfg file:

I'd add that an impulse is a one-time command in the game, i.e. select the next item in the inventory. A keyboard key can be bound so that it triggers such an event. Slightly confusing that the continuous form of "impulse" is called "button" (i.e. move forward). Both are assigned to keyboard keys. Maybe a list of all available impulses and buttons in the engine can be found somewhere in the source code.

I can see the following lines at the bottom of my DarkModKeybinds.cfg: bind "MWHEELDOWN" "_impulse47" bind "MWHEELUP" "_impulse48" Inserting those should bind weapon scrolling and page turning to the mouse wheel.

I loaded into a few missions with a 32bit .exe I compiled from 2.09b5 with no problems, but I didn't spend much time in them. The main objective was to see if Painter's Wife will load on 32bit with 2.09, which it still doesn't. But it's always been that way.