STiFU
-
Posts
4448 -
Joined
-
Last visited
-
Days Won
56
Posts posted by STiFU
-
-
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?).
-
1
-
-
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/ -
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.
-
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.
-
1
-
-
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.
-
1
-
-
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.
-
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
That's one way to not spoil what this game is actually about!
Absolutely excellent game and so meta.
-
1
-
-
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.
-
2
-
1
-
-
15 minutes ago, peter_spy said:
Also, maybe this will help to illustrate the problem better:
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...
-
1
-
-
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.
-
1
-
-
Infinifactory now free on Epic. Great automation / optimization puzzle game. Had quite some fun with that one.
-
2
-
-
5 hours ago, Fiver said:
By the way: the web page (https://www.thedarkmod.com/missions/) has a column "Type" which has values "S" or "C" but it does not explain the difference. Does anyone know?
It stands for campaign or single mission.
-
1
-
-
25 minutes ago, nbohr1more said:
That bug report could be interpreted in two ways: One, the ingame-downloader-sorting needs changing, Two, all other lists needs changed sorting.
The current sorting does not even resolve the issue as the sorting is still different from the missions web page.
-
CMOS all the way! It is in a way truly alphabetical, while allowing for efficient searching, and it is a world-wide standard way of sorting things.
-
1
-
1
-
-
It was most definitely the shortcomings of T3 that spawned the development of TDM.
-
On 1/8/2024 at 11:40 PM, snatcher said:
@Daft Mugi, Please spare us from this. You are entitled to your own opinion and vision but you aren't the voice of them players. You sound as if you felt compelled to do it. You decided to step forward now go and put yourself upfront, defend your position, address user concerns and acknowledge criticism. Be real, just like the old guard.
To be fair, he has put forward a lot of evidence internally. There was a huge (and heated) discussion and we eventually landed on a compromise.
I totally understand, 'though, how you feel like this comes out of nowhere. I get it.
On 1/9/2024 at 10:17 PM, ChronA said:With that many maps what a lot of people are going to want is curation and quality control.
This!!!!! Absolutely this! I have been arguing for something like that for years, but I do understand the arguments of those opposing this. At least you can sort by release date now.
-
18 hours ago, wesp5 said:
so please make it so that hold-frobing takes a moveable light and short frobing extinguishes it! This would also be more consistent to the static lights. The same should be done for consumables too: short frob eat, long frob pick up...
It is already implemented. This is exactly what my extension of the new control scheme does.
tdm_holdfrob_drag_all_entities
Have fun, mate!
EDIT: Correction: Sorry, I misread your post a little bit. Only for extinguished lights and food remains, the hold-type-grabber is used with my extension. For lit candles and food, short frob is still grabber and long frob is extinguish / eat.
3 hours ago, Kopfrkingl said:So the old system is still present in 2.12? Then I truly fail to see the issue some others perceive
The thing is that there are plans to keep only one control scheme on the long run, which I am totally against, 'though, see below.
1 hour ago, Baal said:But just for the sake of this discussion: what if the default action for bodies (drag or shoulder) could be chosen with an option? A simple checkmark that switches these around (either short frob = drag and long frob = shoulder or the other way around)?
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.
1 hour ago, AluminumHaste said:So you forgot how to use the new system AND forgot how to use the original system? So either you had a stroke or you're arguing in bad faith.
Let's try to keep the discussion constructive, please. There is no need to make it more heated.
-
1
-
-
I think that was directed at me, as I usually argue for the new control scheme (albeit with some modifications). I liked that post because it contained some valid points of criticism:
20 hours ago, snatcher said:Besides that above, players are now exposed to:
- Unintentionally shouldering bodies while trying to retrieve items from bodies
- Unintentionally un-shouldering bodies when trying to operate doors
Especially the first point frequently happened to me. Yes, the new frob-to-loot feature is there to help, but I still sometimes accidentally shouldered a body.
-
You can buy a displayport to hdmi adapter very cheap.
-
2
-
-
How you get from Prey, an immserive sci-fi game, to BG3, a D&D fantasy cRPG, is beyond me, but it sure seems to be a good game.
-
1
-
-
You are effectively using a different GPU when using the onboard VGA port, which raises the question, what CPU / onboard GPU are you running?
My bet is that your 2 Gigs of VRAM are simply insufficient for running Iris at Full HD. Could you try a small FM like "The Parcel" with the new monitor and GPU?
-
23 hours ago, chakkman said:
Same with the new mantling. I don't know what you felt was wrong with the mantling before, but, this new, faster system just feels arcade. The mantling was already very quick compared to what a human is capable in real life, but, the new system even exaggerates that. Yes, it feels smooth and fast, but, I prefer a bit of realism.
It was mainly the overhead mantle with its long initial hang-phase, that was shortened, while everything else was just minor adjustments. The hang-phase really was extremely long and shortening that was a good suggestion in my opinion. However, I do agree that we went a bit too far with the adjustment. One might argue that a very short hang-phase is realistic, when jumping upwards with high velocity. Conversely, it is rather unrealistic when falling fast, which is why I had internally proposed to keep a longer hang-phase when falling fast. That suggestion didn't gain a lot of traction, 'though, and I did not want to stretch the discussion even further, so I just did not follow up on this.
23 hours ago, chakkman said:The new frob system is very nice.
By any chance, did you also try the extension of the new frob system where the hold-type-grabber is used not only for limbs, but for all junk etc.? You can enable it with tdm_holdfrob_drag_all_entities. What are your thoughts? I had implemented that in order to make the new system a bit more consistent.
-
2
-
-
Maybe reducing the cvar in_padDeadZone will help.
Documentation on controller support: https://github.com/fholger/thedarkmodvr/wiki/Gamepad-support
Having said that, it is usually sufficient to crouch-walk, i.e., creep not required.
-
2
-
1
-
-
On 12/24/2023 at 10:28 AM, peter_spy said:
maybe, instead of worrying what future license might include, there could be a steady effort to replace photo-sourced textures with hand-made / proc-gen ones? That list is huge, but the peace of mind in the end is priceless.
I doubt that we have the man-power to pull that off these days.
Since TDM has no actual legal entity, nothing can really happen to anyone of us other than a request to take it all down, which we would happily oblige of course and then start to fix up the critical textures. I am sure, once the need to fix them up is actually there, the man-power will naturally reactivate for TDM.
I also doubt that anyone would come after TDM at this point, as it is a beloved community project that had tons of news coverage in the past and the creators of textures.com know about and approve of us.
I was also trying to find our internal discussions about these licensing issues, but couldn't find them anymore. Maybe @nbohr1more knows any further sources?
On code style
in The Dark Mod
Posted
Of course, identifying struct via HN is useless. At work, we use HN when there are reasons for caution: