MirceaKitsune

How do I obtain that log? TDM doesn't generate it in the location suggested last time on Linux, there is no OpenALlog.txt or OpenAL.txt. Edit 1: Sorry I see the variables I must use for it described there. I'll try to reproduce and post a log. Edit 2: Posted the log from a run with the issue triggered, with a description encompassing what I said in this thread.

I just remembered an audio bug I experienced which seems to affect some Linux users. There's an opportunity to fix it in 2.09 which can be done by changing an OpenAL default. I posted a thread about it a while ago: Essentially we might want to default "period_size = 64" or something that's under 256. A higher OpenAL period size can cause lag when the game starts with sound only playing in interruptions, until a few seconds or minutes later when it finally stops. I don't know if lower end audio boards might have issues with a low value however so this should be investigated first.

Thanks. I'm still not seeing the conversation editor in latest Git master from today though, looked closely in all of the menus to be sure: Could I be missing something, or perhaps there's still a problem that keeps the plugin from being detected and appearing?

Not bad at all! Short but detailed, with a nice story in as well. Found only one bug... a cap is missing at the tip of a patch cylinder for some spiral stairs.

Latest Git master fails to compile with a build error. Noticed while trying to test an issue I have a feedback on. [ 49%] Building CXX object radiantcore/CMakeFiles/radiantcore.dir/map/Map.cpp.o /home/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/radiantcore/map/Map.cpp: In member function ‘void map::Map::loadPrefabAt(const ArgumentList&)’: /home/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/radiantcore/map/Map.cpp:661:76: error: ‘GlobalGrid’ was not declared in this scope 661 | auto prefabCenter = accumulator.getBounds().getOrigin().getSnapped(GlobalGrid().getGridSize());

Finally figured out how to read the light value at an entity's location after some experimenting, as an alternative to accessing the lightgem value directly via a hacky getGuiFloat() call. You need to use the following function with the following parameters to get the proper results, as a roughly 0 to 1 range... where 0 is the player standing in complete darkness and 1 in maximum light: vector lts = $player1.getLightInPVS(1.0, 0.01); float lt = sys.vecLength(lts);

Done.

It's not perfect but one of the only models I could find that looks okay. It's a bit too modern for TDM I agree, though at the same time grimey enough to fit the existing generators and other devices. It's worth remembering that like other mods I'm thinking of doing, it will be defaulted in my cyberpunk conversion BUT also available as a plugin for FM's / players for vanilla TDM, thus I'm juggling to make it fit both setups somewhat. It can be changed later if a better one comes up... for now I also need to finish a few remaining tweaks for the next version.

https://opengameart.org/content/turbine-textured Silly me for not using this sooner. Looks 1000 times better than the silly pyramid I was struggling to make! It's also GPL compatible so I can integrate it into The Dark Module once I make this a default component for it. Only problem is the model is pretty high poly... I didn't want to ruin the original so I only decimated two LOD's instead, reduced shadow mesh included: FPS will drop if looking at too many of those items up close, but mappers shouldn't need to place more than 4 which can be viewed simultaneously which should be okay.

Huh, never knew that. In 2016 I would have thought only NASA may have 1000 Hz screens. Yeah ideally there can be no limitation, but I'm not sure to what extent the system can allow that... great work was done modernizing the engine though so it's hopefully not impossible.

Thought those bugs were fixed a while ago, hope that can be solved. If there should be a hard limit, I think that should be 1000 honestly: That would allow one frame per millisecond, which is where there may be a structural code limitation if going beyond. Also there will probably never be a monitor that runs at 1000 Hz in the history of the world, at least not for personal computers... the eye would not pick up on anything that fast anyway.

I think this looks slightly better and more interesting. Not sure if I can improve the item design any further. Might be better to try finding a model on OpenGameArt if not.

I looked at this cvar as well out of curiosity, noticed something suspicious: The value it gets set at for me is 512, however I have a video card with 8 GB of VRAM. Surely it could use at least 1024 if not 2048 / 4096 or the whole 8192! Could the default value of 0 (autodetect at startup) have issues with video RAM detection on Linux / amdgpu or even in general? Or is this normal and I'm just misunderstanding what it represents?

What a nice FM! Very happy to have gotten around to playing this. Easy in terms of enemies, hard in terms of figuring out what you need to do (I needed the instructions for half of things). I can't believe this is only your second FM... should make sure I checked out the first one in that case: I see lots of talented creators who get everything right from their earliest try! In terms of bugs I can't find much to report. It's mainly a few doors clipping through world geometry, very minor and nothing serious enough to be worth noting. I only found one issue that's worth bringing up...

Worked on the item implementation today. Going for a prism thingie that looks somewhat like a potion... the design feels okay overall, but I don't feel like also texturing it and so far I'm uncertain how well using a default metal texture for the frame looks like. Maybe someone has a good lwo they're willing to donate? Let me know if so. Functionality is done just needs polishing. The player no longer starts with any augmentations installed, picking up and using the items is now the only way to get augs.