Leaderboard

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

I'm wrapping up a new series, with hub named "GUI Scripting Language" and children (except preexisting) named "GUI Scripting: ..." If you find an error for me to fix or otherwise recommend an improvement, please mention it here. Thanks.

This is something I wanted to try implementing myself more than an year ago, but ultimately figured it's overly advanced engine stuff for me: If no one else wants to I may still attempt it someday, in the meantime I wanted to write and ask about it at least. I don't know if this was previously discussed and I hope I'm not repeating something old: I've been seeing all the amazing changes done recently like volumetric lights... watching how far TDM has come makes me excited to see it get even further and become even more amazing. One of the last remaining renderer features I feel we're missing is the Depth Of Field effect. I do believe having this would make every environment in each FM even more incredible and realistic, while bringing TDM even closer to having top notch visuals on par with most modern engines (if we exclude PBR materials). Existing shaders and tutorials for the GLSL implementation are out there possibly even an existing idTech4 port; Initially I hoped it might be as easy as grabbing a freely licensed shader and integrating it in the engine, but usually things are always harder in reality. For starters I'm curious if others are with me in wanting this, if there are any plans for adding the feature, and if there remain any major roadblocks in the engine preventing it... engine wise I know the shader just needs access to the Z-buffer and can typically work its magic from the depth map. The best implementation I'm hoping we can get is the dynamic one, which smoothly adjusts focus based on where the player is looking (distance of the center pixel in the middle of the screen). By default the effect definitely shouldn't be excessive, only blurring distant or near things very slightly unless you're looking at a surface right in front of you. I don't believe it needs to be enabled by default as long as it's in the menu, like the sharpness filter it shouldn't bother anyone who doesn't want it and make things look beautiful for those that do.

Hello taffers, I'm currently attempting to ghost (supreme ghost if possible) the aforementioned mission on expert + hardcore settings, and upon trying to loot the spider lair in the sewers, it started to behave rather strangely, as though it was attracted to my general position no matter what: altitude lightgem level alert level. Also, could be a bug with the unofficial patch by @wesp5: rarely when it detects me, the stealth stats won't update when the spider attacks, it will settle to roaming immediately after I'm hidden or on high ground, this didn't happen on my vanilla installation. Since the unofficial patch "balances" some game mechanics, the root cause could be related. On vanilla TDM this is not an issue, or not that I had encountered on my previous normal and ghosting runs of this mission. If this is a core game bug and not something related to the mod, and can be reproduced consistently on vanilla TDM, I can create a bug report if needed. [edited] Thank you.

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.

I think there's no other choice anyway since I recently also searched for that and didn't find a particle that fits.

Just an idea: Make a subcategory of category Editing called GUI and put everything GUI related under it, so it's easier to find. ( Curently there is no letter G in the list of subcategories: https://wiki.thedarkmod.com/index.php?title=Category:Editing )

Does this happen both in Stencil Shadows ( r_shadows 1 ) and Shadow Maps ( r_shadows 2 ) modes? Does this happen in the latest Dev Build version? ( Note: If you are on AMD and want to test the latest Dev Build, I suggest you set r_softShadowsMipmaps 0 )

Maybe this issue is related? https://bugs.thedarkmod.com/view.php?id=5888

My Unofficial Patch doesn't change the spiders at all, so it must be something different. Maybe they are supposed to smell you or use other animal senses and this is a hidden feature?

Maybe those spiders need an ai- and hitbox-fix --> techsupport (??)

You can open up the particle editor, duplicate an existing one and then edit it. It is a bit of fiddling around to try to achieve what you're looking for. You may also need to create a custom sparkle tecture if you don't find a sprite that's already fitting.

I don't see how DoF can possibly work in a game which isn't tracking your eyes. How does the game know what you are looking at? Your eyes could be focussed anywhere on screen, which might show objects at a variety of distances. If the depth is taken from the central aim point, that means that instead of just moving your eyes to look at something on screen, you'd also need to move the mouse to remove the artificial blur. DoF looks nice in photos, and as stgatilov says it might work in a VR simulation with eye tracking, but for a 2D image on a standard screen I can't see it adding any value.

