Search the Community

Been scouring the net for an active community for doom3 and this was the most active outside of github source codes... so I figured it might be worth a shot. Looking to see if there is anyone who can give me a hand fixing up the thirdperson cross hair for Doom 3 Ruiner. There are 2 bugs in it. I'm hoping to get a fix included for the upcoming, and long overdue, patch for the mod. This is probably the biggest bug in the mod. The first bug is from the trace line made to determine the cross hair's position. When playing the mod, type g_debugweapon 1 in the console to show the line used to determine the position and also for the melee combat related additions. When something gets in the way of the line, the cross hair won't update. This is easily duplicated by standing next to a wall or door way and just shooting. I have a hunch the issue is mainly caused by the shoulder camera offsetting the camera. Maybe being able to offset the origin of the line to the right would help? The other bug deals with launching projectiles from the barrel. When set to 1, the cross hair is always off. to counter act it an offset can be set in the cursor.gui It works alright, but will still be off when looking too high or low because of the weapons barrel position. The only thing I can think of is maybe a flag in the projectiles fired to aim towards it... which could look wierd unless the crosshair position is offset right in the cursor.gui. Any help would be really appreciated! We uploaded the source code for the mods years ago on the mod db. https://www.moddb.com/mods/ruiner/downloads/ruiner-hardqore-2-source-codes The crosshair is handled in the player cursor.cpp

There is a whole mess of graphics mods for Doom 3 you could peek at. Sikkmod for example is not based off BFG and has a depth of field effect when reloading weapons which sounds like basically what you are looking for and I doubt it requires engine level changes to work: At a minimum you could download one of these mods and given doom3 stuff is typically all text formats in .pk4s there might be enough there you can just read to figure out how it works. As far as it’s potential inclusion in the game I have no real opinion - though given it would likely be optional I don’t see it hurting anything either.

What function are you using to render the subtitle text? Is it idRenderSystemLocal::DrawSmallStringExt() ? The comment above it says it does drop shadow but I didn't analyzed the code at all to know if true. That 480p virtual background rendering, does sounds like a problem, too text at lest, specially when you guys are still using the text textures at max 48 size, like Doom 3. The engine is essentially using the same "basic" text system from quake 2 or even quake, texture atlas, and it makes for blurry text when scaled, specially from 480p. Btw no pressure here just a suggestion, if you haven't looked at the OverDose source code imo you should, they claim is a very advanced quake 2 engine but internally, looking at it, is almost identical to idTech 4 but with a more advanced modern GL render just like TDM engine . I'm talking about that engine, particularly because they upped the text atlas scale to max 96 and you could look how they did it, that should help a little with the blurry text. And IMO, not affect performance that much, specially today when thanks to your fantastic job TDM engine is so fast. Also they even have a nice tool to create fonts for their engine (and other tools and documentation, some of it imo still relevant for Doom 3 editing and perhaps even TDM). And lastly I know is probably not possible and would be a bunch of work for you and I bet you are already busy with other more pressing things but some day, something similar to this would be awesome, if a open source equivalent exists...

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

I completely love Doom 3, it was my first introduction to the Doom franchise, so sad that idSoftware decided to go back to its, Serious Sam like roots. Just to put things in perspective, I finished Doom 3, 10 times or more, start to finish, while Doom 2016, I never finished one single time, found it to be repetitive and boring, never bought Doom Eternal because of it. Doom 3 to me was like a movie experience, a somewhat serious, more mature game, for example the Doom 3 marine, was a normal man, put into a unusual situation that pushed him to its limits, modern doom is like a arcade kiddies game, where you are a literal super hero that everyone should fear and the player ego goes through the roof because "YOU ARE THE SLAYER!!!", some may like this but personally I don't.

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?

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

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 the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

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

I just found this thread on ttlg listing Immersive Sims: https://www.ttlg.com/forums/showthread.php?t=151176

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

Great mod, loads of fun. It modernizes Doom, but in a good way. Two things I would like to request. 1. sounds for waterfalls/liquid falls. It is nice that there are sounds for torches now, but it seems a bit strange when near a waterfall and there is no sound. Surely surfaces with flowing textures could be tagged to play a rushing sound. 2. Cyberdemon should be a bit tougher, at least against the BFG. He's supposed to be a bad-ass and instill fear in the player, so it feels kind of too easy to paste him with 2-3 BFG blasts. Thanks

