STiFU

If we were able to convert our existing materials to "good enough" PBR materials, we could make the switch to a PBR renderer. This would allow us to successively improve our materials and new contributions could be made directly with PBR. If we had to first fix ALL materials manually up for PBR before making the switch, I don't think this small project would ever take off. That's the motivation for the investigation if the materials can be converted in a sensible way.

The main issue seems to be to derive metalness. What does our current specular map do? It basically encodes reflection intensity at a constant roughness. Isn't reflection intensity basically metalness?

Congrats! Have to give this a shot soon!

I have visited Marienburg (Malbork Castle) in Poland this summer. It is the biggest brick building in Europe and was built and used by the German Tuetonic Order. It was later used by the Nazis and many parts were destroyed during the war, but it has been faithfully rebuilt. Here are the pictures I took: https://drive.google.com/drive/folders/17Vd-2kJG6sLfBi0cCJ6-g9wBT733T5lZ?usp=sharing

I played Fallout 2 back then and it was a great game. I vastly prefer the oldschool c-rpg Fallouts. Sadly, due to 16 bit color depth and low resolution, these games did not age too well. Here's to wishing for a Remaster.

Yeah, I was not very optimistic about my idea to begin with. So, we'd have to painfully go through all materials (and custom FM materials) and convert them manually. Makes me wonder if it would be feasible to support both PBR and traditional materials in a somewhat efficient way in our renderer, so we could still have a functioning game while not all assets have been converted. @stgatilov?

PBR sure would be a major upgrade for our game. Problem is, all our assets would have to be converted and that includes custom assets from FMs. I do wonder, whether there is any research on automatically converting traditional materials to "good-enough" PBR-materials, or if we should experiment ourselves with such a process. I imagine a heightmap could be "approximated" from Normalmap (I know this is not accurate, but would maybe be good-enough for starting), metalness could be derived from thresholded specular map (or material name), glossiness could be derived from normalmap roughness and maybe specular map and as albedo we could simply use the existing diffusemap (maybe try to get rid of any brightnessvariations on that map). @stgatilov care to comment?

I finished all Splinter Cell Games multiple times, except for Conviction of course, which I only finished once because it's horrible. It did have excellent coop, 'though. If someone were to ask me if Splinter Cell or Thief/TDM are my favorite games, I'd have a hard time answering. Considering there is a shipload of content available for Thief/TDM, the longing for new Splinter Cell content is definitely a lot stronger! Maybe I should seek another hobby game dev community called PooBeeSoft for developing a game called "Separated Agent Group" featuring Cam Wisher...

Glad you enjoy it. And I can assure you, it will stay free forever.

That changeset reads quite decent, actually. Not sure about your naming, 'though. "Ring helper"? Which bell is it going to help me ring? ;-D Jokes aside, here are some comments: Do these bugfixes also apply to the core mod, or are they exclusive to your mod-pack? That's a great idea and very consistent with your design approach. I can see the value of this feature. Something like this was frequently discussed when developing various features for the core mod. However, we always dropped that idea because the light-gem does not reflect how bright the object you are looking at is. It only shows how bright the player is. So, utilizing the light-gem here will lead to incorrect brightness of the helper GUI. I would suggest to better leave it at a constant value. Would you mind elaborating what you mean by these?

So, you essentially replaced the dot by a ring and changed some cvars in addition to that bugfix you mentioned earlier?

Not sure if you confused tdm_frobhelper_fadein_duration with tdm_frobhelper_fadein_delay here, but if anything, I would discard the delay. The fadein_duration is supposed to smoothen the appearance of the frobhelper, thereby making it a bit more subtle. Why would you want to delay displaying the frob helper and then have it pop in instantly? If a player wants it to be intrusive, the hover option is the way to go. Subtlety was a key requirement in the design of this feature. Thats probably something we should fix.

I'd hardly call it a mod, if the functionality is already there and it's merely about presenting the settings in a different way. Anyway, I already said that I basically concur and that I would ideally like to see an extra accessibility settings GUI for all related features: frob helper, head bob, more subtle mantle animations, you name it... Still, your reasoning is kind of wrong because the intention of the frob helper was not to detect frobably objects, but to help the player aim on small frobable objects. The "Always On" feature unconditionally helps the player aim, so this does not conflict with the intention of the frob helper at all.

