MirceaKitsune

Thank you for clarifying. Are there any known tricks or workarounds in the meantime? It would be nice if for the time being a quick patch were be possible, but I don't know the code so if it takes time to find any solution I understand. I'll follow that bug as well to stay up to date with this.

I have a few ambiental sounds for wind, but they never sounded loud for me. The map needs a new update though (when I get around to it) since performance remains an issue.

There seems to be a limitation regarding controllers (2.09 release, Linux / X11). The engine appears to not detect special mouse keys: In the Settings - Controls menu, I cannot map actions to some mouse buttons, they aren't being sensed at all. Tilting the mouse wheel sideways seems to register (as "mouse4" and "mouse5") but the forward and backward navigation keys do not. I noticed this a while ago but I don't need those buttons. However I'm trying to introduce the game to someone close: He needs to use a mouse with special buttons for gaming due to medical reasons. If non-standard mouse

I simply use sys.setPersistentArg / sys.getPersistentFloat instead of $player1.setKey / $player1.getFloatKey for the augmentation levels. I can only confirm it sticks in savegames, haven't tested actual campaigns: If there's an issue with persistence between campaign levels, that sounds like a bug in core and will need to be fixed.

Version 3.0 is here! It includes the latest changes and fixes... including persistent floats so augmentations stick throughout campaign levels, and of course the items used to install the augmentations. As it exceeds the file size for forum attachments, you can download it from one of those links: Mirror 1 Mirror 2 Only problem is that you'll get no augmentations on existing maps, they don't contain the items placed in the world. I'm planning to fix this in the next version which shall be the final major update. I'll be introducing a cvar or worldspawn arg, which will make those it

Finished the item inventory icon, custom sounds, particle definitions. Code and item wise everything is almost ready. Only change left in the code is ensuring that augmentations will persist between campaign levels; The campaign documentation says I simply need to use setPersistantArg / getPersistantFloat which I can simply replace my $player1.setKey() / $player1.getFloatKey() with. Only one question: Should I be doing this for limb health as well? That only makes sense if normal player health is persisted between levels, which I didn't check and don't have a test case handy fo

Slowly getting there. I want to clear up two concerns I have left before posting the next version: Help with answers would be greatly appreciated. First of all I want to ask which of two implementations is better: Running the code directly, or making it part of an invisible entity which I spawn at map start? At the moment everything is handled by a detached function called by tdm_user_addons.script / user_addon_init() which directly launches a while(1) loop that calls function. I noticed however that TDM likes to work with entities for in-game functionality: Would it be more ideal to pack

Pretty good one! Small and cozy, but with a lot of detail and story crammed in. Haven't found any bugs that I can report. It will definitely be interesting to see more FM's you make after this.

I need to play again to confirm with 100% certainty, but I think I've also been seeing this one. It didn't draw my attention enough to report it... it just clicked with me now after seeing it mentioned here.

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);