Search the Community

In fact, there are no 2.11 turret features since it's a completely new thing for 2.12. Unofficial script versions of the turret also rely on code changes that were made during turret development for 2.12.

Update: @JackFarmer The root cause of the turret crash has been found. It seems that it was given the same physics code as the security camera but does not have handling for cases where no clip model exists. Removing the physics code fixes the issue. That said, I guess we may look into adding it back so that the turret follows the same destruction features as the camera?

I took a look at DR 3.8 source code (not latest), and it seems to me it only ever checks for the fs_game and fs_game_base command line parameters.

Something I was thinking of: Even if some assets are non-commercial, are all assets at least accounted for to make sure they're credited accordingly and can be distributed? I ask following an issue in another great project I work with called Red Eclipse: They don't have NC assets but did have a few texture packages they had to remove because they later found out their clauses were incompatible with the project. If this hasn't happened in well over a decade it's very unlikely anyone would complain today and request removal for any reason, but if any resource had its license misunderstood that could destroy existing FM's unless perfect replacements were found. Obviously I presume the team never included any asset randomly found on the internet without verifying their explicit requirements in detail, but it doesn't hurt to check. I think the best that can be done otherwise would be to have a list of which assets are libre or have the NC clause: That way a map can choose to use those models and textures that are free if the author wants their FM to be fully libre, albeit this would handicap an author in what packages they can use. If core assets like character models or textures are also NC, the idea is likely pointless as you can't make a FM without those, at best you can skip a few texture packages... not sure about other things like core scripts or defs, since they're technically code I presume those are GPL?

I don't think they're mutually exclusive. A well designed coding standard tends to promote clarity. Still, there's inevitably oddball cases where you can make the code clearer or more efficient by breaking the rules and then you should definitely break the rules.

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!

BFG has no Dmap source code... checking RBDoom3BFG. RBDoom3BFG uses the same as vanilla

Perhaps id didn't cared for that loss on accuracy, at lest for Doom 3, is hard for me to believe they did that for lack of knowledge or something but who knows. Is this code still in BFG?

It turns out we have many people who enjoy discussing code My complaint about that code is that all floating point numbers are snapped to integers with same tolerance. The .proc file contains a lot of different data: models, shadow models, BSP tree, visportals. They contain in different combinations: positions, texcoords, normals, distances. Snapping or comparing all of these quantities with same tolerance is a really bad idea. Some data is more sensitive to changes than other. They even have different measurement units, i.e. you position is measures in something like meter-units, while texcoords are usually measured in something like tex-units, and they are as incomparable as meters and seconds. Some data should not be snapped at all because that could break its internal invariants. If you snap coordinates of normal vector, it is no longer normalized, and the receiver has all the fun of dealing with extremely rare cases which normally should not happen. As for Hungarian notation... I do some mesh processing with halfedge data structures. When you have 10 local variables being halfedge handles, 5 local variables being face handles, and 5 local variables being vertex handles, it becomes much easier to understand what's going on if they start with "he" / "f" / "v" respectively. But this is very situational of course. Just starting pointers with 'p' and array-like stuff with 'a' is usually unnecessary, unless you have 3-4 levels (triple pointer or triple arrays), although in that case the code is smelly regardless or how you name variables

@grodenglaive I think random head turning might be plausible for specific characters, if they're supposed to be paranoid for some reason. But you should let the player know in advance that they're always looking over their shoulders. I don't know if Elsevier has any reasons to be paranoid, but it could be plausible in his case. It could even be one of the reasons why Astrid had a hard time seeing him insert the safe code. The doors thing, at least some interior doors were auto-closing too. I was specifically thinking of the dinning room doors when I wrote that. I think there were more auto-closing interior doors, though. Personally, my potato doesn't have any real issues with performance in this mission. Only on the outside the frame rates drop below 60 sometimes, but never enough to make any noticeable difference to the gameplay. That said, I wonder if you could use double visportals on the outside doors. That might help, as the inner portal should close more often, without needing to close the doors. I use double portals sometimes because of that. But it needs testing to know for sure whether it helps or not. (It also requires adjusting info_locationSeparators, as they can only touch one portal). Also, the big visportal in the water that separates the front yard from the spider area seems to be always open. I wonder if having two visportals in a V shape (from the top view) instead of that one, would help closing it. Or some similar configuration that doesn't interfere with the view from the watchtower.

Because the player didn't move/make noise, the code that AI uses to "listen" for the player wasn't triggered. Because the AI weren't on the same team, the alert level wasn't propagated to the other AI. There's so much that goes on to make AI SEEM like a facsimile to real people, but there's always going to be edge cases where's there's no code to handle 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?).

