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 keys can't be mapped, I'm afraid this is a game we won't be able to enjoy. For this reason I'd like to ask if others can confirm this limitation, and if so can the engine be patched to solve it please? Thank you.

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 items spawn as the player picks up loot and reaches a certain threshold; This way if the map doesn't indicate that it contains augmentation items, they'll appear in place of some loot items as a reward. It's not perfect but that feels like the only way to have them in existing FM's.

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 for; If you finish a campaign level with some damage, will you still be damaged in the next level, or do you always start the next map fully healed?

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 everything into an invisible entity instead, implement all functionality as a scriptobject for it, and just have user_addon_init spawn that entity on map start? Both methods should work fine at the end of the day, but I want to go the route that's better. And the second question: Are all images used in a GUI precached when its overlay is spawned, including ones that aren't active at that time but will be later set by an onNamedEvent changing the background of an element? I thought I saw a few hiccups during testing and wanted to make sure it's not due to unprecached GUI graphics.

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()); | ^~~~~~~~~~ make[2]: *** [radiantcore/CMakeFiles/radiantcore.dir/build.make:1577: radiantcore/CMakeFiles/radiantcore.dir/map/Map.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:785: radiantcore/CMakeFiles/radiantcore.dir/all] Error 2 make: *** [Makefile:149: all] Error 2

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... Otherwise I really... At that stage I expected something else to happen. It would have been really cool if it did, though it seems not:

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.

Latest Git master has a few new issues. First some maps will instantly crash DR when opened: This happens because of that map's map.darkradiant file, it goes away when the following line is manually deleted from it (the MapProperties section): KeyValue { "LastShaderClipboardMaterial" "textures/common/caulk" } Other than that the conversation editor option is gone from the menu: I looked closely and can no longer find it. Could something be making its plugin not compile on Linux?