Jump to content
The Dark Mod Forums

MirceaKitsune

Member
  • Content Count

    1058
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by MirceaKitsune

  1. 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);
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. 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...
  9. 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.
  10. 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?
  11. 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
  12. 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
  13. 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:
  14. Then a wizard with psychic powers he is
  15. Very nice FM overall. It's rarer to see proper outdoor FM's, with the right amount of detail and the geometry not looking fake, this definitely achieved that and felt very natural. Was going to mention the lightning performance and super low-res web texture, but you already clarified those in the first post. All I can offer is two small visual issues I encountered:
  16. I noticed the black transparency bug on another decal again, FM Sneak & Destroy. getViewPos included this time.
  17. Is it not something predefined? It seems unsafe to guess and use this way, if it might change in the future and then the mod would break and need to be edited to reflect a new handle. Overall it sounds like it might work, but is pretty hacky to use in this form. I'll think if to at least write down some suggestions in this regard.
  18. But custom scripts can't access it. That's because you need the overlay handle of the GUI element using that GUI float. I tried using the custom overlay specific to my mod, and unsurprisingly $player1.getGuiFloat(mygui, "gui::lightgem_val") always returns 0.
  19. Thanks, I'll keep that in mind. I think that if I open a new thread there, it will be after the next update: I want to add the last component (upgrade items) first and clean up anything that might still be obviously wrong. Hopefully it won't be too long till that point... just need to design a nice little lwo model for the items, then come up with a solution for vanilla FM's that won't have them thus I'll need to spawn those somehow.
  20. It took one heck of an amount of work, but it's finally been done: Functional skills / augmentations are now in principle implemented! The update contains the same player damage system but with limb based enhancements fully working as well Today I finally separated the individual HUD components for each aug and made the icons operational, which is enough to post a beta for version 2.0 of this plugin. I improved and replaced some of the icons at the last moment, making them more visible and better suited for the effects they represent. Remember this version is still mainly for
  21. A couple of bugs I found today. First of all I happened to replay the FM Special Delivery this time. This FM will crash and is unplayable with later TDM versions, if in the store at the start of the game you choose to buy the Speed Potion. It seems to be due to its scriptobject not being found... maybe it would be a good time to add the finished version of this potion to core? Second one, and I noticed this since the first 2.09 beta: The red and green glows when using items appear really sharp, as if in lower color resolution. Unfortunately I forgot to turn off the sharpen filter an
  22. I can definitely add to this. I ditched Windows 8 years ago, haven't had it on my system since... still can't believe how long I lived on it till finally making this choice. Indeed the only issue is some games being harder to play, especially newer ones as old ones typically work fine under WINE. I didn't notice it much as I rarely touch commercial games any more; Unlike free projects like TDM, which are made by the community and we can fully edit, I don't feel those truly belong to us rather that some company who makes boring stuff just so we give it our money. We must not forget that TD
  23. I replayed Snowed Inn last night, definitely one of my favorite FM's. I remembered it has quite a few improved assets: Better footstep sounds, loot sounds, and other improved and more realistic audio overrides. Also a better looking objectives screen with slightly higher resolution graphics. I really must ask: Unless there are licensing issues involved, is there a reason why we don't make those vanilla and replace the old ones? They're in the same style but better and more accurate! It could be a nice addition to the new 2.09 release
  24. I think it would be odd to expect mappers to compile code and distribute a dll with their map. On the other hand scripting is definitely something you can expect from most map builders: I tried to make a FM without any scripts, then ran into limitations so I looked up the basics and in a few minutes I easily wrote a script for what I needed. Thus I agree that more focus on scripting would be a good idea, it's very easy to learn / use as well as very powerful with the right abilities. And like I said there aren't that many missing features! There are mainly two clear limitations that come
×
×
  • Create New...