peter_spy

I'd be cautious about scripts too, because if there's an error in the script, you'll be thrown out of the map. But decls should be fine. Typically for errors in decls will just result in a console message, and e.g. model or material going black. You'd have to debug it the same way, when all steps are manual. IIRC, def files need both reloaddecls command and actual reloading the map, so there will be kind of two steps before a change is reloaded in TDM: saving a txt file and issuing a map yourMap command.

I'd go even further and do that as soon as the texture, model or declaration file is updated on the hdd. Unity works like that, and it's great. Right now testing materials means continuous alt tabbing and left hand pain.

What do you mean by that? Aligning textures on brushes? Otherwise, you don't need to dmap and reload the map, if you update texture images, models, or material declarations.

I wonder why moving around in game would be useful for moving camera in DR in the first place. I need to check how perspective view in DR looks in TDM because of the full rendering features. I don't need the DR camera to move with what I do in the game, so it can remain where it is in DR. When I switch back to DR, I'd expect the camera in TDM would jump to where DR camera is, and that's it. I probably wouldn't even need to switch to TDM and move around in game, because I could do the same in DR and spend most of my time there. Edit: I should have mentioned that I use 2 monitor setup, so I have DR on one monitor and TDM on the other - that's why spending 99 percent of the time in DR makes more sense to me.

If the workflow would be: a) launch a map in DR, b) launch the same map in TDM, c) press the sync button in DR, most users would probably assume that TDM should sync the camera with DR, and that it may always work in this direction. That would reduce the number of options further.

Wording is not an opposition then, and it doesn't describe the feature well. "Sync TDM with DR", "Sync DR with TDM" should be clear enough. That's still confusing. User doesn't have to be familiar with underlying implementation, hot reload is continuous sync of what's being done with the map in dr, right? So how 'one time hot reload' differs from save map and reload map in TDM, and how's that useful? All in all, the continuous update of a map and continuous camera sync is the main feature here, and that's what should be in the spotlight. Ideally, both features would be activated with one button. Not sure if users should be bothered with details such as which camera syncs with which. I guess there could be something like Show advanced settings checkbox with such granular options, but putting so much detailed options in one place creates a lot of informational noise.

I don't understand what loading /sending camera to the game would mean. Hot reload means the map in tdm is being synced with dr, right? So why not just a simple on off switch? Dmap is ok, although maybe slightly redundant, since mappers do that from console anyway.

Jesus, it's like 16 buttons or checkboxes to mess up with. Completely overwhelming for a new user.

I have a setup with mirror, visportal, and portal sky leading to a skybox, no issues either on 2.08 or latest 2.09. There's something wrong on your end. Either the mirror setup is wrong (check limitations), or the invisible asset is the issue (brush, model, or its material).

That's really weird. I understand that it made no sense to support all C++ data types, but I was taught that using floats when you can use ints is wasteful, memory and performance-wise.

Yup, now it works. Semicolon is typically used to mark an end of a statement in a method, that's why I find it weird to place it after a method name (it makes sense when a method calls another method in its body, as this is a statement). Another thing that caught my eye, when you're talking about types, you don't mention ints. Storing numeric values in floats makes sense if they need that kind of precision. So if you want to convert a boolean to a number, int would make more sense.

A somewhat random feedback: I tried to invoke a script by using console command, as described here: https://wiki.thedarkmod.com/index.php?title=A_to_Z_Scripting:_Ways_of_calling_a_script#From_the_console Either I did something wrong, or it doesn't work. Also not sure why would I want to use a semicolon at the end of a function name, in the console command.

It works only with the first setup, where the camera is an image source for the display. It doesn't work with target_null.

What can I say, I just know what I like

