Leaderboard

As I leave my crimbo vacation and return to my work duties I can feel that my time may be severely cut for mapping, so I may as well have you guys take a look at what I've been working on (you know, per the thread title and everything): I really wanna finish this one but RL is a bit volatile atm! Fates be kind!!!

TDM is in El Reg https://www.theregister.com/2020/12/26/linux_game_development_scene/

In another forum where I made it known, Linux users were delighted with TDM, because the offer of games for this OS is not exactly overwhelming, in this field Windows rules and OSS games are usually quite crappy, while TDM really is comparable in quality to many commercial games.

I think we FM mappers need to be less shy in requesting new script API functions (e.g., as New Features in the bugtracker) where existing methods are inadequate, overly convoluted, or non-existent. The case for a new API offering is strengthened to the degree that it's clear it will be generally beneficial across FMs. The bar for this should be particularly low for "...get..." functions. So, in MirceaKitsune's case, I gather something like this is wanted: float gem = sys.GetLightGemValue(); // as just calculated this frame by engine sys.SetLightGemValue(MY_HUD_GUI, gem); // pass it on to my custom HUD The first of these should be easy to justify. The second would take more persuasion.

Please don't take this wrong but to me it seems you are confusing TDM engine with engines like Unity, that are a black box totally separate from the gameplay code and assets and you script your entire game, but idtech 4 is not like that. TDM when it was a mod used the SDK (source development kit) that idSoftware released for us fans, the SDK is the full c++ gameplay code, forget the script language is the real c++ code that linked the gameplay to the engine. Remember when I talked about a .dll? idtech 4 was separated in two components, the main engine .exe and the gameplay code .dll, moders add access to the c++ gameplay code (.dll) but not the main engine c++ code, now TDM has access to everything. (edit: TDM engine doesn't use a dll anymore is all on the main .exe now) Is like Source 2 for example they both have the same design philosophy and roots the quake engine. IMO expecting TDM engine to be like Unity will only bring frustration to you, if you really want to make a full total conversion for TDM you will have to fork the game and work on the c++ code, or work on the c++ and ask the main TDM devs if they can merge your changes. Or like you are doing, just accept the script limitations and try to workaround things.

Relevant part:

AI isn't handled mainly through scripts either. The script mainly handles the way anims are played (allowing to tweak stuff without source code changes). Similar to that it handles some weapon and tool functionalities to allow easy tweaking. Everything more complex is handled by the code. Why do you think so? In Doom3 I suspect scripts were mainly used for setups (scripted sequences where monsters break through walls for example) that would be to nasty and error-prone to be setup via triggers but are not worth the effort to be hard-coded (for example because they are unique). And for stuff that might need continuos tweaking (not only in some basic values that could be handled via spawnargs but in the actual behaviour). The player code contains over 12,000 lines of script, ai is cluttered over several dozens of files of which the main one contains almost 14,000 lines (some of which are comments, though). And those files normally only contain the stuff special to the player/ai. Common code can be found in other files. Do you really want to put all of this into (slow and restricted) scripts?! That wouldn't work. It is actually quiet the opposite. Everything is handled via the source code, and only those things will go through scripts, guis or whatever that are intented to go through them.

In general one should not expect others to implement script functions for them unless those appear extremely useful or some of the coders is really bored (that is rarely the case, as there is still a bit of a lack in that regards). On the other side script funtions are normally quiet rudimental, so implementing them isn't too hard once you understood how the whole setup works. In most cases you can copy what is already there and alter it to fit your needs. Furthermore trying to find a workaround within the limitations of the current systems also has its benefits, as one can learn quiet a lot about scripting and other systems as well as the engine in general. Informations that can only prove useful on the long hand (there is a reason I have turned into a jack of all trades over the years - I am always looking for workarounds ). @MirceaKitsune: Even though there are no script events implemented exactly for your needs, there are workarounds. Reading the lightgem value via the gui is, as stated earlier on, possible. It's not the most direct way but, hey, it works. Modifying the breath is what the breath potion is doing, and yeah, iirc it utilizes the heal function (which is not obscure imho, regenerating health or breath is almost the same, so it makes sense both can be achieved via the same function) Disallowing players to run can be achieved via immobilization (think of player carrying bodies). Crouch would need more investigation, but it may be possible to utilize the animation system for that (if there is no immoblization for that either) Changing the player/ai footsteps volume is probably achievable via modifying the specific sound shaders combined with altering the ai's sensivity to propagated sounds. I thought about that in the past (player is harder to hear in loud environments), but never really implemented it. It appears to me that you are a bit too focused on the script events, expecting that there is one for every single (often very specific task). Try to think more outside of the box. There are guis, materials, shaders,objective system and Stim/Response to your disposal (and maybe something I have forgotten), and all of them can interact with each other.

Following up on HMart, because there is no longer an FM-specific dll to modify in C++, I'm thinking that it is far less likely that FM authors will seek to change the C++ code. So doing increasingly more of the mod stuff via scripting becomes important. It is a challenge to design this in a way that minimizes slowdowns inherent to scripting.

How did TDM code its functionality before idTech 4 became FOSS and went standalone then, with no source code to edit? I thought it did so because all specific game code was purely script based. Not sure how I feel about this. I was hoping only basic functionality was coded in the engine, like the rendering or pathfinding or ragdolls or foot IK and so on: The rest I thought was all scripted... like telling the AI what animations to play, when to become alert, checking when they see an enemy, where to walk to, etc. There is of course code specific to the player or AI, but my belief was it's just common generic stuff (determining movement and visual optimizations and such). IMO this would be the correct way as an engine is usually a general use system... in fact I thought you could still play Doom 3 using the TDM engine binary, obviously not vice versa due to mandatory new features in our engine fork. Then again I'm learning these days that the scripting system is VERY limited, far more than I thought it was. I'm grateful it allowed for my augmentations mod to be coded in the end, but there's a ton of hooks for modifying player / AI / etc that can ideally be added someday to make modding via scripts possible.

Oozing with atmosphere and incredible visual work as always Dragofer. You're a master of your craft!

@Araneidae Did some research, and it turns out support for our 64 bit color precision is actually core since OpenGL 3.0. This is probably a driver bug - I'm afraid you'll have to remember to stick to 32 bits color precision as a workaround. There's nothing for me to detect missing support, unfortunately.