Obsttorte

Just for my understanding: Why do you set your monitor brightness to the lowest possible value while on the other hand increasing the in game brightness to such an absurd value? I mean the screenshot looks almost like you are playing a daytime mission. As I see it, at least from your example, you are simple hitting some technical limitations. The brightness can't be increased indefinetly without encountering issues at some point, as the pixel colors are capped (they don't exceed a specific value). So upon increasing the brightness you hit a point sooner or later where the colors start to wash out and everything turns into white noise. When this happens depends on several aspects and the range in which you can alter the brightness is probably set a bit randomly, but obviously you cannot expect things to work well if you are choosing settings that far from the default. If you consider the game too dark I would suggest that you keep the ingame brightness close to the default value and increase the screen brightness instead, as this may yield better results.

I'd say so, too. It is an aesthetical and therefore a mappers choice primary. Although I can see that it can be annoying, especially when playing at night/in a dark room, so I would suggest that you first give this feedback in the respective fms thread. Maybe the mission authors aren't aware of this. If it turns out that there is no specific intention behind it and that the mission authors don't care, it should in principle be possible to cap the brightness. But I am pretty sure you can do this in either your monitor or your graphics card settings. (Personally I use f.lux which tones down brightness and shifts the color towards a orange/brownish tone at night. That would make the first readable pretty much look like the second one).

Or in klingon and then translate it into elvish.

@DragoferWell, that's more often than I thought it would be. I agree that it makes sense to upload the fms somewhere, so they don't get lost. The betamapper repo seems fitting.

I mean't a seperate one, just like that.

Sending someone a pm may not necessarely cause the person to get an e-mail, as he either could have turned the notification of or isn't using the respective e-mail anymore. Maybe something like this list?! https://wiki.thedarkmod.com/index.php?title=Upcoming_Fan_Missions (which is btw. heavely outdated). I am not sure though how often abandoned work really gets adopted (and how often said adoption leads to a release). So maybe a lot of work for nothing.

I don't think one is better than the other. As far as I understand it, but I haven't really dived into the materia, it's just two different approaches to calculating the shadows. Depending on your hardware and the specific mission one might gain you better performance than the other. But if you don't notice any difference both visually and performance wise, it doesn't play a role which one you've choosen anyway. So I would suggest: Forget about it

Three possible approaches come to mind: Make it adjustable. Maybe not a slider, as players shouldn't spend half an hour finetuning the animation. But if there would be two or three options to choose from, it may be a good start. I cannot make the animation raise higher, though, without a new animation. Make it depending on the current player illumination a.k.a. lightgem value. In dark areas rise the blackjack higher, in lit areas lower. A generally lower arm raising, so it is less distracting, but add the same time an acoustical hint that tells you the arm is raised, even if you cannot clearly see it. (As well as an acoustical hint for lowering the blackjack). Personally I guess I would be in favor of (3) probably, although I am not someone who would use the system at all, so I can life with all approaches. But I am all for the argument of making it as less intrusive as possible and not a big fan of unnecessary costumization, so (1) would be my last resort. I am open for suggestion, of course.

DarkmodPadbinds.cfg contains the bindings. You can compare it with the keybind file and an explanation is given here: https://wiki.thedarkmod.com/index.php?title=Bindings_and_User_Settings EDIT: You can also use JoyToKey to bind joypad input to keyboard bindings. It's a versatile program and may be easier than editing the config.

The current version of the fm contains neither of both models referenced above (font_medium and misc_junk_18), it contains misc_junk_X with X up to 17, though. The font model isn't referenced in the map file, but the junk model is exactly once, at the location pointed out by @Daft Mugi. // entity 6876 { "classname" "func_static" "name" "func_static_1098" "origin" "704.037 -464.909 -395.714" "rotation" "1 0 0 0 1 0 0 0 1" "model" "models/darkmod/props/misc_junk_18.lwo" "noclipmodel" "1" } My suggestion is therefore to replace the model with one of the 17 other junk models or to just delete the entity.