Grab Jazz Jackrabbit 2 before Nov 3, 9 AM EDT. https://www.gog.com/giveaway/claim https://www.gog.com/en/game/jazz_jackrabbit_2_collection Pretty nostalgic because I remember watching the trailer for this game... over 20 years ago, included on a disc for Railroad Tycoon II. It's also an early game from the company now known as Epic Games... shouldn't they be the ones giving it away for free?

The ultimate goal of on-screen computer graphics is photorealistic rendering, in which case modelling the camera lens is the only option that makes sense. If you want to aim for eye-realistic rendering, it belongs to VR mod: there you can use eye tracking to detect focus distance for the eyes. Overall, I personally don't like the idea of Depth of Field effect in TDM, and I suppose most of people won't. But yeah, you can probably use g_testPostProcess cvar to add a full-screen effect, using _currentRender and _currentDepth as input texture, and writing custom shader.

This is an irrelevant aside but... That wiki article had one of the most enlightening things I've been wanting to know about for a long time in it an almost throwaway little aside in the 2nd paragraph of https://en.wikipedia.org/wiki/Euler_angle s#properties ... which after a little following up through some of the linked wiki pages is (I think; it's nuanced math, so I'm never entirely sure) that the quantum spin of a particle is a feature of a 3D rotations in a 4D rotation space, which (again if I understand it) is very close to our Euclidian intuitions that contiguous bodies rotate together (in S^3 space), except the rotation space it actually fills up (RP^3) has these isolated 0D points that also "have rotation". I'd been trying to figure out since forever what quantum spin really was because it's crazy at face value. But seeing it as just a natural & necessary property of rotation symmetry, which is all a particle is (Poincare symmetries), somehow makes me feel better about it. It isn't so unintuitive and arbitrary seeming now. I mean imagining how space really works is still odd, but it fits the math of everything else happening in a particle like a champ, and word on the street is that spatial relations are a property of symmetry relations & not the other way around anyway. It's just funny that I'd find it in a thread following up on a game coding question of all things, after trying to understand it through so many other routes after countless direct searches and reading tutorials. Okay, sorry for the aside. I felt moved to say something to someone about it.

Difficulty is an interesting one to tackle, like most things it is highly subjective. I have had people complain that a mission is both too easy and others say it's too hard before, much like some people will enjoy a mission and some wont. It all comes down to tastes and playstyles. The route I like to take is somewhere down the middle with a little more leaning on the easier side. I would rather people have an enjoyable time in a mission than not. However I do offer up more difficult tasks within levels. So for example @Obsttorte the meat factory you mentioned is an expert contract. So for those I don't offer as much hand holding and expect the player to figure out their own way forward. If this was a main objective you would have things more directly telling you what to do and where to go, there would be less AI down there and it would be better lit. But because it's not a main objective, it's an expert contract, I wanted to provide more of a challenge to folks. Perhaps I could convey that some areas are tougher by having an onscreen text read "You are in an expert area" but I feel that takes away from the immersion of the level so I just leave things as is. In regards to there being an unnecessary amount of gear, that's another point I don't agree on. As TDM is an immersive sim, I feel it's important to give the player as many options as possible. So say while you may not find any of that gear necessary another playstyle might. Do you want to go in with just a black jack, go ahead, or if you want to go in heavy then you can stock up on mines and fire arrows and wreck havoc, or maybe a flash bomb. Perhaps the roof is better, so a rope arrow will make that easier, etc. You did mention the issue of spending 15 minutes in the manor but 45 minutes outside. That's because the mission was originally only the manor, it felt too short so I decided to expand the things to do in the mission by building the city around it. I can see the argument that the logical pathway is to improve the main objective aka the manor, however I wanted to make things more interesting and give folks more side content through the contracts. That way if you want a quick and easy mission you can just break into the manor and get out and that's maybe a short 20 minute mission. But if you want to go the completionist route then it's going to add a lot more content. That's why in games the main storyline takes 15-20 hours to complete but a completionist will take 100 hours to complete. Again it's all about giving the player more choice. Re: the performance. Well you got me there, dead to rights. I wanted it to look pretty and fancy with loads of custom textures and sounds. I tried as hard as I could to optimize the area, but there definitely is some sluggish performance in certain areas.