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.

Your post helped me understand the darkmod/maps use case (evidently called the "non-project" method), which my tiny, tidy brain [] couldn't quite grasp before. That will help inform my rewrite of the beginning part of A to Z Beginners Guide Page 1 that probably led you astray. Given the confusing shortcomings of non-project for non-trivial FMs, I'm going to steer the reader towards the "project" method (i.e., darkmod/fms/<FM>/maps) instead... what Destined may have intended with his "File Structure" section.

I agree that the first page of the A to Z tutorial, containing the section on File Structure, could use some clarification and freshening. (I'll see what I can do.) Someone else who is better with blender should address your export issues. Probably involves a materials (.mtr) file.

To follow up. Do make sure you use the same name for your FM folder, .map file, and (if you use it) the first line of your startingmap.txt If I were you, I'd postpone custom model efforts until you can arrange your folders to reliably get game selection, dmapping, and mapping to work. If those are working correctly, then you should be able in DR's Game/Project Setup to see a list of available FMs and let you select yours. If you don't have Project Setup pointing to the right place, then any custom materials defined in your FM will often appear incorrectly in DR, e.g. as nodraws. Also, sometimes DR generates files, and those could end up in the wrong place too.

I'm heading out the door, but I can probably answer this one quick. I use the same folder structure as you quoted for Neon's Style, except it must be ...fms/mymission/maps/mymission.map and under fms/mymission/, make sure you have darkmod.txt, readme.txt, and all other folders you might make.

Working on more wiki pages. As I kind of an aside, I got curious about inlining, which I saw occasionally mentioned but not really explained. So I researched it with the results now here: https://wiki.thedarkmod.com/index.php?title=Inlining

I think you're saying is, with Groups, the rotation point (origin) is automatically determined and can't be changed, but with func_group, it can be. My chief concern about func_group is that you would move a func_group around loosey-goosey as an entity, but then it would end up off-grid when auto-converted to worldspawn, causing headaches. Unless you can snap a func_group to a grid? Otherwise, limits use in, say, modular building. Thanks for the feedback. I can add something about the custom filter, too. I'm not going to over-sell func_group

I think there wouldn't be embedding (other than transiently) during the while loop, but you are correct that the last two statements beyond the loop embed it halfway. Might be OK if that was a cushion or straw. Otherwise, taking the gem radius into account would be better. (That could just be baked into "tabletopheight".)

Could you expound a bit on why this is true? For one of my planned wiki articles. Thanks.

@Spooks Sorry for posting to this old thread, but I'm using it as a basis for a wiki page about func_group. Could you take a look at it and see if it needs changes? Thanks https://wiki.thedarkmod.com/index.php?title=The_Parts_and_Whole:_Func_Group

That's why I was thinking a force field might be necessary.