Recently revisiting the forums after a longer period of time I wanted to check the unread content. I don't know if I am doing this wrong since.. ever... but on mobile (visiting the unread content page on my smartphone) you have to click on that tiny speech bubble to go to the most recent post in a thread. If you don't click correctly you'll hit the headline and end up at post 1 in the beginning of the thread. It's terrible on mobile, since not only the speech bubble is really small and was to miss. But also the thread headline is just millimeters away from it so you go right to the first post that was ever made instead of the most recent ones. Am I doing it wrong? I just want to go through u read content a d the to the newest post from that topic.

It's interesting because I recently read a thread on the Doomworld forums on people's opinions of single-segmenting maps in classic Doom/Doom 2. In other words, playing a map from start to finish without using saves - if you die, you have to replay the entire map. The general consensus was that saves are useful, however there was some merit in there being extra tension and challenge knowing that death couldn't be rewound easily by reloading a save. On the other hand (and speaking as an adult), people have to work and often have limited time for gaming. Having to replay a long map because you died can be quite off-putting and takes the joy out of a game if it happens often enough. Savegames keep the tempo going, keeps the feeling of progress going. Also someone pointed out that starting a map from scratch after a death is kinda like using saves anyway, just a single save at the beginning. You're just being tedious by denying the use of saves in this case. Dunno where I'm going with this. Trying to be diplomatic and say I can see all sides to the discussion.

A@datiswous Ah yeah, well sorry, I was quiet busy and only visiting discord. First time here on the forums since months now I think.. Thank you for the subtitles. I encourage everyone who is interested in using them to download it from here as I'm not sure when I'll be able to implement them myself into the mission. Again, thank you for your work.

DarkRadiant 3.0.0 is ready for download. It took a while, but DarkRadiant 3.0.0 is finally available. Most of the time has been spent on improving DarkRadiant's renderer, which now features shadow mapping support of up to 6 lights. It's still not matching the engine's output (especially in terms of performance), but it should be faster and much more helpful than it was before. The effort that has been put into the renderer rewrite plus the bigger changes in the previous few releases make the jump to the next major version feel more than justified. Besides of that, a lot of non-renderer issues have been resolved in this release too, next to some fine usability improvements. For more things that have changed or fixed, see the list below. Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.0.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! And I'll gladly repeat myself, by thanking 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. Changes since 2.14.0 Feature: Realtime shadow mode Feature: Allow way to hide some entities in Create Entity list Feature: MD5 Animation Viewer: show current frame & total frames Feature: MD5 Animation Viewer: jump to frame Feature: DarkRadiant warns about missing .darkradiant file on load Feature: Ability to center 3D camera on selected entity Feature: Cut functionality to complement copy and paste Feature: Save user settings by application version Fixed: Free Rotation not working anymore, can only rotate along 3 axes Fixed: DR crash with combination of mouse buttons pressed Fixed: Git Sync Exception: too many redirects or authentication replays Fixed: Missing brushes when opening alphalabs1 from vanilla Doom 3 PK4s Fixed: Selected Skin not showing in ModelSelector Fixed: Reload Defs takes longer every time Fixed: ForceShadows materials are not casting shadows Fixed: Objective GUI doesn't display properly in some places Fixed: Crash on loading certain maps Fixed: Vertex colours do not show on models in lighting mode Fixed: Entity inspector shows inherited spawnargs of previous selection Fixed: DR overwrite order for defs is different from TDM's Fixed: X/Y and Camera View bindings don't save properly Fixed: Material Preview rendering Fixed: "Replace Selection with exported Model" sets classname to "func_static". Fixed: Map -> Edit Package Info (darkmod.txt)... crashes DarkRadiant Fixed: Rotating a func_static result to random stretch textures Fixed: DR crashes when syncing with remote Git repository Fixed: Switching visibility of Github repo from public to private causes crash Fixed: Dockable window layout doesn't save new floating XY views Fixed: "Choose skin..." button on custom model spawnargs shows skins for main model spawnarg Fixed: Entity inspector considers inherited colors black Fixed: ReloadDefs moves def_attached light crystals to entity origin Fixed: Option to filter skins out of search results in the Choose Model dialogue Fixed: .lin files can't be opened if different case than .map name Fixed: Model chooser radio box selection issue Fixed: Changing multiple lights between omni/projected resets colours to black Improvement: Allow absolute paths for snapshots Improvement: Light diamonds and Speaker radii are transparent Improvement: Unify Declaration Parsers Improvement: Add "Create Particle" to right-click orthoview drop-down menu Improvement: Revisit Interaction Shader to get closer to the TDM looks Improvement: Entity inspector should recognise spawnargs beginning with "sprS_" as def spawnargs Improvement: UI for worldspawn-to-entity conversion Improvement: classname field should always be read-only, to force use of the "Choose entity class" button Coding: Update solution and build dependencies to Visual Studio 2022 The list of changes can be found on the our bugtracker changelog. Have fun mapping!