I was wondering if it's possible to make a program that generates a subs file from a folder with a bunch of srt files. I know this is too much to ask for, but I just mention the idea.. The lines are usely: srt "sound/sub-path-to-sound-folder/sound-file-name.ogg" "subtitles/sound-file-name.srt" Edit: I think I already figured it out using Python code. Just putting it here quickly so I can reproduce it later. import os, sys path = "C:/Progs/tdm/fms/mandrasola/sound/sfx/mandrasola/" path_sounds = "sound/sfx/mandrasola/" path_subs = "subtitles/" listfiles = os.listdir(path) for x in listfiles: print("srt " + '"' + path_sounds + x + '"' + ' "' + path_subs + x.removesuffix('.ogg') + ".srt" + '"') Generates: srt "sound/sfx/mandrasola/mandrasola_guard1.ogg" "subtitles/mandrasola_guard1.srt" srt "sound/sfx/mandrasola/mandrasola_guard2.ogg" "subtitles/mandrasola_guard2.srt" srt "sound/sfx/mandrasola/mandrasola_lovell1.ogg" "subtitles/mandrasola_lovell1.srt" srt "sound/sfx/mandrasola/mandrasola_lovell2.ogg" "subtitles/mandrasola_lovell2.srt" srt "sound/sfx/mandrasola/mandrasola_lovell3.ogg" "subtitles/mandrasola_lovell3.srt" srt "sound/sfx/mandrasola/mandrasola_lovell4.ogg" "subtitles/mandrasola_lovell4.srt" srt "sound/sfx/mandrasola/mandrasola_lovell5.ogg" "subtitles/mandrasola_lovell5.srt" srt "sound/sfx/mandrasola/mandrasola_lovell6.ogg" "subtitles/mandrasola_lovell6.srt" srt "sound/sfx/mandrasola/mandrasola_ludmilla1.ogg" "subtitles/mandrasola_ludmilla1.srt" srt "sound/sfx/mandrasola/mandrasola_ludmilla2.ogg" "subtitles/mandrasola_ludmilla2.srt" srt "sound/sfx/mandrasola/mandrasola_ludmilla3.ogg" "subtitles/mandrasola_ludmilla3.srt" srt "sound/sfx/mandrasola/mandrasola_ludmilla4.ogg" "subtitles/mandrasola_ludmilla4.srt" srt "sound/sfx/mandrasola/mandrasola_ludmilla5.ogg" "subtitles/mandrasola_ludmilla5.srt" srt "sound/sfx/mandrasola/mandrasola_ludmilla6.ogg" "subtitles/mandrasola_ludmilla6.srt" srt "sound/sfx/mandrasola/mandrasola_ludmilla_iwarnyou.ogg" "subtitles/mandrasola_ludmilla_iwarnyou.srt" Man this would have saved me so much time yesterday..

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

The previous reporter who had non-working glasses said game crashes on drop. The same happens for me. As you might guess, most of the code expects the entity of the inventory item to be alive. Anyway, I don't think it is possibled to drop inventory item if it has no entity, because logically it should just put this entity back into the world. If it's dead, it can kill the inv. item, but I don't think it can resurrect the entity.

I have added some notes to 6436 relating to the 'shot from afar' problem. For your main point (1 in your original report) I think that the main aspect of it is that you are (code-wise) literally invisible to the guards. It's as though if there was a real-life invisible man who whacks you on the shoulder from behind, you'd whirl round and there would be no-one there. What would you do?

That is interessting. I also do not find hungerian notation helpful in any way. Exactly the opposite in fact. I was doing a lot of functional programming recently, where code is very short and concise. Maybe that's the reason. It is simply not needed there.

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.

They are there for a reason though, not just because someone said so. If you want to communicate with people and you work on the code with someone, you need to share some common principles. And while I agree that things like clean code can be a bit extreme at times, I've never seen anyone questioning it super hard; neither stuff like solid principles, for example. Obviously, you can be a rebel if you want to, but you'll probably end up working alone.

Orbweaver said all what I thought, I also hardly always follow programing "rules", mostly because "basic naming conventions in programming" change with times and as the languages evolve and change. So imo no one should get to much hung up on those, specially when some rules aren't even evidence based but some famous coder thought it made the code "cleaner" and people just followed. For example Hungarian notation, so many coders use it but to me it can crash and burn. I played around with Penumbra HPL engine for a time and it is riddled with such notation and not once, I felt it helped me understand better the code, for the contrary.

I've very rarely seen setter methods which return values (unlike getters which obviously need to return the value they are "getting"). What value should a setter return? The same value it was given as a parameter? That's entirely pointless because the calling code already has that value. It could return the previous value, but such a value isn't necessarily defined (and doesn't appear to be relevant in the case of writing something to a file). Sometimes setters return the object itself, so you can call them in a chain, e.g. myObject.setWidth(60).setHeight(20).setColour(RED); but it's not clear how that would work with writeFloat which isn't an object method to begin with. That's certainly common (and is a convention I use), but not universal. The C++ standard library doesn't use it, for example — to check if a vector is empty you call std::vector<T>::empty(), not isEmpty().

@MirceaKitsune - have you raised a bug report for this particular problem (searching in the wrong place if shot by an arrow)? I think I have found the cause of it and can write it up in the bug tracker. In short, I believe the intended behaviour is that the victim is supposed to search halfway between him and the shooter (presumably chosen because he shouldn't really know where the shooter really is) but the code that sets this point gets overridden shortly afterwards by code that sets the search point to his current location. It's quite instructive (if you like that sort of thing) to read up the various bugs reports on AI behaviour that have been raised down the years. In particular, bug 3331 contains a number of fixes to problems similar to those reported in this thread.

Dhewm3: static void WriteFloat( idFile *f, float v ) { if ( idMath::Fabs(v - idMath::Rint(v)) < 0.001 ) { f->WriteFloatString( "%i ", (int)idMath::Rint(v) ); } else { f->WriteFloatString( "%f ", v ); } } Hmm... The original GPL Doom 3 code: static void WriteFloat( idFile *f, float v ) { if ( idMath::Fabs(v - idMath::Rint(v)) < 0.001 ) { f->WriteFloatString( "%i ", (int)idMath::Rint(v) ); } else { f->WriteFloatString( "%f ", v ); } }

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.

Uff... hard-coded "magic numbers" like this always make me uneasy.