All Activity

Sure, let me know what and when.

I am just happy it wasn't that breaking bug! Hopefully the rest of your playthrough goes smoothly.

Less than a day left. I just wanted you all to know.. Good Luck to you, We are All counting on You!

Strange. Just restarted the game and loaded from my last save and... they work now! Perhaps restarting was the answer all along. I probably should've tested that before running to the forums - sorry about that!

Huh that is quite interesting as it doesn't sound like the issue reported above actually. When you use the "use inv. item" key on the glasses do they flash green or red?

Order I got them in: I can drop one pair of the glasses and pick it back up, but if I try dropping both, the second pair just vanishes. They didn't work as a single pair or when I had both. No crashes, though! I'm partway through Seeking Lady Leicester right now but I'll try restarting the mission when I'm done.

Yes: Unfortunately I haven't been able to find the conditions to replicate this, so I am not entirely sure how to fix it. I know that's not very good news. They are not required to complete the mission, but it would likely require a mission restart to get them to work again. Can you tell me:

Hello! First off, I'd like to say fantastic work on this. Like other people here though, the peculiar lenses don't seem to work for me. Otherwise, I'm having a great time exploring. I do like that you don't start out with the basics.

Yeah, I agree, it probably would be a good new-feature request for the bugtracker, and likely not too hard to implement. I wouldn't mind having "side by side" tracking too (one or two more spawnargs), but that's no doubt a bigger bite, and has complications like passing through doors.

You CAN deactivate it though - see other posts in this thread about it.

That's exactly what I meant I didn't find a switch around the gas trap. To deactivate. All good

If you mean:

Sorry the translated one makes mistakes Everything ok Only in a secret room with the gas Doesn't the switch also go with the rune

Thanks for playing! I'm not sure what you mean by the following though: "Only the secret chamber works well." "With the rune stone works from the inside" "The switch didn't come out though"

with raytracing and AI becomming more prevalent things look dire for the old card users unless ofc. they dont give a damn and only play older titles . truth be told a fully (true) raytraced engine would murder even the greatest gfx card out there thats why we dont see stuff like that and probably newer will (luckily). thats not to say it wont become hurtfull for those who still use pre RTX and FSR cards, tbh even some gen 1 and 2 of those struggle with titles like alan wake 2 and the latest cyberpunk titles if settings are turned up above low. some bandaids like the DLSS to FSR3 framegen mod allows owners of previous nvidia RTX cards to push the envelope a bit so that for example alan wake 2 runs at <> 60 fps but you better have a top card like the 2080 ti to even attempt 4k in said title. the rtx 3070 also runs it pretty well but in 4k the latency becomes noticeable because it lacks vram. theres a paid mod that also allows framegen for pre RTX cards like the 1080 ti but with alan wake 2 i would not recommend playing above 1080/1440 resolutions if you intend to keep it at playable fps. even the 2080 ti is gimped when the detail levels go into omg... land but it atleast handles it with some grace with semi good detail settings (yeah i have all 3 cards mentioned).

I can confirm this, but it's a game issue not a DarkRadiant issue. Actually it's both a game issue and a DarkRadiant issue — DR renders the same thing (presumably because it's using shaders ported from the game code). Vertex blending simply doesn't work with bump maps. One of the bump maps gets applied across the whole model, ignoring the vertex blend. This used to work fine in vanilla D3 but I assume it got broken by one of the many shader changes in TDM. Example material: textures/test/red_blue_vcol { { blend diffusemap map textures/test/flatred vertexColor } { blend bumpmap map textures/test/spheres_local vertexColor } { blend diffusemap map textures/test/flatblue inverseVertexColor } { blend bumpmap map textures/test/square_pyramids_local inverseVertexColor } } Result: Notice how only the "square pyramids" normal map is appearing. The "spheres" normal map is not visible at all, although the diffuse maps (which are solid red and blue) are being blended correctly. It seems that the last normal map completely replaces everything else.

Would you be able to send me a save game file where you know this is happening?

I haven't tried with the fireplace lever, but I have tried leaving and re-entering the jewelry shop (with various combinations of leaving the doors open, closing the doors, locking and unlocking the doors) but for me the cases remain unfrobbable.

Congrats on the release Thanks for the great mission. I played through the mission... everything has Only the secret chamber works well. With the rune stone works from the inside The switch didn't come out though 1000 and 1 thanks for 1000 and 1 night

Yes, I'm asking because I'd like to know that too

I would like to know in what cases this could be useful, considering how (I think) limited briefings/debriefings currently are. But maybe you don't know either.

I have read somewhere that it's good to implement small changes in the floor-height, so the level feels less boring when walking around. I don't have a good example, but maybe others can.

Well could be useful to have spawnargs for this?

The remaining questions from my side: Do we need the ability to override cvars during briefings/debriefings/menus? Do we need sys.unsetcvar script event which works like unsetm console command?

There are two ways to override cvars in a mission: mission.cfg file can set non-archived cvars (starting with 2.12). sys.setcvar in game script can override cvars (starting with 2.13 / dev17044-10746). Of course, there has never been any effort to classify cvars into public and private, no thinking of backwards compatibility of relying on cvars, etc. So overriding cvars should be considered a last resort feature. mission.cfg allows to statically override cvars on FM level. The change takes effect during all missions in a campaign and all briefings/debriefings/menus. However, you cannot adjust cvar value during gameplay, so only one constant literal value can be set. The implementation is simple: mission.cfg file is executed from your mission when TDM engine starts all non-archived cvars are reset to their defaults when TDM engine restarts (due to FM change) sys.setcvar allows to override cvars on gameplay level. These overrides behave like the variables in game scripts, i.e. they are saved/restored to savefile and reset on game start/end. You can adjust the same cvar several times with different values, and savefile will capture the override that is currently active. The minor downside is that these overrides automatically don't carry over between missions in campaign, and they cannot work in briefings/debriefings/menus. Note that sys.setcvar has been available for a long time already, but previously it had different meaning. Previously it set the cvar as if the player set it himself. So the values stuck between restarts, missions, FMs (even saved to darkmod.cfg for archived cvar). Now it always sets the "mission override" for cvar. You can test cvar mission overrides manually using two new console commands: setm {cvarname} {newvalue} --- set mission override for the cvar with given value unsetm {cvarname} --- drop mission override for the cvar It is not perfectly obvious what should happen if mission-overridden cvar is changed by user. Right now the main value of cvar is changed and mission override is broken/erased in this case. So be wary that user can mess with your overrides just like you can mess with his cvars.