Search the Community

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.

Interesting... An enclosure with a full color screen on it. I wonder how it knows how full the file system on the installed drive is? I didn't think enclosures were "smart" enough to know that; how is it supposed to know if I'm using Btrfs or Ext4? And how long before someone hacks one of these to play Doom?

DarkRadiant 3.6.0 is ready for download. What's new: Feature: Selection Focus (Ctrl-F) Feature: Add Radiant.findEntityByName script method Feature: Media Browser shows a thumbnail preview when selecting folders Feature: Map is remembering layer visibilities between loads Fixed: ModelDefs are shown in T-pose Fixed: Patch vertices are the wrong colour Fixed: Shader Clipboard source gets cleared on 'copy shader' operation Fixed: Nodes of hidden layers are still visible after loading the map Fixed: Can't close properties window Fixed: Merge Action rendering is broken Fixed: After using ToggleMainControl_Camera, the center panel is grey after restart Fixed: When using ToggleMainControl_Camera, arrow keys cannot be used to move the viewer Fixed: Property Panel not remembering undocked/closed tabs Fixed: Texture Tool not updating during manipulation Fixed: Orthoview ignores filters for surfaces in models Fixed: Blue dot when selecting one face removed Tweak: Conversation Editor: double-click opens selected conversation Tweak: Preference option to disable drag select in camera view Tweak: ESC key should clear the resource tree view filter text Tweak: New layers function: tooltip popup getting in the way Feature: Selection Focus (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.6.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

I refer to Doom 3 in general, at least the original game engine from 2003. All comparisons are operations which are part of expressions. In order to evaluate expression, you need to store temporaries somewhere, and combine them with each other through a sequence of operations. In case of GUI scripts, the temporaries are called "registers". These registers are floats, they simply cannot hold a string. Actually, I have just found the commit where I removed the comparison, and here is what it says: Revision: 16537 #5869. Removed incorrect comparisons with empty string ( == ""). The scripting language does NOT have string values, it only has float values. So when you reference some string variable in expression, it gets value 0.0 if string is empty and 1.0 otherwise. For this reason, there is no sense in comparing to "" (which is actually replaced with 0 because no variable with empty name is found). So the "!=" operator is just a weird way of writing != operator, doublequotes don't change anything. And a string value inside expression is immediately converted into float with 0 or 1 depending on whether it is empty or not. There is no string comparison, but there is checking for emptyness. Multiline macros work as they did, in fact the change is about fixing them! There are several different but related things, and they get into a confusing mix here: Token concatenation used for multiline macros, which comes directly from C/C++ language. String literal concatenation with backslash is optional feature of idLexer --- it does not exist in C/C++ language. String literal concatenation by writing them one after the other --- standard feature of C/C++, disabled in D3 GUI. Here is the full commit message: Revision: 10031 #5869. Don't enable string concatenation by backslash (\) in GUI code. GUI code uses doublequotes everywhere to make names like gui::my_var atomic, since otherwise parser would break them into many tokens. For this reason, string concatenation is disabled in lexer (that's when you can write "hello" " " "world", and C will treat it as single string "hello world"). However, ID enabled special string concatenation via backslash to substitute for it, like this: "hello" \ " " \ "world" The problem with such usage is that it breaks multiline macros. Due to limitations of GUI code, we have to write whole window (even with subwindows) into a macro in order to make it reusable. If any line in such macro ends with a string literal (that's very likely in GUI code), then parsing breaks and whole macro does not work. This can be worked around by moving the first token on the next line to the end of the current line, but it is very messy and totally not obvious. Better just forbid string concatenation altogether. Buy the way, the following way of concatentating string works (at least inside macro): "hello" ## " " ## "world" Note that ## is a standard C way of concatenating tokens, although in C it works on TOKENS, not on string literals --- but here they are mixed anyway. Also, it is even possible to do this: #define HELLO_MESSAGE(index) "Hello, " ## #idx ## "-th user!" Which is very useful to construct variable names inside macros =) The work is finished, although it might get some changes if any related bugs are reported e.g. during beta. I don't think we can give access to single thread. If you miss some info, just ask me and I can copy/paste or explain in my own words. The two references you gave here are about: expression evaluation order fix, expressions in Set command, change in register disabling behavior. They are described in this public post too:

@stgatilov, you said, RE string comparisons: I'm unclear if you are referring just to changes you made in 2.11. I think equality testing of two strings (one of which is "text") was working and is a good and expected capability, and should be supported. Including against an empty string. I noticed in your bug activities that you did remove some comparisons with ... == "". I see you also removed string concatenation with "\". No problem, but does that mean multiline macros are no longer a thing? (If so, I'll need to change some examples) BTW, the series so far hasn't really tried to cover the 2.11 changes, since I figured it's a work in progress. But since you did a great deal of GUI work in July, perhaps it's stable enough to try to consider it. I see the logs listed in bugtracker, but don't have access to the private forum threads mentioned there: https://forums.thedarkmod.com/index.php?/topic/20526-gui-refactoring/&do=findComment&comment=477179 https://forums.thedarkmod.com/index.php?/topic/21535-order-of-evaluation-in-expressions-materials-and-gui/ (Nor do I have SVN currently set up on my newer machine, for changelogs from there.) Any place else I should look?

