Jump to content
The Dark Mod Forums

MirceaKitsune

Member
  • Content Count

    1058
  • Joined

  • Last visited

  • Days Won

    9

Posts 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. 3 hours ago, Springheel said:

    That model doesn't really suit the TDM setting as it looks currently...it has wires and fairly modern looking pipes and logos on it.

    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.

    testing_2021-01-19_18_17_07.thumb.jpg.434f7bce2936354fafd487b94ba2d3bf.jpg

  4. 1 hour ago, AluminumHaste said:

    Dude, don't.

    We already have 360hz displays and nvidia showed off a 1700hz display back in 2016.

     

    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. 2 hours ago, nbohr1more said:

    The only thing I think we should do is set the max to 300.

    Physics gets out-of-hand above that:

    https://bugs.thedarkmod.com/view.php?id=5464

     

    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. 13 minutes ago, nbohr1more said:

    (Then) Try setting:

    sys_videoRam 2048

    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?

  7. 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...

    Spoiler

     

    The priest will often get stuck in front of this door, repeatedly opening and closing it only to go back and forth through it. I only caught him become unstuck once, beyond that he's been standing in that spot for the entirety of the FM. Toward the end he moved to the door in the opposite direction, where he didn't even go through any more just sit in front of the open door shaking. Perhaps an outdated dmap... if not maybe the engine doesn't like a little collision in the door.

    heartstmattis_2021-01-18_03_48_23.thumb.jpg.3cd9081f22d69bfdf79731dd5b5ae2d9.jpg

     

    Otherwise I really...

    Spoiler

    Loved the unexpected creepiness when you steal the heart and everything goes red and everyone becomes a skeleton. Must have taken a lot of work to script every single light and AI like that, even making the process reversible! That's the sort of thing I love to be surprised by in a FM :D

    At that stage I expected something else to happen. It would have been really cool if it did, though it seems not:

    Spoiler

    I thought Neimath was going to come back to life. That's because one of the readables said something about "after you cleanse the heart all souls will return to how they were at dawn". He looks like he was freshly killed however, possibly in the same day... I thus imagined the player revived him by stealing then cleansing the heart. That would have been EPIC when you think about it, plus another joyful thing the player could have been given the option of doing.

    At some point I thought I was right, when I saw an acolyte walk in an area I haven't seen him before. But when I went back to the underground crypt I could still see his dead body between the skeletons, so it was probably someone else.

     

  8. 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.

    testing_2021-01-18_01_30_53.thumb.jpg.ef417c4e47540c8618d525d59d7b60a8.jpg

    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.

  9. 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?

  10. 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 I'm seeing so I'd leave this unchanged.

    In my test just now, going from 2048 to 1024 granted me an additional 20 FPS, while 1024 to 512 offers yet another 20 FPS. The visual difference is also quickly noticeable however, with the shadow map becoming more square each step. I was at 2048 before noticing this and now went down to 1024 to enjoy better frame rates, even if the lower quality can be easily noticed on an 1080p screen.

  11. 50 minutes ago, nbohr1more said:

    Try:

    r_useNewBackend 1

    r_shadowMapSinglePass 1

    r_shadowMapCullFront 1

    In my experience, r_shadowMapSinglePass is the biggest performance factor and it is broken on the old backend.

    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:

    heartstmattis.thumb.jpg.4a2f2d967b27878623efa35a1a97ea76.jpg

    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 rather surprising that others are experiencing issues.

    35 minutes ago, Araneidae said:

    Those settings didn't work very well.  Am back to 6 fps and it looks horrible as well!

    At the moment I'm getting reasonable performance with high quality shadows, but with r_usePersistentMapping off.  Can post a complete .cfg if that's helpful.

    I'd do that. I also have r_usePersistentMapping enabled and everything else works well with it.

  12. 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:

    Spoiler

    If you frob the painting behind which the wall safe is hidden, you can open its door through the painting itself, even if you didn't use the button under the desk to lower the painting first. This should be easy to fix by putting a target_setfrobbable around the safe door and making the button trigger it on / off with the painting. Though the button should also close the safe door if it's open, so that the painting can't pull itself back over the already open door either... not sure how to do this as simply targeting the safe door would automatically open it when closed as well, perhaps disable the button while the safe door is open?

    reluctantbenefaction_2021-01-12_02_37_41.thumb.jpg.3b480eb650950e0d7157bffaa3a78c28.jpg

     

     

  13. 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:

    Spoiler

     

    The water floats above this beer jug. It might be hard to see in this screenshot as it's animated, but if you look closely you should notice the refraction in the air (look above the jug and along the table's edge).

    siegeshop_2021-01-10_02_22_45.thumb.jpg.1c1788c4a9b07b28db84775189ca0e15.jpg

     

    Spoiler

    The pipe floats in front of this guys face. It doesn't even move with his head, but most importantly it just hovers at a noticeable distance from it. I know the goal was to make it look like he's smoking, but unless permanently attached I don't think this can look well as is.

    siegeshop_2021-01-10_17_46_05.thumb.jpg.be4135af2da85ee9aefab2988c149492.jpg

     

     

  14. 1 hour ago, grayman said:

    The GUI number is something below 10.

    try 1, 2, 3, etc. until you find the one that works.

    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.

  15. 7 hours ago, Obsttorte said:

    The value of the lightgem is passed to the gui via the code. There is not much to improve here.

    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.

  16. 7 minutes ago, Dragofer said:

    Nice work - I think for testing you might like to go to the general TDM forum, since the editing section probably only attracts a subset of community members.

    Importantly, I think the .pk4 will have to be named such that it sorts alphabetically after tdm_base.pk4, i.e. prepend a z_.

    It'd possibly make the life of your testers easier if you provided an alternative download where all upgrades start at 0, and provide a list of cvars that the player can enter into the console to upgrade individual skills. People might like to try them one at a time, rather than a potentially overwhelming 16 at once, especially when it comes to troubleshooting.

    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.

  17. 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 :D

    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.

    hud.jpg.e4d93402c56a1406243e6b2efd2af7d4.jpg

    Remember this version is still mainly for testing purposes! The skills are yet to be tested in a real FM, and most importantly there's no upgrade items implemented yet: The player will currently start out with all augmentations automatically upgraded to level 4, the next (and final) step is adding upgrade items to slowly gain them during a FM.

    Here's the latest pk4. Delete any previous version, then as usual simply drop this into your TDM folder which should automatically enable all the functionality in any FM. Testing would be appreciated; There are things I may not be able to change due to limits in the scripting system, but if there's any annoyance I can fix I shall look at it in the next update.

    player_2.0.pk4

    • Like 1
    • Thanks 1
  18. 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?

    Screenshot_20210105_045257.thumb.png.15452530b2b3e5f983e20406f230cd2d.png

    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 and see if that's causing it.

    1.png.65b24b1fd19d3edb5f184e1eb8bf600e.png2.png.d49ddd039bd4da9a42ff393926a3f1ce.png
    Lastly I recently replayed Snowed Inn as mentioned above. Saw a little peculiarity which might be an alpha drawing issue in the renderer: There's a certain drawing on a wooden wall in a part of the map. When shining the flashlight at it, the corners of the decal plane become black rather than staying transparent. This only happens if the flashlight is on and perhaps shining at the right angle, without it transparency works just fine. Might count as a FM spoiler so just in case.

    Spoiler

    snowed_inn_2021-01-04_03_15_30.thumb.jpg.f7b43023148edf0329d22bab860fe00d.jpg

     

     

    • Like 2
  19. 3 hours ago, Zerg Rush said:

    In another forum where I made it known, Linux users were delighted with TDM, because the offer of games for this OS is not exactly overwhelming, in this field Windows rules and OSS games are usually quite crappy, while TDM really is comparable in quality to many commercial games.

    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 TDM isn't just the only FOSS game of its genre: It's one of the only projects with AAA assets and graphics... albeit by 2010's standards, but in my book I would still call them that. Alongside it and Xonotic, most open-source games have pretty cheap assets and a lot of bugs unfortunately... TDM however has long achieved commercial quality, and for something remarkably complex in its core design and the features required.

    • Like 3
  20. 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 :)

  21. 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 to mind... more in total but these two stood out: The first is having no way to read the value of the lightgem, which is a big one and can hopefully be lifted easily by adding a $player1.getLightgem() hook (there's already one to set an offset for it). The other has to do with getting and setting the value of the breath, in case you want to modify the air as easily as you can health (there's allegedly an obscure way using the heal function which I might try if all else fails).

    Other hooks I could have used was the ability to force the player in crouch mode, or disable run so they're stuck walking and unable to run... I'd have really needed these two for my player damage mod. Also a way to change the volume of player (and why not AI) footsteps, so you can make the player more silent and harder to hear when walking around. Beyond these and a few others the script system offers most of what you need, just requires a few extra touches in my opinion.

×
×
  • Create New...