HMart
-
Posts
1545 -
Joined
-
Last visited
-
Days Won
9
Posts posted by HMart
-
-
1 hour ago, Dragofer said:
This is true, but the fact is that the viewmodel only consists of a bare arm (animated model), with something bound to it (static model). The depth hack only applies to the arm model itself.
If you want to stop the lantern clipping through walls you have to make a new version of the animated arm model that has the lantern integrated into it.
Yeh that is also how Doom 3 weapons were done, but perhaps this can be worked around? Next to weaponDepthHack there's also a modelDepthhack bool I assume for every other model, perhaps that just needs to be put in the model def file or enabled by a spawn argument? I really don't know, or if that spawnarg even exists, if not then is something to put in the roadmap.
-
Quote
The lamp clips through walls when up close (no idea how to fix this)
Is the lamp a weapon? Unless TDM weapon system is different from Doom 3, weapon models should have the "depth hack" thing enabled, that "hack" (that is how idSoftware calls it
) makes sure the weapon never intersects with geometry.
in the code:
bool weaponDepthHack; // squash depth range so view weapons don't poke into wallsDon't know if there's a way to enable that without messing with c++, stgatilov or others may know.
-
2
-
-
7 hours ago, kin said:
I asked someone that has no idea about dark mod to play for 10 min and describe player foot steps. She said that it sounds more like you are trying to actively make noise walking or running (very clappy) rather trying to be silent. Definately we would benefit with some kind of adjustment.
Perhaps but the game, has gameplay features that can muffle your footsteps sounds, carpet and other ground textures, the vine arrows also, so by making them more silent/quiet, imo you may end removing the incentive, for mission makers and players to make use of those.
To me, If a player thinks the footsteps are to loud then maybe the mission maker, didn't put enough ways for the player to walk more silently in the level and so he always hears loud footsteps and thinks that is bad/broken.
Btw what about incentivizing mission makers to do certain things, by the older more experienced mission makers, agreeing on a small list of "best practices for mission makers" for performance, looks and gameplay and pin that at the top of the forum? Then any new developer may learn something from that and avoid some rookie mistakes, like for example, not putting enough ways in a level for a player to walk more quietly.
Just my two cents.
-
Quote
Do you know why sndshd files cannot raise the volume of sounds?
This most be a TDM only thing, because I tried it right now and I can use volume keyword, in a sound shader, in Dewm 3 engine, to both increase and decrease sound volume.
Or unless is particular to the player footsteps, I didn't tested those, will see and update this comment.
Worked with the player footsteps sounds as well but I remember messing around with the c++ code to make those work. I used Blendo Games starter pack and the player system that comes with it, has the footstep system disabled, this because the starter pack has no real player model, just a floating camera.
SpoilerThe footsteps from original Doom 3, were based on the player animation, if I'm not mistaken they are called from within the player animation def file, at the frames where the character model puts his right or left foot on the ground, so that may make the handling of the sounds different from normal.
Ps- btw I add to call reloadDecls in the console NOT reloadSounds for the volume keyword to work.
-
2
-
-
6 hours ago, JackFarmer said:
From my status update feed a few weeks ago:
Dear ChatGPT, What are The Builders in the Dark Mod?
The Builders is a popular game mode in the video game community called "Dark Mod," which is a fan-made tribute to the classic "Thief" series of stealth games. In this game mode, players assume the role of builders who construct structures in a dark and ominous environment while trying to avoid detection by patrolling guards.
The Builders game mode is unique in that it offers players the opportunity to create and design their own levels using the in-game tools and resources provided. Players can experiment with different building materials, construct intricate traps and puzzles, and create their own unique gameplay experiences.
While The Builders game mode is not an official part of the Dark Mod, it has become one of the most popular and well-loved aspects of the game, thanks to its emphasis on creativity, strategy, and stealth.
QuoteI don't think it's entirely off-base that there's a link between the game being conceived and made largely by map editors and the main antagonists being Builders preaching about good design as a religious sacrament all the time.
demagogue to me its doesn't matter that its "somewhat right" what it wrote there, is mostly BS, is not true.
QuoteThe Builders is a popular game mode in the video game community called "Dark Mod,"
Not such game mode on this game... nor this game community is called "Dark Mod", that is the name of the game. I bet the AI said that, because many indeed refere to this community online has "The Dark Mod" community but the AI totally failed to get the real meaning/context of those words.
QuoteThe Builders game mode is unique in that it offers players the opportunity to create and design their own levels using the in-game tools and resources provided
Again there's no such game mode, nor players make levels using ingame tools and resources. That is obviously marketing from some online MMORPG game or such.
Quoteplayers assume the role of builders who construct structures in a dark and ominous environment while trying to avoid detection by patrolling guards
Again to me it doesn't matter that the intention is almost there, you and me know that because we know the game and its community, but if we were new players, the truth is, that description would give us a totally wrong idea about this game.
Because players don't assume the role of builders, builders are a ingame enemy faction, players don't build anything, they play the missions and the roles of thief's or assassins', mission makers (no matter if they are themselves players) are the ones that build missions, the only thing right in that quote is " trying to avoid detection by patrolling guards".
What that original quote show to me, is that the AI can write coherent frases but still be totally wrong, is just a clever mashup of cool marketing words, from other games i bet, being reused in a new context, mixed with a few correct bits/words from Dark Mod.
-
5 hours ago, revelator said:
Soma for instance uses a rather odd physics engine
Soma uses Newton Dynamics (Newton 2.x or 3.x? )I know that physics engine, is very accurate, is also why it is slower than Havok and PhysX for games, unlike the others it takes very few shortcuts in its physics calculations (there the name), that made it's joints and friction handling very stable and perfect for the type of player world interaction that Frictional Games wanted for Penumbra, the fact the physics engine was so stable and rather unknown, is IMO one of the main reasons their first game was so unique and successful.
Btw Newton Dynamics started as a physics engine for robotics and stuff in academia, so it needed to be accurate, the main developer of the engine, is now making a modern version more focused at games, Newton 4.x and it is way faster than the former versions, but I assume that with that speed comes less calculation stability but I don't really know.
-
John Carmack the main idTech 4 developer once said, "best way to mesure performance is not FPS numbers but frame timing" and I agree, we tend to mesure game performance by counting higher and higher fps's but you can have a very responsive and playable game at 30fps, if the frame timing is constant and a very lagging game if not, even if the fps numbers are 60 or higher.
And today in the age of Nvidia DLSS 3 AI frame generation, FPS numbers, are imo becoming irrelevant, hardware unboxed found that with DLSS 3 you can have a game, for example show 120fps but feel almost exactly like a 60fps game (because is the speed the game is really running at, DLSS 3 is just inserting fake frames between each real one and artificially upping the frame rate).
-
Perhaps you have a infinite loop in one of your scrips? Infinite loops can cause freezes. But I also thought the script parser was able to caught those?
Btw I don't remember ever having, Doom 3 in this case, freeze because of changing a def file (or even a script?), the worse it could happen is crash the game or cause ingame bugs but I'm not absolutely sure on this.
-
15 hours ago, AluminumHaste said:
There's no need for accelerated physics cards. Look at warframe, they were using physX for the particles and stuff if you turned it all the way up, but instead switched to generic GPU physics. Not only does this allow it to run on any GPU that supports it, it also runs better than it did before.
I don't think we need a extra PPU card not today, I'm just saying that Ageia failed, not because their competitors could do the exact same or better, without a accelerator but because they just couldn't show, or didn't knew how, the true promise of the PPU to the public, in visual terms, not in a way that non tech savy people could see it.
And when some of its effects, could be made "good enough" with less physics complexity, and or faked like for example Valve did in HL2 with the baked "cinematic" physics, it add no chance.
SpoilerBtw the PPU was more than a simple particle physics accelerator, it was capable of being a full substitute for the CPU for physics, (like a sound card was for sound back on its day), it could also do gameplay interactive, meaning objects that affected the player and AI directly, like collision detection and rigid body physics that effected the AI navigation, not only extra visual stuff like soft body physics, cloth and hydrodynamics using a kind off simplified PIC/FLIP method, unfortunately this was what Ageia bet on the most, because was more visually cool for players, totally falling into the, GPU can do, realm and defeating their own hardware.
Nvidia GPU's can do most of it but gameplay affecting rigid body stuff, is still CPU side, Nvidia PhysX is 100% visual flair (like 90% of the Ageia stuff was to be fair).
Quoteoh boy can o worms...
hahah Indeed
Quote... i agree at the time the graww demo was impressive, my point being that over time the competition will find ways to overcome the shortcommings of having to use dedicated hardware in this case it turned out that upcomming CPU's were more than adequate for the same task.
Not trying to start a debate over this stuff but CPU's even modern ones, IMO aren't still capable of what even the old PPU could do, at lest I haven't seen a game with CPU only physics doing that, you are free to show me wrong thou.
Quoteit is actually a little misleading calling it software based when you take this into account
Agree Is like saying software rendering, everything done on the CPU is said as being done in "software" but at the end of the day, is a peace of hardware doing the calculations.
Quoteand havoc did a pretty good job considering this was quite some time ago.
We agree we disagree on this?
Plus Havok is as dead as Ageia PPU today, Nvidia PhysX pretty much dominates the physics engine market.
QuoteThe physx code is opensourced now so a developer could actually make a bridge between say OpenCL and physx and have AMD cards with hardware accellerated physx but i have yet to see any attempts at that.
I certainly can't argue with that, totally agree. Btw Bullet physics engine made by a old Physx engineer (if I'm not mistaken) did support OpenCL acceleration on AMD and the company did showcased it but like almost AMD stuff, it didn't add any use, in gaming at lest.
Btw guys sorry for the huge replies but is hard to say everything I wanted to say about this subject in a few words.
-
1
-
-
Havok never did such a thing, I know because I was a owner of a Ageia card and Havok demos or games, were never able to reach the same level of physics Ageia PhysX demos displayed. I know Ageia is now a joke and people have forgotten most of it but I experienced it first hand and let me tell you, to this day, there's not a single, Havok or Nvidia PhysX, game or demo, that to me, does what some of the old Ageia demos did, at lest not all of it, again I saw it with my own eyes and played them on my PC.
Warning massive wall of text:
SpoilerThere were 3 demos that to me, showcased how impressive the PPU accelerated physics really were even back then. Unfortunately most videos I will show are old and low rez for today.
One was the Ageia Island for the game GRAW 2, looking at the video really doesn't paint the full picture, you add to experience it, one thing people loved to do was compare Crysis 1 trees, to this Ageia Demo, saying "they are the same!" all because you could shoot and cut trees in Crysis also, but there was a very obvious diference for those playing the demo with a PPU, the underlying physics running behind the curtain, were way more complex in that GRAW 2 demo, I could compare both games side by side and yes the Crysis Trees were impressive but the physics were way simpler, the trees in Ageia Island add smoother cloth physics for each individual leaf, Crysis add a simple ragdool system like the mattress in HL2, I still remember well today, when you cut a Ageia demo tree, it falls down with a real sense of weight to it, it strike the ground, crush's the cloth based lefts and has a spring effect to it, like a real tree would, in other words the Ageia trees trunks were soft and malleable, when the wind changed direction and or became stronger, they were shot or stroke by the blast of a big explosions near them they bended like soft body physics. In the other hand the Crysis trees, when cut sometimes never reach the floor because the leaf's stop it mid air, they fall with the sense of weight, of cardboard and the tree trunks are rigid. I can't really explain in words, you add to experience it to see it.
But in the end people didn't cared if the Ageia physics were more complex behind the curtain, visually most didn't saw the diference, most also didn't understood physics engines, they only cared if they were extremely revolutionary visually and out of this world and Ageia demos were not, not to the eyes of the average consumer, not enough for most people to spend the money of a GPU, on a new totally unproven Ageia PPU. I add money to spare back then and I knew more then most about physics and always wanted to try new stuff, so I bought it, but we were very few to keep the company alive.
Another demo was Cell Factor , not all effects in the game are showcased there for some reason, lacks the impressive destructible cloth and liquid effects, could be a video of a earlier version of the demo.
The last "demo" was the multiplayer game warmonger this one also add impressive PhysX effects, full destructible cloth and buildings, but because was trying to be a real game, not only a Ageia demo the dev's tried to keep the physic stuff to the bare minimum to please Agaia, in the end it failed has a game and as a PhysX showcase. Specially when a very popular AAA game, also add destructible buildings, Battlefield, even thou was not the same thing, Battlefield used clever tricks, like particle effects and baked physics, it was visually impressive enough, to totally kill the wow effect of this Ageia sponsored game.
In the end Ageia lost because even thou the physics engine was good, it was just not able to show it in a way to push people to buy a extra expensive peace of hardware. Nvidia bought it, killed the PPU, claimed to slap it in each Nvidia GPU, that to this day, I don't believe is true, why ? Because I have not seen a single Nvidia PhysX game able to do everything that this three Ageia demos did, all those years ago, on a way less complex and slower PPU.
edit: Revelator I see that you were also a owner of a Ageia PPU, that makes your comment even more strange to me, what Havok demo/game did you played that made you get that impression?
-
IMO there's some benefits to using "" around paths, one it permits you to put spaces in your paths (thou I don't recommend that at all), second it breaks your paths into easier strings, for the text parser to read/deal with, it also help us visually distinguish what's is what better.
They aren't a rule you can ignore them but imo using them maybe decreases the probably of parsing errors.
About lower case, I'm not sure but unless you are comparing strings, I don't think the parser itself cares about the case of character in a string. Thou because of portability to linux and other OS's idSoftware recommended, no spaces in folder names and no higher case letters in a path, the engine even has a warning message just for that. But like you see above, even I forget that sometimes, is why I have plenty of warnings about non portable paths in the console!
-
Instead of that try this to see if it works, it does on my end
skins/bathroom/Tube01a_waterclean { model "models/mapobjects/washroom/bathtub_oldA.lwo" "textures/common/nodraw" "textures/water_source/Water_clear" }change the stuff for your own model/materials of course
-
On 3/22/2023 at 12:43 AM, MirceaKitsune said:
Thanks, that is good to know. Only issue I noticed with deforming glass is any other glass material seen through it will be invisible which can look ugly. Performance wise it's still good, volumetric lights remain the biggest hit so far though that's also manageable. I have a pretty crazy visportal setup which can look scary due to the quantity used but is actually working quite well.
Those pics look very good.
About glass behind glass, that is a problem in all game engines, using rasterization, no matter how modern they are, is a limitation of rasterization itself, is not impossible thou, there's a trick to make it work called "Order-independent transparency" but afaik is complex and demanding and apart from a very old AMD (or was it Nvidia?) demo, I never saw any game use that trick, specially not now that real time raytracing is a thing.
Thou on the link I posted it says the ancient Dreamcast console add special hardware for OIT.
-
Hum I think I see the problem. Btw If you haven't, I recommend that you read the gui documentation in TDM wiki, may give you better advice than me.
I think the problem is that grayman "gui::startSelect" is handled by the engine c++ code, thought another gui file (if any), this is because gui:: vars aren't global to all guis, they are "baked" in the gui they are defined, meaning you can't just reuse them in any other gui file as is.
SpoilerGui vars are just placeholder names for a value in a gui and need to be handled by c++ code and that code, calls into the gui file directly, for example, if you put a gui::whatever inside the player hud gui file, then in c++ you call
hud->setStateWhatever("whatever", something);
so if there's no c++ code, calling that gui file in particular and handling/reading that gui var, putting it in that gui, will not do anything.
Search the various mainmenu gui files and see where that var was originally defined, that particular c++ code in ModMenu.cpp has a comment saying, it handles main menu cmds so it most be something linked to the main menu.
In the end, if you want to make that work, you need a way to read your version of gui::startSelect value somehow, you set it's value in OnAction but you aren't doing anything with it, right now the engine c++ code, doesn't know it even exists, because your gui:: var even thou has the same name has grayman's one, is not the same.
This is a problem for those not editing the c++ code, original Doom 3 engine, only lets you read from and write to gui:: vars from c++, you can write to them using scripting but the gui needs to be assigned to a entity (so no fullscreen guis) and you can't read back the value.
But TDM may have changed this and have new ways to handle gui vars that I don't know, so the best bet is to read the TDM wiki on the subject like I suggested.
If TDM wiki has nothing to help you, then I recommend you do a feature request for the next TDM version in the bugtracker.
-
1
-
-
That's exactly what the code you posted does, it selects only a single spawn entity, a custom one if you give it or the default one.
Looking at the code you posted, grayman changed the code in a way to permit anyone to override the default spawn entity, for a custom one, by setting a gui var called "gui::startSelect" to the name of the entity you want to use as spawnpoint, but is still a single one and that's logical, because there's no way to spawn the player in more than one spot at the same time! Unless the player was a quantum particle!
joking
Spoilerp.s - Thinking about it does exist a way to spawn the player in two different spots at the same time! The xray feature! Just make it so when the player uses the XRay glasses he sees ia different room!
Or something like this game:
-
1 hour ago, datiswous said:
Well aperently it does, because this has been in core since TDM 1.08
Oh! I didn't knew that! Thanks for the correction. Is what happens when I take knowhow from the original Doom 3 engine (and Dewm 3 engine) as a starting point. :S
-
1
-
-
The engine has multi spawn positions but only for multiplayer, the single player code does not handle that but I see a way to go around this, what about using the player teleportation feature?
Something like this, In DR put special "go to" entities, just used as locations to transport too, then in the main menu GUI set which entity the player should jump too and then transport the player to it when he spawns, you can do a fade transition to hide the jump, for the player will be like he spawned there in the first place.
-
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...
-
1
-
-
10 hours ago, stgatilov said:
Definitely won't do it.
The first implementation did not have background, and it was hard to read subtitles on top of some bright parts in briefings. Background is here to ensure that text font is in contract with whatever the game displays below.
Would be to hard to do drop shadow for the text? Afaik that (and or using other color than white text like you see in thief 3) is how almost everyone solves that bright text over bright backgrounds.
P.S Unfortunately the example image I attached, looks worse than I thought, but in the real thing the text with drop shadow is very visible. And the drop shadow can be made stronger than that.
-
2
-
-
Sorry my reply was a bit confusing, those macros aren't defined anywhere (thou you can define them yourself...), it was only a idea for the TDM team to implement if they wanted. Sorry for making you waste your time chacing nothing.
TDM_MAJOR_VERSION, TDM_MINOR_VERSION and TDM_PATCHLEVEL (and the rest) need to be defined/created by the TDM team, and made part of the standard game defines, you can define them yourself, but that would be useless to anyone else, because only you would have those defines in your copy of the game, so right now afaik there's no way to do what you want, unless the TDM team creates those or something like those macros. I hope this is more understandable.
-
Hum personally I don't think that exists, at lest for all functions, I could be wrong thou.
But TDM, coming from Doom 3 should support
https://modwiki.dhewm3.org/HasFunction_(script_event)
but this is particular to script objects/entities and not to ask if some generic global script function exists anywhere and I don't really know how that would be implemented.
But couldn't script macros be used for that? Something like SDL does.
// based verbatin from SDL version define #define TDM_VERSIONNUM(X, Y, Z) \ ((X)*1000 + (Y)*100 + (Z)) #define TDM_COMPILEDVERSION \ TDM_VERSIONNUM(TDM_MAJOR_VERSION, TDM_MINOR_VERSION, TDM_PATCHLEVEL) #define TDM_VERSION_ATLEAST(X, Y, Z) \ (TDM_COMPILEDVERSION >= TDM_VERSIONNUM(X, Y, Z)) #if TDM_VERSION_ATLEAST(2, 11, 0) // run this func only in TDM 2.11 or above func(){ do stuff; } #endifNot totally sure if script language macro support is robust enough for this but it should be.
-
2 hours ago, MirceaKitsune said:
A little detail I'd like to sort out if possible: I've started working on a campaign which plans to use the existing style and assets in a more futuristic setup. One thing I'd like to make is light switches with an LED that shines in the dark. Model and skin are no issue, but I was wondering if there's a way to make it turn off when the light switch is enabled: Can an atdm:mover_lever have a skin_lit and skin_unlit like lights? If not I'll either have it always on, or attach the LED as a separate entity maybe giving it a small light too.
If you know how to script and make skin files for models then all entities should accept the following script function.
QuotescriptEvent void setSkin(string skinName);
Sets the skin this entity uses. Set to "" to turn off the skin.
Spawnclasses responding to this event: idEntity
Then is just a matter of setting the desired skin, depending on the state you set the light switch.
If you don't know how to script, this can still be done, even if not imo the ideal method, done using the special editor entity, target_setModel, if it still exists in TDM, if it does then this can be done directly inside DR , by just using the targeting and triggering functionality. More or less like so:
light switch -> triggerOnce ->target_setModel-> new light switch model
If I'm not mistaken target_setModel ONLY accepts model names and not skins as input, so this will require you to have two almost identical models, one with light on another with light off.
Hope this at lest gives you some pointers.
-
On 2/25/2023 at 12:12 PM, datiswous said:
Is there a console command (in tdm) that makes you jump to specific info locations? Coupled with automation, you could quickly jump to different rooms in a large map. I guess instead I could make a filter that filters everything away except the info locations. Then navigate between them..
Probably most mappers use a layer for every room (hide everything except the room)?
Yes there should be, not to jump easily to any entity in particular but you can "save" a camera view position and then jump/teleport to it.
if TDM engine team didn't changed any of this you could try:
cvar "where" or "getviewpos" -> "prints the current view position" so you can know where you are in world coordinates
cvar "setviewpos" -> "sets the current view position" ak teleports the player eye/view to that positionIf this particular cvars don't exist in TDM then look in the TDM wiki for something similar it most exist.
btw you can bind keys to cvars, so if you need to jump to a particular position many times, you can do
bind key setviewpos x y z yaw -> bind f1 setviewpos -50 30 75 180 and just press f1 to jump to that position when you need
Hope this helps.
-
1
-
-
21 hours ago, AluminumHaste said:
There is no SS3, how can they do a remake?
And thank god they got rid of unity, that engine is total trash garbage on anything over 60 fps.
Just spend 5 minutes on steam forums for Unity project games, and there's just thousands of people complaining about poor performance, stuttering etc.
Totally agree and not only that but if Doom 3 was made on Unity, TDM would never exist, because any game made on Unity is just almost impossible to be modded, unless you do heavy reverse engineering of the files (most don't know how) or the developers make their own mod tools, that I assume less than 1% of Unity game developers bother to do or even know how to develop their own tools.
Quote...
I think in CDPR's case, the choice to move to Unreal made practical sense. The talent pool for people familiar with Unreal is far higher than REDengine and that in itself would speed things up considerably as opposed to getting new people familiar with an in-house engine
...
Xolvix that is my supposition as well, but is a petty variety in the game engine world, is slowly dying, not only because that is starving the engine making talent pool, but also because that has a real impact on the look and feel of games, unless the developers go out of their way to remove the engine default look, all games made on Unity or Unreal look and feel the same.
Newbie DarkRadiant Questions
in TDM Editors Guild
Posted
Personally I really don't know if that is available or not but that does sound too a specific guard behavior, so perhaps is not defined?
If is possible to have that? Yes, if is not available already, unfortunately there's no other way but code it into the guard AI, in c++ or script yourself, if you know how to code....
Btw the civilian AI does have "fear" and runs away from danger, is that AI type really entirely separate from the guard AI, or the guard behavior is just "dormant" on the civilian AI and vice versa?
If all AI's are done through the same AI system then perhaps is just a matter of turning some stuff on or off.
If they are totally separate AI's, they are still so similar in parts that perhaps so you could adapt/transfer the civilian fear behavior into the guard AI for specific types of danger. But all of this requires coding.
Sorry for not being more helpful than this, I really don't know much about TDM or even Doom 3 AI stuff.