STiFU

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/

I agree, and you might become happy in 2.13. My thinking was that you could select "Thief-Style" (new Daft-Mugi control scheme) or "TDM-Style" (old control scheme, but with long-frob shortcut for frob + use). No promises, however. The proposed change has to be accepted by more than one team member after all.

This is an intereting discussion. So, could one of the mods please move this to a separate thread as to not derail the beta testing thread. As a developer, you spend about 80% of your time just reading code. So, optimizing for readability is very important. The more information you can gather just by reading without cluttering up the code (by needless comments) the better. Hungarian notation helps immensely to quickly prase the displayed code in your brain. Yes, your IDE will show the desired information as well, but a mechanical interaction with the code is required to show it (mouse over or similar). Also, often you are tasked to do code review on webpages that don't offer these nice crossreferencing features of your IDE. Some things are objectively bad, 'though, so the respective rules preventing those things should universally be followed. For instance, much legacy code is nested extremely because at some point in time, it must have been a rule that you only have one return-point in your function (probably a c-residual). Such code is exhausting to read ("what was the else-if-condition some 1000 lines ago leading to this else-case again?") and very likely contains tons of code duplication. Today, we have the rule to only use little nesting and short if-else-clauses, to make the code easy to read and debug. If I come accross such a nested legacy function, I refactor the shit out of that function while trying to understand it, just so the next person after me doesn't have to deal with that horrible mess again.

After we were green-lit in just a couple of days, we were informed that we would have to form a legal entity, so that somebody can be held liable for potential copyright claims, and that we'd have to guarantee that there is no copyright infringement in the game. Since we are not 100% able to guarantee the latter, the prior poses quite a risk to the legal representative of the mod. So, we decided to drop this endeavor.

Honestly, I wouldn't be so quick to judge here, as noone knows the history of this code-snippet. It might just have been that there were floating-point-quantization errors in dmap and that they wanted to get rid of those by rounding at the desired precision, i.e., 0.001. Also, floating point comparisons with fixed precision like this are not uncommon at all. Some applications simply don't require more accuracy so you skip the very complex "regular" floating point comparison.