Judging from the original state of GUI code, I suggest the following likely explanation. The GUI scripts and the docs were written by a person different from the one who implemented C++ GUI engine. He tried some stuff, and it worked, or appeared to work, so he decided it was correct. But it was not, but still worked (maybe always, maybe most of the time). Unfortunately, the original Doom 3 GUI engine is so bad that you cannot deduce what's correct way of doing things by merely experimenting with it. It could be e.g. the weird register deactivation rule, or the obscure "all expression are evaluated at some time before script handler" concept.

-> https://forums.thedarkmod.com/index.php?/forum/13-music-sfx/

I mentioned this in the improvements thread - https://forums.thedarkmod.com/index.php?/topic/11058-things-that-could-be-improved/page/95/#comment-473534 Bright readables in a game that is 99% darkness literally burns my eyes.

@HMart, you took issue with me saying: This was my summary of what I thought you meant in these post fragments from a forum linked to by Ref 10 (namely, https://forums.thedarkmod.com/index.php?/topic/20100-idtech-4-gui-scripting/#comment-439778 )... I see I probably shouldn't have added the "[as float parameters]" to the ambiguous "as well" phrase, and perhaps "recommended TDM try" is too strong. Overall, would this be better? "In Ref 10, it is noted that in transition statements, a 4-value color vector must be either a literal or (less reliably) a definevec4. Using a #defined macro for the color vector won't work currently... an idea for a future improvement?" EDIT - I see that a broader revision was needed. So changed to this in https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_TDM_vs_Doom_3,_Quake_4 ====transition 4-6 parameters==== Often, transition statements have a pair of 4-value color vectors as their 2nd & 3rd parameters. As the discussion in [[GUI Scripting: References & Resources | Ref 10]] indicates, each vector is traditionally represented by a double-quoted literal: transition "matcolor" "1, 1, 1, 0" "1, 1, 1, 0.8" "300" This was id Studio's preferred method, but using a definevec4 user variable was a possible alternative. In addition, TDM can #define colors for transitions. Unfortunately, due to syntax differences, for a particular color, it is not possible to create a single #define that would work with both properties and transitions; thus: #define INACTIVE_COLOR 0,0,0,0.50 #define SINACTIVE_COLOR "0 0 0 0.50" See [[GUI Scripting: Preprocessor Directives]] for further examples. (Possible future improvement: Changing TDM's parsing to let a transition also accept color vectors with commas.) See also the discussion above about 4vect properties and _x, _y, _z, _w suffixes.

Recently I started listing the Abandoned Works on a wiki page. Looking through some of the project folders I encountered assets that were posted on the forum years ago (for example this fish), but I never read about them before. I don't think the forum is good for listing assets, it's off course good for discussing. So I was wondering maybe it's an idea to make a list of game assets, including scripts, centered in one place? Knowing the assets exists, people are able to find it on the forums (placing direct links on the wiki page will get outdated). I might have to ask people for permission.

I remember some idSoftware dev on Doom3World forum saying exactly that, they also said that in float "somevar" "0" the "0" is ignored From iddevnet, but you can look at the c++ and see if is true or not just to make sure. That is indeed not correct, unless is for Doom script... idSoftware says for Gui script user var definitions you should do: float myfloat or float "myvar" "0" // see above about zero or other value being defined here at user var definition Hum you maybe right but Doom 3 main menu does uses that "!=" if ( "SGC1Title::text" "!=" "" ) { set "forecolor" "0.6 1 1 1" ; set "SGCBtn1EdgeG::matcolor" "0.5 0.7 0.8 0.5" ; set "SGCBtn1BorderG::matcolor" "0.5 0.7 0.8 0.5" ; set "SGCBtn1CornerG::matcolor" "0.5 0.7 0.8 0.5" ; set "noevents" "0" } This is awesome info and explains why some of my ifs didn't seem to do what i expected. but is that still true, if you change it through c++, using "_gui->SetStateInt("gui_var", value);" or is only when doing it from Doom Script?

I recommend going to changelog and roadmap in bugtracker and looking through issues that are about GUI scripting. I'm pretty sure there were some major changes which are worth taking into account when writing a tutorial. Maybe even give a list of these tickets somewhere, because if people come from other Doom 3 mods, they can get wrong impression, since stock Doom 3 engine has more bugs and some different behavior. Speaking of putting double-quotes vs not putting them: I think it is a good idea to enclose every item in double-quotes. Literal numeric values are perhaps the only exception. Internally, lexer breaks the text into tokens, and each token is treated as single item. Characters like colon, dot, or dollar break name into several tokens, so you have to enclose such items into double-quotes. In fact, adding double-quotes is never a problem since lexer always removes them, emitting their contents as single token of type "string". The only case where it is a problem is with literal numeric constants, since the GUI parser expects to see them as tokens of type "number". Regarding "initialization" and "updates" of properties. When you declare a property, you can write any expression on the right side, potentially referencing some non-constant things there. Normally, when some of these things change, the property is reevaluated automatically. However, this can get you into trouble is you assign something into the property using Set command... so there is a concept of "active" and "non-active" properties, or "enabled/disabled" properties (not sure about canonical terms). Some things disable/deactivate a property. The rules of original Doom 3 were weird in this regard (6028), but in upcoming TDM 2.11 I think the only way to deactivate a property is to Set something into it, or start a Transition of it. Deactivation happens in runtime, not statically, so the property will keep updating before the first Set is done. The section User Variable says this is OK syntax: float crouch_scale=0; I'm sure this is not correct, and hope that recent dev builds produces a warning on it. String comparison section says that there is some special "quoted comparison operator": if ("LSGSaveGameNameEntry::text" "!=" "") { I don't recall seeing anything specific regarding double-quotes around operators. Moreover, GUI parser cannot see double-quotes, since lexer will replace it with a single two-character token of string type, that won't work properly with GUI parser. Moreover, I don't see any occurance of quoted "!=" in current .gui files, so I guess it was a buggy code that got fixed. I think there is no string comparison, because all expressions and their intermediate values are floats, they simply cannot hold strings. In Precedence section, there is discussion about parentheses. Yes, you can put parentheses in GUI expressions, and rely on normal evaluation order otherwise. The discussion about macros here might be a bit confusing, because GUI engine has nothing to do with #defines, in fact it does not even see them. Just like in C language, all the directives starting with #sharp are handles by totally separate thing called preprocessor, the GUI parser will see all macro references replaced by whatever they point to, so for the GUI parser it would be just a gigantic expression with two levels of nested parentheses. I would probably be better to stress this in tutorial, because this understanding of preprocessor as an entirely separate step can help on many occasions. There is Multiple If section, which totally lacks the most important caveat of GUI ifs that usually kills all attempts of writing any complicated logic in GUI scripts! While you can write expressions inside If conditions (and now also on the right side of Set command), they are evaluated not when you normally expect it to! All the expressions are evaluated before script commands are executed. So if you Set the value of "gui::myvar" from 0 to 1, the following "if (gui::myvar)" will still be considered false. I believe all the expressions are evaluated at the same time, regardless of whether they are on the right side of property definition (aka 'visible "gui::LootIconVisible"') or inside script. This is very important to understand when you write expressions, since normal people assume that script commands are evaluated sequentally, and their changes are propagated immediately. And yes, you can write nested ifs, but with the caveat of early evaluation they probably won't give you much. UPDATE: I see it mentioned in Changing User Variables. And yes, it should apply to properties too, simply because the problem is on the other end: the change is applied immedately, but conditions and expressions are evaluated earlier. Perhaps correct this misconception here, and mention it in Multiple If section too (never too much). Regarding onTime event. You wrote there '"reset" command', perhaps change it to '"resetTime" command'. Regarding onTime 10 instead of onTime 0 in main menu. I think one reason of doing so is to ensure order of triggering handlers. Imagine that you have 50 "onTime 0" handlers, but you want to ensure that some of them are evaluated after the others. Adding small time offsets is the only way of hacking around it. Regarding vector components. The original Doom 3 code intended to make them accessible via indexation, like v[0], v[1], v[2], v[3]. But the code had a terrible bug, so it did not work. In TDM 2.11, it works (6028). UPDATE: also here

Gui language has full-blown support for preprocessor macros. In fact, it is done via the same exact code as in game scripts. If something does not work with them, it's either some custom settings of GUI lexer, or just the GUI language not understanding what you pass to it. In fact, C preprocessor is the only way to implement reusable code in GUI scripts. But in order to use it properly, you need to be an expert in C, with stuff like #include and include guards, ## -- concatenation and # -- stringization, and know about single expansion rule, etc. Just look at tdm_objectives_core.gui and tdm_subtitles_common.gui in the latest dev build, and you'll know what I mean, This is not pointer for certain. It is a very specific hack to link to variable specifically in Transition command. The rules regarding what is considered a string and what can be turned in to a link are not obvious and consistent, as well as the rules about when engine evaluates all the expressions/conditions. Yes, macros don't have namespaces, so you should always prefix your stuff with your domain, or/and undef your macros when they are not needed. Actually, the GUI windows have no namespaces either, so you can get name collision here just as easily. You need a lot of discipline (like in pure C programming) in order to work with large codebase in D3 GUI. Even with the recent 2.11 improvements which add previously nonexistent error reporting. According to the code, dollar only works in Set and Transition right now. This is not a macro at all. Here you define a custom window register. And you reference it only in some locations, as far as I remember. They probably ignored the advanced GUI scripting because it did not work... or the vice versa: they did not use it, thus it did not work Doom 3 code had so many bugs in GUI handling, and lack of any error reporting. I am impressed that TDM guys managed to implement such a complicated main menu with this mess and maintain it for years. As for C preprocessor, I don't know. Maybe they did not reuse any of their GUI code, simply copypasted it around without any worries about future maintenance.

I have not read your wiki about the gui scripting, so sorry if this was already known by you and talked about, but if not, imo is always good to know that gui scripting language, can do a little more than what idSoftware used and talked about. Unless i failed to see where idSoftware talked about this stuff. I discovered this by accident, when I tried a few stuff that Doom Script supports, to see if they worked with gui scripting and they did. For example the gui language, other than #include also supports #define, just like Doom Script, thou in a more limited way, so you can do basic text substitution using #define like: #define COLOR_WHITE 1,1,1,1 #define WIND_HEIGHT 480 #define WIND_WIDTH 640 or more complex #define RECT_SIZE ((WIND_HEIGHT/2)-(320/2)),((WIND_WIDTH/2)-(240/2)),320,240 then used as: rect RECT_SIZE ----------- It also has basic support for pointers! using $ sign, example: transition "start_white::matcolor" "$Desktop::COLOR_WHITE" "$Desktop::COLOR_BLUE_07" "1000"; and other capabilities that I may be forgetting, have not messed with gui scripting for ages now. Thou i remember macro and pointers support was not free of problems, there's some idiocentricities with this stuff, for example macros using #define and defined in the global space, meaning outside the main desktop windowdef or any other windowdef, work globally and are accessible directly by name (just like in Doom script), but seem to work, only in some things, like "rect", "backcolor" and others but not in transitions, I remember having trouble with those, the only thing that worked well for this ones, was defining the "macro" in another way, like this and inside the main desktop windowdef: definevec4 "COLOR_WHITE" 1,1,1,1 Despite #define COLOR_WHITE 1,1,1,1 and definevec4 "COLOR_WHITE" 1,1,1,1 looking similar and apparently do the same thing, behind the scenes they seem to be handled totally differently. I don't claim to have tested this macro stuff very deeply but imo has potencial to make gui scripting life easier, but caution in the few tests I made, transitions using macros, were the most unstable GUI feature, they work the best inputting values directly, specially because those are separated by spaces not commas. Thou using pointers like I show above, even using colors defined using commas worked, sometimes... I think this, spaces versus commas, most be why macros and pointers were mostly ignored by idSoftware, most of their GUI's only use a "safe" subset of the GUI script language and I unless I missed it, I never saw #define being used in any of their gui's. But they do work in the basic tests I made, Gui scripters just need to be aware of the limitations.

Most modern games only use it in cutscene-like scenes, where the players eye is clearly guided towards relevant image content. Doom Eternal uses a very shallow DOF when the Doom Slayer picks up a new weapon and shows it off a little or when performing a glory kill. Elder Scrolls Online uses DOF when talking to NPCs. While the DOF-implementation of ESO is not the best, both examples work really well. In TDM, there are not really many suitable situations where this rendering technique could be deployed, so I don't think it'd be worth the effort.

That brought some memories is a very old test map/thing that I used to learn DR and TDM modding, I spend a few weeks messing with it only. I add almost no idea what I was doing the scale is all wrong for example. Thou If I remember correctly, this test map has at lest 2 or 3 custom models that i made that I don't recall ever being used on any real mission, would be a petty if no one took a look at them to see if they are of any use. Btw those frob-animated boxes, were my first foray into coding and Doom Scripting, also trying to code any ingame interaction with the language, to see if i could do it, so the script code logic most be a absolute mess and perhaps hardly useful but happy you find it cool.

For a while, I've been researching the under-documented GUI scripting language and writing up a new wiki series about it. Fruits of this labor can be seen here: https://wiki.thedarkmod.com/index.php?title=GUI_Scripting_Language As time, interest, and need allows, I hope people will it check parts of it out. It is certainly possible that I didn't get everything right; feedback can be offered here: https://forums.thedarkmod.com/index.php?/topic/21642-feedback-on-wiki-gui-scripting-language-series/ Thanks

Personally I don't like depth of field, in real gameplay at lest, for screenshots and cinematics is fine but if you want to try including it yourself, sikkmod for Doom 3 has a ARB shader for it, so if you learn basic Doom 3 ARB and TDM GLSL shader code, you could translate it to TDM, both engines follow the same basic principles.

Gosh.. Since when did the image upload in the forums stop working... Anyway.. I tried out the new view setup - thanks a lot for all the advices. I positioned a little "attribute bar" to the right. So as soon I select an entity I can see its spawnargs. However what did not matter as it opened as a new window before does come to light now that it is just a small bar: The size of the spawnargs view is really small and there's lots of empty space that could be used for it instead - however I cannot enlarge the attribute / value part of the window - it just stays by a few rows. Maybe I'm doing something wrong - maybe it is a possible new feature in the next update - here is the screenshot: https://ibb.co/PcSmFT2

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

DarkRadiant 3.5.0 is ready for download. What's new: Feature: More customisable layout, all windows and panes can be dragged and arranged Layouts like Embedded, Regular and Splitpane are superseded and have been removed Tweak: The LayerControlPanel's tooltip popup is now less annoying Tweak: Clarify distinction between Shadow render mode and other render modes Fixed: Show/hide Light Volumes for combined entities inconsistent Fixed: Currently applied particleDef not selected in Particle Selector Fixed: Layer visibility checkbox not reacting to double-clicks Fixed: Cannot toggle visibility of layers in Linux Fixed: Drag-and-dropping layers is not working in Linux Feature: Customisable Layout (click to see the videos) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.5.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

1. If you want to use custom work (sound, models, textures) from released missions, best thing is to ask the author if he/she agrees. So far, Sotha is the only one who permits unlimited usage of his custom work (he expressed that here on the forums). He just wants to be credited. 2. If mission authors from released maps are not available anymore, then I do not know what to do. @Dragofer@nbohr1more: Any suggestions? I would say, that's the same situation as described above, just replace "released mission" with "abandoned work". As for my released work, feel free to use whatever you want.

Doom 3's GUI system is pretty basic and not suited for more complex things. It's also a pain to work with. Maybe the mission managment should just not be implemented with it; but with something else (GTK, Qt etc.). Like a launcher, but integrated into the game.

Collision gets generated from the perspective of the AI or player that will navigate it. If you create complex brushwork with tons of triangles, then all that geometry must be evaluated to determine how it might impact physics and navigation. Doom 3 was designed to be mostly indoor corridors so most brushes would be low-poly flat walls. Places in Doom 3 where geometry is more complex tend to be made with Modelling apps like 3DS Max or Lightwave though some complex geometry is in the form of patches or brushes converted to func_static. In those special circumstances, clip brushes like monsterclip, playerclip, or caulk are used to ensure that no 2003 era CPU need to perform 3D physics evaluation of these high-ploy structures. The same holds true in TDM though in 2.11 we do have some new model BVH optimizations that make it less critical to use clip brushes. As I recall, these optimizations only apply to the real-time performance of a mission. Dmap still needs to generate collision surfaces and that is still very difficult. TDM's dmap is far more optimized than Doom 3's but it's still vulnerable to complex structures with lots of connected edges needing to evaluate a huge number of permutations to resolve the final optimized collision structure. If you have a powerful enough CPU, lots of RAM, and possibly a decent chunk of patience for compile times you might be able to dmap a pathologically high-poly mission just by waiting 30 minutes or more. It's not an advised practice though. Map loading still has to parse the compiled collision data and even the optimized result might take too long or eat too much RAM during the loading process for many players ( see how many folks couldn't load "The Painter's Wife" or "Penny Dreadful 3" when they came out. ). We still recommend the use of clip brushes to simplify collision and path-finding just as was done in 2003. A few relevant topics: https://wiki.thedarkmod.com/index.php?title=Pathfinding https://wiki.thedarkmod.com/index.php?title=Performance:_Essential_Must-Knows https://wiki.thedarkmod.com/index.php?title=Systematic_Method_for_Adding_Pathfinding_to_Uneven_Terrain

In a PM, I pointed him to d3 mod "fast item respawn mod", but didnt got reaction. https://www.moddb.com/games/doom-iii/downloads/fast-item-respawn-mod