It feels a bit like skating, her running and walking feels more like gliding over surfaces. And when she runs into something, and you keep the directional key or pad pressed, she keeps running in place, so that does look silly As for the internal monologue, it would be much better IMO, if the protagonist didn't have to say things in her head, and then say it out loud to a character in dialogue. Yes, that's how it works in real life, more or less, but it doesn't mean it's interesting for the viewer (at least to me it's rather bland or annoying). I didn't get far yet, so I can't comment on the gameplay much (and I didn't in the previous post as well). It feels okay; again, kind of standard Remedy stuff, shooting guys with guns regardless of what paranormal force controls them (in Alan Wake it was black, here it's red and that's about it in terms of differences ). Maybe if I wasn't slightly familiar with the concept of the SCP Foundation, I'd want to come back to play it every evening, just to see where the story goes. Unfortunately, as a whole, it's just okay-ish to me. Great graphics and lighting; great sound design too, as you mentioned. But other aspects didn't grab me with anything in particular (yet?).

I've been looking into this as well, using this article: https://wiki.thedarkmod.com/index.php?title=Security_Camera Right now I'm interested in the last (most simple) example in particular. E.g. can I control the FOV of the image that is being sent to the display? It seems pretty wide by default.

I actually did get Control on Steam winter sale I don't have an RTX card, but the game still looks amazing with SSR and quality of lighting this high. I kind of have a problem with Remedy games, and it's present here too: graphics is their forte, but other parts seem to stand out, in a bad way. E.g. I didn't like writing in Alan Wake (IMO it's basically Stephen King wannabe internal monologues), and here the protagonist does it too. While the voice acting is pretty good, the writing is again somewhere between meh and facepalm. Animation seems to have taken a hit too; character movement feels like on roller skates, and facial animation looks quite stiff and artificial. None of that makes me put the game on the shelf yet, but it impacts my experience a bit.

@stgatilov Okay, just checked it on a model in 2.08, this is what I got: – You don't need a mirror global keyword, just mirrorRenderMap will do. – None of the image stage keywords work (resolution values, translate, scale, all of this is useless now). Correction: rgb (or red, green, blue separately) works. – Diffuse / normal / specular images have no effect – Other blending modes put after mirrorRenderMap will work – As you said, shape of a mirror can be complex, as long as it's flat. Any slightly concave or convex face will generate a HOM effect. Example code: In-game result:

Doom 3 used another blend stage with texture to simulate dirt and imperfection. That should be possible here too, right?

Will check that on a model. Btw. TDM example doesn't seem to use any numbers for resolution, as per iddevnet example. Isn't that wrong? Or the engine just uses screen resolution?

I think I tried that, but I got a black surface instead. It worked only when I switched to a brush. Also, I think we need a research (and then a tutorial) on how to use this technique properly, because there's not much info on it, neither on Modwiki, nor on TDM wiki. https://modwiki.dhewm3.org/Mirror_(Material_global_keyword) I got two material examples for mirrors, and they both differ quite a bit: D3 example only uses mirror as a global stage keyword, while TDM example has both global and image stage. While iddevnet description reads: Not sure whether that means it should be an either or situation? I don't plan any model with mirror reflection yet but maybe using just the image stage is an answer. And, isn't using mirror as both global and image stage in one material making double work for the render, so it produces glitches?

Great catch, and that's a proper regression. Such warning would be appreciated. IIRC, mirrors were never great back in Doom3 either, and they still need to be applied on brushes (not models).

Absolutely! The gameplay is actually great, and I was immediately hooked when I saw the art style, as it copies my childhood-favorite comic book artist (Mike Mignola). But I still find it fascinating how devs got the idea that this game should last for 80 hours. It's like having a vast world like Dark Souls, and then cutting all of its locations down to first 4, while tweaking the mechanics in such way that the time to beat the game remains unchanged. You could say that it somewhat fits the desperate tone of the game, but it felt like cheap shot to me.

Eeehh... While the art style and the game systems are neat, there's not enough content to justify the punishing RNG and excessive grind. IIRC the base game takes around 80 hours to complete, which is around 4 times (!) too much for what it offers.

Seconded. It's much more focused, puzzles are much less clunky or obscure, and the oppressive tone a la Half-Life 2 is really well done.