I haven't used it back in the day when I was still an active author, although I am pretty sure it's because I didn't knew of it back in the day. I've also never used layers, so that's probably not a good indicator. I could see it beeing useful if one is either working close to a reference as Dragofer mentioned or if one simply adopts its working style to it (for example creating a sketch first, maybe even in real, as some, myself included, may find it easier than an image program, and then use a scan or image of it as reference). Instead of removing it would be a notification in DR, stating it isn't maintained anymore, be an option in case not many are using it?

WARNING:Couldn't load model: 'models/darkmod/waterworks/font_medium.lwo' (nor the fallback to ASE) WARNING:Couldn't load model: 'models/darkmod/waterworks/font_medium.lwo' (nor the fallback to ASE) WARNING:Couldn't load model: 'models/darkmod/props/misc_junk_18.lwo' (nor the fallback to ASE) WARNING:Couldn't load model: 'models/darkmod/props/misc_junk_18.lwo' (nor the fallback to ASE) I would assume these are causing the issues, most propably the first one, as the junk is probably easy to overlook. Besides that it appears that a ton of the assets shipped with the mission are in the meantime part of the core mod causing tons of warnings to spam the console. So it may be worthwhile considering an update either way.

Due to it beeing mainly used in indoor areas probably I guess it isn't such an issue if the poly count is a bit higher. The engine is generally not bad in handling high ones. It would be an option to create several versions differing in poly count, so it can be setup as LOD entity. This way you would get best of both worlds, but for the price of some extra work (I am no modeler, so I dunno how much extra work exactly ). It's important to have a low poly shadow mesh, though. But I guess you are aware of that.

Just saw it is mentioned here: https://wiki.thedarkmod.com/index.php/Bindings_and_User_Settings its _impulse27

If the monsterclip does not go up to the ceiling (touching the blocking brush up above) it can happen, that the pathfinding algorithm will consider the top of said monsterbrush as reachable by the ai, and will therefore add it to the aas. This can indeed cause odd behaviour, although I am not sure that it would explain what you are seeing. Usually the ai just tries awkward things like walking on top of a shelve or jittering up and down. There is an impulse one can bind to a key to inspect the aas areas in game which is pretty useful for finding such spots. But I forgot which on it was. Grayman once posted it iirc. Another thing worthwhile trying is to insert additional pathnodes. Is the pathnodes are far away from each other there may be things influencing the pathfinding which you then easely overlook. That's just an assumption, though. Let's hope that Biker is lucky.

One thought regarding this. It would be nice to have a version without text (but with the logo). TDM allows adding text via decals, and by this mappers could give the safe their own branding. Indeed. The engine supports skins. The system simple replaces one material by another. It can't differentiate between two different geometry sets or meshes if they use the same material, though. (Something to consider if you want different pieces of the safe to use the same material, but would also like to allow it to use different one. Not sure whether this is desireable here.)

And a condump, please. The missing entity should be listed there.

I wouldn't expect orientation to play a role in regards to pathfinding. The ai needs to get from its current position to a suitable one to play the sid down animation, but the path has nothing to do with what direction the ai is currently looking at. My assumption was that there is either something in the surrounding conditions that has changed, or it is a numerical issue. @SeriousToniWhat mission are we talking about? If you can point me to the spot where it happens I may be able to take a look myself.

Sweat.

I bet you are (sorry, couldn't resist, some typos are just too cute)

Does it happen more frequently or earlier if the timescale value is set to a higher value? Any moveable that could potentially block the path?

You are welcome.

The file states, that the code you have altered is deprecated and therefore shouldn't be used anymore. You have to alter the above code (after uncommenting it). You may notice that the naming has slightly changed. I assume that this is due to the gui refactoring @stgatilov worked on. EDIT: Try this mainmenu_custom_defs.gui

There is a script object to alter the objective state setObjectiveState(1, OBJ_COMPLETE); setObjectiveState(2, OBJ_COMPLETE); : : : If you do this for all the objectives (so until the number corresponding to the amount of objectives you have) the mission should end. There may also be a console command to finish the mission, but I am not certain about that. Regarding the outro: Are there any hints in the console that may give a clue on what is going on?