Geep

My first map (way back as a wad file for original Doom 3) was of my basement. I had a demon popping out of my refrig. So yeah, there's a tradition to map what's close at hand. Vids are great, but it's hard to use them as a reference, to try to remember where you saw a particular problem solved. A general Google vid search (relying on YouTube's automatic speech to text transcripts) I don't find too effective. For written content about DR mapping, some reasonable starting points are the Dark Radiant user manual and Fidcal's A to Z Beginners Guide, https://wiki.thedarkmod.com/index.php?title=A_-_Z_Beginner_Full_Guide_Start_Here!. I'm doing my 2-cents here and there on the wiki too. The writing continues!

If you ever wondered what a .proc file actually contained & why, there's now a wiki page page on it: https://wiki.thedarkmod.com/index.php?title=PROC_File_Format It's a treatment of a complicated subject, so I can't guarantee I've got it 100% right. Just more right than anything else I've seen about it.

Yup, looks like ample breakage possibilities.

Directory structure is working now. The path to the executable is a bit funky (via the source directory), when local debugging is run directly from VS. It becomes: [my drive and user account]\Games\tdm11dev\darkmod_src\..\darkmod\TheDarkModx64.exe That's set by the call in win_main.cpp to Sys_EXEPath, which gets the path from GetModuleFileName (resolves to GetModuleFileNameA). The string is passed up to Sys_DefaultBasePath (which strips the filename off), and back up to the game init code. Don't know if GetModuleFileNameEx would be better for this, give a cleaner path. Or if this weird path breaks anything, other than unnecessarily stressing the MAX_PATH boundary. Do you guys usually set one of the "fs_..." command-line args to deal with this?

OK, I'll try to rearrange to that directory layout. I'll have to lookup how to do that without screwing up Tortoise. I'm not on that machine at the moment, so I can't check your BTW. I don't remember about "branches", but I do remember a local "tags" directory... don't know if it was populated.

The build succeeds now with the latest. Yea! However, evidently the directory structure is not quite right for debug to work. I followed what the compile guide said (I think), with these 2 directories: ...Games/tdm11dev/darkmod_src/trunk/TheDarkMod.sln (etc.) [using TortoiseSVN] ...Games/tdm11dev/darkmod/TheDarkModx64.exe (& all the .pk4s, etc) [using tdm_installer] It appears that the build process puts the results in ...Games/tdm11dev/darkmod_src/darkmod/ I tried changing adding a "." to the project output location to move the directory up one, i.e., DarkModTools property sheet, for the debug x64 configuration: Configuration Properties; General; Output Directory [changed from] $(SolutionDir)..\darkmod\ [to] $(SolutionDir)...\darkmod\ But that seemed to generate build errors subsequently, so reverted. I can probably munge this up so it works, but thought I'd ask your suggestions first.

Sorry, I got waylaid putting up a new wiki page about the proc file format: https://wiki.thedarkmod.com/index.php?title=PROC_File_Format which you expert blokes are invited to poke holes in, as time & interest allows. I'll try to reload 2.11 source this weekend.

Used the public svn, not the team svn. Some forum comment made me think that 9881 was more stable its successor. I don't really need the very latest, at least not right now. TDM 2.10 would've been fine too, but who knows, maybe some issues building under VS 2022? I'll try a later 2.11 revision as stgatilov suggests... probably won't be today though.

Just looked at the wiki writeup. Maybe the "transfer of locking info" happens ONLY you use the alternative method with door_controller1 specified. I'm thinking for a controller, just create a func_static plate, make it frobbable, have it trigger the door. There's a texture of a keyhole you can use on its face.

No, it's because Away 0 used that method, which was inherited from _Atti_'s original construction from a decade and a half earlier. So I don't have anything against the door controller method, but alas no real insight about it to share with you either.

Greets. I just setup VS 2022 Community/VC++/MFC on a fresh box, and did a Checkout with TortoiseSVC from the public repository of build 16481-9881 (matching a fresh 9881 dev install of TDM environment, as required). When I do the build, I get a link error: Can't find file libavcodec.lib I'm not finding that file in the working repository, although I do see the libavcodec folder and avcodec.lib If I select DarkModTools/Properties, I'm able to go to the Link/Input field and see where libavcodec.lib is listed, but I can't edit it to change it to avcodec.lib (says it's inherited) I'm kinda rusty, haven't used VS since 2015, so this may be a trivial thing. Help?

Hmmm, rat pathfinding might work for small animals like cats, lizards. But for humanoids, I was thinking of 3-4 foot tall characters, so probably would need a separate pathfinding script.

HMart has large AI on a wishlist. I'd kinda like small AI with associated animations. For humanoids like hobbits, elves, kids, goblins, dwarfs, leprechauns. Animals like cats, dogs, snakes. Less ambitiously, with existing animations, a few more female heads and/or bodies wouldn't hurt. Female inventor or chubby engineer, for instance.

I've further revised this. I've had to make some assumptions about the "non-project" form of file organization, where you place your .map file in <darkmod>/maps/, and any custom resources in sibling folders, for instance, <darkmod>/materials/. The assumptions are: 1) That the current TDM version still supports non-project custom resources in this way 2) That DR will not be able to find the custom resources, because it can't set a Game Project location for those resources. 3) That a custom resource placed in a folder like <darkmod>/materials/ becomes global and visible to all FMs within <darkmod>, not just those in <darkmod>/maps/, but also those in: a) <darkmod>/fms/<FM>/maps/ in non-pk4 form b) <darkmod>/fms/<FM>/maps/ in pk4 form Anyone, are any of those assumptions wrong?

OK, I've updated parts of Page 1 (and a bit of Page 5) of the A - Z Beginners Guide, to cover a choice of using project and non-project file structures. That part's hopefully clearer and certainly longer, but I shortened the intro. No plans to revisit rest of that guide. That would be Labors of Hercules.