Dusk has the Doom gameplay of course, but it's so poor in a good number of design aspects and choices to be a "Doom/Quake killer". That's what I'm talking, Cultic is just perfect about the *design*, it's Blood on steroids. If you want the perfect Quake experience just try Arcane Dimensions And for Doom just try CountryCide: https://www.moddb.com/mods/trench-foot-wip/downloads/countrycide

I know this forum is for The Dark Mod but this seems to be the only place with an active technical side to Id Tech 4 so I'm kinda not sure where else to look. So I've been trying to compile the Doom 3 source code to make some edits to some game mechanics in Resurrection of Evil. Thing is though I keep running into issues with errors in Visual Studio and I'm not exactly sure on how to solve them. I've been following this guide in order to compile the Doom 3 source code but I get issues with DoomDLL, MayaImport, and Game-D3XP. https://www.katsbits.com/smforum/index.php?topic=896.0 MayaImport doesn't matter as the issue for it seems to be that I don't have Maya to begin with and I'm assuming isn't needed for me to compile anyways. DoomDLL fails however with errors about Win_input.cpp with errors about things being in a constat and identifiers. Game-D3XP fails due to a problem with the script_compiler.cpp with it complaining about constant char as well. I can get Game-D3XP to compile if I replace the script_compiler.cpp with the one from Game and it seems to work fine. While I managed to compile a DLL for Doom 3 and ROE they were much larger than the vanilla DLLs that come with the game. I know some things changed like something different about the shadows to avoid a problem with a patent but are they supposed to be almost twice as large? I removed the default DLLs from the game files and used my own which seemed to run fine which gets me on to the point. The goal of this is essential to make some engine changes to allow the player to get ammo_souls like they did in Doom 3. I tried adding the Soul Cube and changing the Artifact to use ammo_souls so that it would be usable in custom maps that don't have the Artifact charge pickups. Killing enemies won't get you souls in ROE even if you have the Soul Cube in your inventory it seems and I've found this in the code. /* ============= idPlayer::AddAIKill ============= */ void idPlayer::AddAIKill( void ) { #ifndef _D3XP int max_souls; int ammo_souls; if ( ( weapon_soulcube < 0 ) || ( inventory.weapons & ( 1 << weapon_soulcube ) ) == 0 ) { return; } assert( hud ); ammo_souls = idWeapon::GetAmmoNumForName( "ammo_souls" ); max_souls = inventory.MaxAmmoForAmmoClass( this, "ammo_souls" ); if ( inventory.ammo[ ammo_souls ] < max_souls ) { inventory.ammo[ ammo_souls ]++; if ( inventory.ammo[ ammo_souls ] >= max_souls ) { hud->HandleNamedEvent( "soulCubeReady" ); StartSound( "snd_soulcube_ready", SND_CHANNEL_ANY, 0, false, NULL ); } } #endif } From what I've been told the #ifndef _D3XP skips the code if D3XP is defined somewhere but I'm not a code expert and this is just my guess from reading what the statement might mean online. The other problem after this is that I want to use Sikkmod on top of these changes with my Doom 3 mod list. While Sikkpin released the source to his mod I'm not 100% on how to use it. I assuming you just plant it on top of the vanilla Doom 3 source code and compile it that way but doing that gives me issues with player.obj and calling external objects. Error 1015 error LNK2019: unresolved external symbol "public: __thiscall idGrabEntity::idGrabEntity(void)" (??0idGrabEntity@@QAE@XZ) referenced in function "public: __thiscall idPlayer::idPlayer(void)" (??0idPlayer@@QAE@XZ) C:\Users\The_OId_AI\Downloads\doom3.gpl-master - Copy\neo\Player.obj Really, all I want help with is compiling it all properly so that I can look into what I need for the Soul Cube and the Artifact. TL;DR1. Is the guide I'm following correct? Are there any extra steps I need to take that the guide may not have mentioned due to maybe the author thinking it was obvious?https://www.katsbits.com/smforum/index.php?topic=896.0 2. Is the compiled DLL supposed to be about twice as large as the vanilla counterpart? If not what exactly should I do to make sure it is? 3. How can I resolve the issues I am having with Sikkmod 1.1 ROE edition source? What steps do I need to take in order to compile it. 4. Is it a bad idea to do what I am doing with script_compiler and D3XP? Is there something I should look into for a proper solution? More info here but I think I covered everything here. http://idtechforums.fuzzylogicinc.com/index.php?topic=532.msg5830;topicseen#msg5830 If there is anything I'm missing that you need ask and I'll see if I can give you an answer. https://www.katsbits.com/smforum/index.php?topic=896.0