Search the Community

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

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

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

The votings for the game awards 2020 are starting. So, what's your game of the year? Mine is clearly Doom Eternal. On highest difficulty, this game gives you the same feeling of acomplishment as Dark Souls and the likes. This FPS-game just rocks and rolls, both due to gameplay and soundtrack (obiously I also voted for Doom Eternal in the best soundtrack category)! Regarding the other nominees: Yes, TLOU 2 was an interesting experience, but game of the year? NO! Hades: The game would've been better had it been a true rogue-like. The way it is currently implemented, to much grind is involved, so that it fails to motivate me on the long-term. FF VII: Haven't played it, yet, as I am waiting for the PC release, but I have a feeling it might be a strong Game of the Year contender, too. Ghost of Tsushima and Animal Crossing: Don't understand why these would deserve the spot. Scrolling further down, I see that "Star Wars: Jedi Fallen Order" (technically a 2019 game) is nominated for best action-adventure. That's a definitive yes from me, as I really loved that game, although I think its chances to win are rather slim next to the other nominees.

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.

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

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 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 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.

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

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/

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.

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.

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.

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 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.

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.

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

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

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.