Jump to content
The Dark Mod Forums

STiFU

Development Role
  • Posts

    4423
  • Joined

  • Last visited

  • Days Won

    50

Posts posted by STiFU

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

    4 hours ago, snatcher said:

    Correct aspect ratio across different resolutions

    4 hours ago, snatcher said:

    Ring removed when peeking or using the spyglass

    4 hours ago, snatcher said:

    Pointers remain in the background when using readables / menus

    Do these bugfixes also apply to the core mod, or are they exclusive to your mod-pack?

    4 hours ago, snatcher said:

    Always On mode switches between the dot and the ring

    That's a great idea and very consistent with your design approach. I can see the value of this feature.

    4 hours ago, snatcher said:

    Extra dynamic brightness based on lightgem values

    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.

    4 hours ago, snatcher said:

    Pointers designed to blend in with the user interface

    4 hours ago, snatcher said:

    Little trick to make things flow when operating doors

    Would you mind elaborating what you mean by these?

  2. 3 hours ago, snatcher said:

    In my opinion the fade in speed (tdm_frobhelper_fadein_duration) must be discarded. Players should not be waiting to see if they can detect the helper but should wait because they know the helper is about to popup in its full glory.

    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.

     

    9 hours ago, snatcher said:

    Nobody?

    While working on the mod I noticed that while "Fade In Fast" parameters apply it does not stick in the menu from session to session and it reverts back to "Fade In". The preset is missing in game/game_local.cpp:

    int frobHelperPreset = 0; // Off
    if (cvarSystem->GetCVarBool("tdm_frobhelper_active"))
    {
    	if (cvarSystem->GetCVarBool("tdm_frobhelper_alwaysVisible"))
    	{
    		frobHelperPreset = 1; // Always
    	}
    	else if (cvarSystem->GetCVarInteger("tdm_frobhelper_fadein_delay") == 0 &&
    	         cvarSystem->GetCVarInteger("tdm_frobhelper_fadein_duration") == 0)
    	{
    		frobHelperPreset = 2; // Hover
    	}
    	else
    	{
    		frobHelperPreset = 3; // Fade In
    	}
    }

    Thats probably something we should fix.

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

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

    • Like 2
  5. 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.

  6. @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? 🙂 

    • Like 1
    • Thanks 1
  7. On 3/27/2024 at 11:38 AM, Bergante said:

    Thanks 🤩
    funny to find this pages (i´ll gona put them to my Fav´s)
    but before i add some off my stuff i´ll need to listen to what you´ve posted ! 

    P.s.: can you give me the titel/link to  @STiFU's progessive music thread.

    Forum search is king! ;)

    • Haha 1
  8. 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.

    • Like 1
  9. 10 hours ago, MirceaKitsune said:

    Maybe this can be fixed in time for 2.12 so we aren't stuck with the broken behavior for the whole release?

     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.

    On 2/24/2024 at 6:57 PM, stgatilov said:

    beta212-07 is available.

    This one is considered release candidate, meaning that most likely it will be turned into official release soon.
    For this reason, here are the deprecated 32-bit binaries.
    It would be great if someone briefly checks the 32-bit Linux executable (cannot do it myself).

     

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

  11. 2 hours ago, OrbWeaver said:

    Exactly, and it breaks down completely once you start using more complex types than primitive numbers. Knowing that something is a pointer is useless without knowing what it points to, knowing that something is an "obj" or a "struct" is similarly unhelpful, and once you start trying to expand the convention so that the prefixes can convey information about the actual object type, you will end up with complex multi-character encoded prefixes that nobody else will be able to understand.

    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.
    • Like 2
  12. 6 hours ago, OrbWeaver said:

    I'm surprised to hear anyone is using Hungarian notation these days. It's one of the most derided, disliked, obsolete and useless naming conventions in programming. I don't think I've ever seen a modern programming guide or tutorial which advocates it (except perhaps in very limited situations like using "mSomething" to indicate a member variable).

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

    • Like 1
  13. 1 hour ago, Fiver said:

    To me it would make more sense to swap the two triggers for bodies. That way
    * "Frob" would mean "grab and hold object in front of you", and "Frob" again would mean "release" consistently for all three objects.
    * "Hold frob" would mean "interact" (="shoulder"/"unshoulder", "extinguish", "eat") consistently for all objects.

    And if "unshoulder" required "Hold frob" it would reduce the risk of unintentionally un-shouldering bodies when trying to operate doors.

    I may be missing something here...

    I agree, and you might become happy in 2.13.

    On 1/21/2024 at 6:27 PM, STiFU said:

    I have already commented/suggested internally that the frob-code needs refactoring anyway, and if we were to do that for 2.13, we might as well introduce a simple switch. Basically, the code would determine if short frob or long frob has been pressed and then decide which action to perform based on the chosen control scheme. 

    And for your information, my preferred solution has always been to keep the original controls, but have long-frob as a shortcut for frob + use. This might be an option with the proposed refactor.

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

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

    1 hour ago, HMart said:

    Hungarian notation, so many coders use it but to me it can crash and burn

    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.

     

    1 hour ago, HMart said:

    I also hardly always follow programing "rules"

    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.

    • Like 1
  15. 15 hours ago, Fiver said:

    I'd be interested in hearing more about what the licensing issue on Steam was.

    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.

    • Thanks 1
  16. 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.

  17. On 2/3/2024 at 11:03 PM, peter_spy said:

    I've never been into deck building games, but this one is excellent. Fairly complex, but unfolding slowly, and super addictive. The "just one more go" syndrome is strong with this one :D

     

    That's one way to not spoil what this game is actually about! 😄

    Absolutely excellent game and so meta.

    • Like 1
  18. TDM is already a niche genre. If we release it to a niche platform, it will be niche²! Since we would have to strip TDM off all its assets, recreate some and build a demo FM around it, it wouldn't be more than a tech-demo, i.e., there is no game, which would be niche³. It's just not worth it! We even did not release on Steam due to licensing issues and on that platform, we actually could have gained a huge player-base.

    No TDM dev has ever showed interest in doing such a thing and that also goes for most of our community.

    It's not going to happen unless you do it yourself. Be prepared to put at least 2 years of full-time work into this project.

    • Like 2
    • Haha 1
  19. 15 minutes ago, peter_spy said:

    Also, maybe this will help to illustrate the problem better:

    Fresnel-differences.jpg

    As you can see with image 2 & 4, the geometric complexity, whether with actual polygons or faked via smooth edges on normalmap, does matter. And I bet when most users think 'fresnel', they mean the last example.

    Most TDM geometry is brushes and models textured with simple tiling materials. They won't look like the last example, until they have enough polygons.

    Hm, I am not sure I follow. Shouldn't the behaviour of the Rim shader be independet of actual geometric complexity and normal map based complexity? If the answer is yes, then brushes should also look fine because the applied material provides geometric complexity.

     

    15 minutes ago, peter_spy said:

    I think you mean Reshade. I used it a couple of times, it has a few interesting tricks up its sleeve

    Reshade is awesome. I use it all the time to improve the visuals of old classics. The Post-Lightmaps-Era games just look so much better with some SSAO...

    • Like 1
  20. On 1/22/2024 at 11:45 AM, datiswous said:

    Normally one would post in the topic of the fm and then hope that someone (the author) comes along to fix it

    Yes, while Saint Lucia and A New Job are a little different, seeing that they are parts of the official introductory campaign, we usually use the bugtracker only for engine and core asset related issues. Please use the respective FM threads in the future.

    • Thanks 1
×
×
  • Create New...