I always tweak the tdm_frobhelper_ignore_size such that it is enabled for all object sizes as well because I prefer it that way. However, back when I implemented this feature, it was common feedback that it shouldn't be enabled for big objects like doors etc. because it was intended to help frobbing small objects, i.e., it was not supposed to be an interaction indicator, which we already had in the frob-highlight. The reasoning for this feature still stands today, so I don't see how this qualifies as madness. The "Always On" feature has indeed been added as an accessibility feature as it supposedly helps some people with motion sickness, and since there were now already multiple options, I also added the "fade-in fast"-option because I felt the delay of the usual fade-in was so long that the frob helper wasn't really that helpfull in more hectic situations. Accessibility features should by definition never be hidden, so I would not remove the "Always On"-option. In fact, I would actually like to see an extra options page only listing accessibility options. On that page, we could then of course also add a checkmark-option to enable frob helper only for small objects.

Sorry, I didn't mean to step on your toes and to dictate the title change on you. I was merely raising concerns, as the title and beginning of this thread reads an awful lot like one of these here... Full disclosure: I haven't played your FM, yet, so maybe I didn't get the full picture. But then again, there are probably more people as clueless as me that don't get it at first either. Futhermore, you had some avatar come in and tell us about the loss of a beloved community member, wheras in myhouse.wad, it was the opposite, i.e., some random dude nobody in the community knew was gone.

@Wellingtoncrab would you mind editing the main post by either removing those parts about you being lost or at least put an "april fools" disclaimer on it. I might be over sensitive, but given the actual losses of some beloved community members, I kind of feel like this is something not to joke about. And honestly, I completely fell for it at first and was really sad and shocked for a minute or two, and frequently checked your profile if you finally came back online. By the way: Did you steal the idea from myhouse.wad?

Forum search is king!

I always loved the "connections" theme and I think it is very fitting to celebrate TDM. It's a shame we can't have 4 polls per thread because then my proposal would be to have free-for-all with a "connections"-rating added that evaluates how well the mission integrates into or expands upon the existing lore.

That was exactly the intention of "A New Job". When you play, you will notice that there are pop-ups every now and then, explaining some mechanics. But honestly, there are so many mechanics in TDM that it is hard to introduce everything in an entertaining way.

In the beta phase, we usually only address regressions since the respective previous version or bugs with newly introduced features, in order not to unnecessarily lengthen the beta-phase. And we are already in release candidate territory, as stgatilov already said.

You can download the build tools independently of VS: Buildtools for Visual Studio 2022. If you can still install those on Win7, you can maybe build DR with the command @stgatilov posted above. You might need to navigate to the directory where msbuild.exe is located first or even launch a developer console (which should be available in the start menu after you installed the build tools).

If there ever was a common code-style, it is definitely lost forever in the TDM-codebase. It's a huge mess in this regard!

Of course, identifying struct via HN is useless. At work, we use HN when there are reasons for caution: u for unsigned to prevent unintentional implicit unsigned promotion (and overflow) Yes, I know, the compiler will issue a warning, but in some legacy projects, there are tons of warnings, so devs are going to miss that one new one. We are slowly working toward warning-free builds, but as long as we are not there yet, the u-prefix helps a lot. p for pointers to make the reader / dev aware that that variable could be NULL. m_ for members, obviously useful. Similarily, g_ and s_ for globals and statics respectively, although it is obviously discouraged to use those. Various prefixes for the different coordinate systems we use. I for interface, just for convenience b for boolean, this is basically just for convenience so you can directly see that this is the most basic type. This one, one could defintely argue against, but I personally like it.

That's because all those guides apparently did not reach the age of web-page-based Code-Reviews via Github, Azure Devops, and the likes... All the people arguing against Hungarian say that you simply don't need it anymore, because your compiler / IDE will tell you what type a variable has (your Pull-Request web-gui will not show you that information) and that Hungarian only makes it harder to read variables (which is not really accurate, as our brain is perfectly capable to read any camel-case variable or function, so why shouldn't it be able to parse the prefix?).

By the way, give Graven some more time to mature. In it's current state, I can only recommend it to true Hexen-fans. Want to know more? https://steamcommunity.com/id/stiffsen/recommended/1371690/