Geep

Agree with that, but I suppose there could be some backward compatibility issues if changing that behavior. BTW: Wiki wording changed RE controller on just 1 side of door

Yes, I read it as just citing an example. But I'll change the wording to be less ambiguous. Also, for I also would have thought that setting ai_should_not_handle on the secret door would still allow the AI to go through it if its open. But if not, and by design, then an easy workaround (once established) should be documented.

Just to understand, the outcome of this discussion (and bugtracker post) so far is that: - The wiki post is correct as is. "frobable" on the door IS considered by the AI. So if "frobable 0" and the door has a controller that accessible to the AI, the AI will use it. - except if fleeing, and that is a bug.

*crickets* Well, that question must of been too obscure. I'll come back to that, but first help me clear up GUI command "runscript", that could appear in an event handler code block. I'm going to claim, despite some engine C++ code to parse it, that - on purpose - this command no longer works in TDM. In either form, "runscript ..." or "set 'cmd' runscript...". If you know about this, please either agree with that claim, or provide a counter-example, such as a working test map or a pointer to an FM that successfully has a GUI file that uses runscript. Thanks!

A broader GUI issue: I'm struggling to adequately understand "gui::" variables. I've got a series of questions, but let me start with 2 basic ones, having to do with scoping. I’m going to use the general term “guiDef” to refer to “windowDef”, “choiceDef”, etc. 1. Internally, I think "gui::" variables are those stored in idDict structures. With respect to a given GUI, is there a single idDict for an entire GUI (i.e., top-level on down), or does each guiDef (top-level or nested) have its own? 2. Is there also (or instead) a “global” idDict, across all GUIs in an FM? Looking mainly for TDM-specific answers from our gurus. Thanks.

Just checked. Yep, that list was actually based on 2.08 data. I'll update to 2.10 (not today tho). Glad you caught that. Edit: Now updated

@greebo, I've updated this page to include your point about set "cmd" not available to mappers: https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_Parsing_of_Set_'Cmd'

Actually, set "cmd" log... was described in the Doom 3 docs, but I did earlier confirm the syntax as used in the main menu system. Those docs didn't indicate it couldn't be applied to player or entity GUIs. What I'm trying to do now is develop TDM-specific documentation, so knowing what won't work is fine. Although I might put in a bugtracker feature request to get set "cmd" logging more generally available, for the obvious assistance it would give to mapper GUI debugging. From what you say, I guess there's no point in testing set "cmd" runScript... There is the other version (just "runScript...") I need to experiment with. BTW, thanks for clarifying the handle & overlay situation. EDIT: Just runScript, while quietly parsed, doesn't seem to me to try to execute the script function.

Also, when I first started working with TDM, I was very concerned about all the warning messages. Now, I'm more laissez faire (or maybe just fairly lazy). This is just an FM I'm building, not the James Webb telescope.

@Nort Entity 0 and worldspawn are the same thing. More exactly, in the .map file, all worldspawn brushes and patches are listed anonymously under entity 0. Also, I don't know if this is relevant to your DR Default issue, but if you have your work organized by projects in <FM> folders, and you have created custom textures (or other custom assets), you have to make sure you tell DR which project to use currently. Otherwise, textures will appear missing in DR.

Playing with my earlier version of the .gui file, to try to understand why it didn't work. Main problem turned out to be that a user variable (in spite of Doom 3 documentation suggesting otherwise) needs to be terminated by either a ";" or a "0". I'm adding that to one of my draft articles, working title "Syntax from Hell". This now works, approximately same behavior as greebo's version (if less elegant): windowDef test { rect 0, 0, 640, 480 backcolor 0,1,0,1 visible 0 notime 0 float vis; // must either end with ";" as here, or 0 onTime 0 { if("vis" != "$gui::is_visible") { set "visible" "$gui::is_visible"; set "vis" "$visible"; set "cmd" "log 'visible changed'"; } } onTime 100 { resetTime 0; } } @greebo, what is still a mystery is why the logging you see here is not working. Not showing up in either qconsole.log or DarkMod.log. Is there some .cfg value that must be set? Or a special log file I'm not aware of?

@greebo, confirmed that works. Wonderful! But now some questions, starting with the .script side. I did play around with setGuiInt for a while, but then concluded that it (and other setGui... SDK calls) couldn't work, because inside the C++ code, it looks to confirm that the passed handle is in the m_overlays list. I kinda thought that a handle for a gui that was on a world object's surface would not have an overlay defined for it. So I'm confused again. Does overlay not refer to a 2D pane rendered in the same plane as the screen? When I was working with setGuiInt, since I wasn't instantiating the world surface gui myself, but relying on autoload, I didn't have the handle number, so I would find it using: string s; sys.println("handle hunt"); for (i = 0; i < 10000; i++) { s = me.getGui(i); if(s != "") // could do a better job of string comparison here, but works for test map { handle = i; sys.println(s); break; } } sys.println("handle =" + i); That was returning a value of 1. But what you seem to be saying is, the handle has to be 1 for the gui defined by "gui". True? And presumably that goes for "gui2" (handle = 2) and "gui3" (handle =3), but maybe not beyond that?

@Nort Yes, it's a spawnarg. In TDM, if you are calling a function from a spawnarg that's designed to do that, it will want a particular form of the function. If you don't give it what it wants, you often get a stack underflow because of a mismatch in parameters. User input parameters and output results are often passed in separate spawnargs, agreed upon by caller and callee.

@greebo, here it is: https://drive.google.com/file/d/19sAIHOtVZYkkNtfzwLOB-Fq8NCSsD8a6/view?usp=sharing This is not full fledged, so needs to be started with "map testgui", not through main menus. You'll see a green surface, with brown side walls. If you frob it repeatedly, nothing happens, but you can see in the console that the frob script is trying to toggle the visibility of the green surface.

To use the frob_action_script call, you must supply a function with the signature "void myfrobfunc(entity)". There a multiple ways to persist a value between function calls; I just used one that I like. If instead of a simple function, you were writing a script object, you'd typically make it a variable of the object (again, declared outside the body of any member function).

Sorry if I confused. What I meant was that this: float vis = 0; needs to be declared at the beginning of the .script file that contains the onFrob() [and maybe other functions in general] and outside the body of onFrob, so the value will persist between onFrob invocations, not just be temporary. Like the scoping in C. BTW, I believe tels is no longer active with TDM, so guidance must come from elsewhere.

I've been working on prepping some basic info about TDM-specific gui scripting, and there's an issue that has me stumped, having to do with a gui on a world object's surface... NOT an overlay. I'd like to influence what that gui does from a .script (either regular or script object, and by passing either values or using calls), but haven't been successful. I understand that TDM's version of idTech4 has reduced functionality for guis on world surfaces, but still.... If you want to take a wack, here's details. As always, could just be syntax problem. Thanks for any help

I'm thinking that door controllers is mostly a generalization and repurposing of the earlier froblock/chest/lid way of looking at things. As to the highlighting, whether you want a door to highlight when to frob the separate lock, or vice versa, I guess is up to the mapper. That's mainly what the method discussed under Chests brings to the table, I suspect.

Your edit makes sense to me, given your findings. Since you've now folded in atdm:froblock under the Door Controllers method, I've moved the section about "...Door with a Froblock Lock Plate", previously at page end (and that you had linked to in your post above), to just be a child and continuation of Door Controllers.

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.