MirceaKitsune

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

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.

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?

A separate suggestion, I noticed this while doing the above tests: Please add r_shadowMapSize as an option to the menu, under the advanced shadow settings ideally just after the shadow softness / quality sliders (that's the sample count). This option implies a huge "good visuals" versus "bad performance" ratio and should be accessible for users to customize. Allow it to have at least the values 512, 1024, and 2048... possibly 256 for people with really poor hardware, and / or 4096 for folks with a powerful graphics card that want maximum sharpness. 1024 is a good default to stick to from what

Just wanted to report that I use all 3 of those cvars since switching to the beta. The first two improve performance without any noticeable visual differences or undesired side effects. The third (r_shadowMapCullFront) is the only one that introduces minor visual inconsistencies... more specifically causing shadows or AO to be culled close to an object. Here's a comparison screenshot without then with this cvar: Reminder: I use the vanilla AMD drivers (amdgpu + Mesa) on Linux (openSUSE Tumbleweed). It's often the AMD Linux drivers that have weird issues, so if it works for me it's r

This is honestly among my top favorite FM's of all time. Replayed it for a second time and it was nice to see it again! Very nice and well thought out, well detailed with a lot of content crammed into a relatively small map. I wanted to report an issue I just now encountered in case it can still be patched up: