[[ 2.10 ] New Frob Shader]

11 hours ago, nbohr1more said:

I was expecting a furious debate about color.

I'll start one. I like "spooky blue-ish glow":

 

 

 

This is actually kind of cool looking! I don't see it working out as a default color though; I for one support something closer to white, but still bluish if possible... haven't seen a screenshot of that yet for comparison.

[[ 2.10 ] New Frob Shader]

1 hour ago, kingsal said:

Mine is a slight blue tint at 0.67 0.55 0.6 . Your value is more green than anything with a green value of 0.8

We've discussed having it based on entity type, but its not the focus at the moment.

Fair enough. Out of curiosity, how does it compare with a more standard blue? Could you share with something like 0.4 0.5 0.6? That looks good too and I don't mind either way, feels pleasant and at the right brightness.

[[ 2.10 ] New Frob Shader]

16 minutes ago, kingsal said:

Btw these are the settings I purposed for the outer glow if anyone is interested. Its fairly subtle.

However, this is using the old frob highlight. 

    r_frobOutlineColorA = ".8" (could be controlled in settings to players liking)
    r_frobOutlineColorB = "0.67"
    r_frobOutlineColorG = "0.55"
    r_frobOutlineColorR = "0.6"

+1 to making the transparency a menu setting. As for the color I'm not sure about that default: I believe it should be pure white, or if anything a slightly blue tint (eg: RGB 0.6 0.8 1.0).

I wonder though if maybe the color should depend on the type of entity being frobbed. Like green for doors, gold for loot, blue for in-world decorations you can move around, etc. Obviously as a spawnarg on the definitions of items, root defs can customize it then so every derivative can inherit it without leaving existing FM's out.

[We have lost a member of the TDM development team]

8 minutes ago, Zerg Rush said:

I find this a wise decision, although I think it does not exclude a mission in his honor, as grayman has also done with Sir Taffsalots sword, another member who died some time ago. Mission that by the way, I played yesterday.

Oh wow, he died too? I think I briefly saw or heard about Sir Taffsalot years ago, though it was around when I first found TDM in 2014 I believe. And I actually played that FM too, the name at least I surely remember... now I understand what it was about. Hopefully it's not weird but I'd like to imagine they met where they went, and among other things discussed TDM and what they created with it while on this Earth... maybe that they'll even know where it goes from here on.

But yeah: Definitely make at least one FM in his name. Something great and of quality, definitely well deserved

[Mapping and Version Control]

If we want something that's easy to use for mappers and encourages them to actually use the feature, please consider my idea to create an actual Git plugin for Darkradiant, and let me know what you think about it since I'm quite curious myself. Unlike my idea for realtime editing it's actually not something that radical to implement.

I'd basically go for a set of menu entries and toolbar buttons that automate the appropriate Git commands required to work with a map, a customized GUI for Git if you will. Obviously the OS needs to have Git installed else DR would issue unrecognized commands to the system... on Linux this is a given, not sure about Windows users. It operates on the idea that the current FM directory is a Git repository, while being able to turn it into one upon use if not. The only features and commands it's really going to need are:

• Clone: Runs "git clone". Only needed if your FM isn't already a repository; This asks you for a Git URL and turns the FM directory into that repo.
• Pull: Runs "git pull". The repository thus map file are updated from the network, map is automatically reloaded when ready. This may erase local edits or throw an error if the remote map is newer: I understand the commands needed to merge against local changes are "git stash; git pull; git stash pop" (source 1, source 2). If changes were made to the same brushes or entities there will be a conflict: We'll need a prompt that lets you pick which version to keep, ideally with realtime previews later on so you can see how items change in the viewport (local versus remote versions) then have the option to make your choice per group. Same for other text data such as defs or script files, there should be a diff previewer that makes it easy to pick which def / function / paragraph to keep in cases of conflict.
• Push: Runs "git push". Uploads new commits to the remote repository. This should be pretty straightforward, the plugin only needs to support an additional menu asking for the username and password of the Git repository if they aren't set up in the config.
• Commit: Runs "git commit -m Message". Records saved changes you made to the map, a window lets you write a commit message describing those changes. The menu should also list every file in the FM directory so you can add or remove map assets as you work with textures / sounds / scripts / etc... if that's too complicated it can automatically add all new files and delete ones that were removed, but only in subdirectories that hold valid map content (eg: "myfm/def").
• Log: Runs "git log". Generates a simple commit list in which you may browse through all commits... no need to even account for origins and branches, a linear list of commits from the current branch should suffice for our purpose, long as they're listed in a readable format like short log + author + date. Double-clicking on a commit should prompt you to revert the repository / map to it locally in case you need to go back to an older version.

That should pretty much be it! Support for more Git options like branches could be added later but beyond this anything else can be optional. Needless to say mappers who want more features can use Git commands and other GUI Git tools on the FM repository separately: This is just to make it easy to do simple actions directly from DR... it also comes with perks that can be added later such as realtime previews of differences between commits, or a timer to automatically pull every X minutes so the mapper can be notified when there's a remote update and can click a button to reload the map with the new changes. The nice part is we can start with simple basics then expand with more features as needed.

[Mapping and Version Control]

How amazing we'd both write about almost the same thing at almost the same time last night As my thread about full realtime / multiplayer editing is its separate idea, I'll simply quote my post on the matter of non-realtime collaborative editing over Git / SVN and the challenges I see with this idea.

9 minutes ago, MirceaKitsune said:

The biggest issue is that the moment two or more creators edit the same item, there would be a conflict once the changes are faced with each other and have to be reconciled. We could teach DR how to resolve map conflicts and pick one set of changes, but this means one author's version would be chosen while others have to lose their work. The problem doesn't even end there: Some changes can be reconciled in theory but still lead to inconsistencies in practice! Say one author moves the walls of a building while another handles its furniture entities; DR can agree on which set of changes to keep for each of those movements and everything would seem resolved to the code, however if they aren't made or solved together you're left with an empty house in one place and floating furniture in the other, which a person has to later notice and manually resolve.

There may be ways to reduce this risk. One is attributing specific groups of brushes and entities to different creators: Only the person who spawned an item may edit it, no changes to other people's stuff allowed. This way anyone can push map changes to a Git repository at any point regardless of what other developers may have done during that time, the differences can be merged under any circumstance as no conflicts can occur. But it's a limiting approach since you can't help another mapper with their part of the map, while on the other side they can build over what you're doing and you couldn't get their stuff out of the way.

A good way to take this approach would be allowing maps to be stored in multiple files during development, so changes don't need to be made to the same file altogether. This means that alongside the main myfm.map you can have myfm.bob.map + myfm.mike.map + myfm.alice.map and so on, when loading the main map content is also loaded from those additional files: Now you can push and pull the git repo at your own leisure, your work is always up to date locally while changes made by others become visible whenever you do an update and reload the map! This alone is unlikely to be noticed or used by many creators though, unless encouraged by additional Git tools in the interface; DR could support pushing and pulling changes directly from the toolbar, with an option to automatically update other authors files at an interval (say 5 minutes by default) then refresh the map seamlessly.

While this would all be fun and easier for starters, the holy grail would be realtime editing at the end of the day. That way anyone can work on anything and always see the updated result on their end during all stages... without having to fear emerging conflicts that need to be reconciled later, unless someone's connection goes down and they make changes during that time which should probably be disallowed by the code. If designed properly we could have a powerful and unique system to work with here.

 

[Idea: Collaborative online editing with realtime map synchronization]

Going to look at the other thread as well, thanks for sharing. Letting DR save and load maps over Git / SVN would be a simpler version of this idea, perhaps even a precursor to it. But it does come with issues: Multiple mappers can't easily work on the same FM at the same time! Here's a more in depth analysis on how I see that working out:

The biggest issue is that the moment two or more creators edit the same item, there would be a conflict once the changes are faced with each other and have to be reconciled. We could teach DR how to resolve map conflicts and pick one set of changes, but this means one author's version would be chosen while others have to lose their work. The problem doesn't even end there: Some changes can be reconciled in theory but still lead to inconsistencies in practice! Say one author moves the walls of a building while another handles its furniture entities; DR can agree on which set of changes to keep for each of those movements and everything would seem resolved to the code, however if they aren't made or solved together you're left with an empty house in one place and floating furniture in the other, which a person has to later notice and manually resolve.

There may be ways to reduce this risk. One is attributing specific groups of brushes and entities to different creators: Only the person who spawned an item may edit it, no changes to other people's stuff allowed. This way anyone can push map changes to a Git repository at any point regardless of what other developers may have done during that time, the differences can be merged under any circumstance as no conflicts can occur. But it's a limiting approach since you can't help another mapper with their part of the map, while on the other side they can build over what you're doing and you couldn't get their stuff out of the way.

A good way to take this approach would be allowing maps to be stored in multiple files during development, so changes don't need to be made to the same file altogether. This means that alongside the main myfm.map you can have myfm.bob.map + myfm.mike.map + myfm.alice.map and so on, when loading the main map content is also loaded from those additional files: Now you can push and pull the git repo at your own leisure, your work is always up to date locally while changes made by others become visible whenever you do an update and reload the map! This alone is unlikely to be noticed or used by many creators though, unless encouraged by additional Git tools in the interface; DR could support pushing and pulling changes directly from the toolbar, with an option to automatically update other authors files at an interval (say 5 minutes by default) then refresh the map seamlessly.

While this would all be fun and easier for starters, the holy grail would be realtime editing at the end of the day. That way anyone can work on anything and always see the updated result on their end during all stages... without having to fear emerging conflicts that need to be reconciled later, unless someone's connection goes down and they make changes during that time which should probably be disallowed by the code. If designed properly we could have a powerful and unique system to work with here.

[We have lost a member of the TDM development team]

Regarding the FM series he was working on, this is my take on it: I definitely feel the nicest route would be continuing them rather than leaving them abandoned. Ideally by those creators who knew him and the stories well enough, thus know what he'd most likely make of them and the direction he'd want them to continue in. At least the existing / unfinished FM's for sure, but why not new episodes too if someone familiar could assume the series and become their new owner to develop them?

Here's an extra idea if I may: In the next original episode, if anyone decides to produce one, add a memory of him in the world as a main plot point... like making him a character in the FM or something nice like that. There are many creators with inspiration here so I'm sure something remarkable could come out of such an initiative! This can be made into a moment of creating something nice that wouldn't have happened otherwise rather than letting it be just a moment of sadness, if that makes sense. Hope this thought helps.

[Idea: Collaborative online editing with realtime map synchronization]

This isn't a feature I personally plan on using as I like to work alone. However I wanted to bring this up as I believe it would help with mission creation and more FM's being developed faster, particularly for people working on FM's in teams rather than alone. I'm imagining a relatively simple system, albeit it may require bigger code changes.

Think of it as multiplayer with a server list but for the map editor: DR instances would have the ability to connect to other DR instances (or different server software) over the internet. Upon connecting the map in cause is cloned locally and loaded. The maps are synced between actively connected instances and any change made on any of the connected DR's is mirrored to the others in realtime, with the local map file being updated on each end as this happens. When an user selects or moves a brush or entity on one instance, it's highlighted and repositioned on all others as fast as the network allows... if done right a DR user should see map components moving on their own in the viewports as they would if being dragged by the local user.

I'm imagining that such an ability could bring FM creation to a new level; Creators of a FM can connect to a central server storing that FM, ideally up for connectivity 24/7... each author can then make changes whenever they feel like working on a given part of the map, with everyone else seeing those changes in realtime (if connected) or when they connect to the project later. We could have larger and more complex FM's as a result! What do you think, and would this be possible without too much development effort?

Trivia: This idea was inspired by the map editor in the Cube / Tesseract engine which is what the popular FPS Red Eclipse uses. It's not just integrated in-game requiring no separate editor at all, but people can start an ordinary multiplayer match to create a map instead of playing Deathmatch. This got me thinking about the possibilities of realtime collaborative map editing, especially for something more complex as TDM FM's where this could accelerate things quite a bit.

[We have lost a member of the TDM development team]

This is something I did not expect. I didn't know him personally but saw him often here on the forum. He made some wonderful things that will live on. RIP.

[ATTN ALL, question about Dark Radiant & professional use]

This is an interesting initiative, I'll want to see how it goes. Wishing you the best of luck!

TDM and DarkRadiant are very modern tools... at least by FOSS standards, some code is technically +15 years old but that doesn't stop the end result from being as good as if it was made yesterday If it doesn't work out, I'd recommend taking a look at Tesseract (the engine Red Eclipse also uses) which supports modern graphics with the added benefit of having an in-game map editor and even allowing players to create maps in multiplayer!

I also have a dream to create an immersive game, which would contain elements from multiple games overall (FPS weapons, stealth mechanics, RPG leveling system, worlds generated in Minecraft voxels). Planning to use Godot for this one, but alas it's not something I'm ready to get myself busy with yet.

[Linux testers needed: new window management and input handling]

2 hours ago, cabalistic said:

We link statically to a GLFW binary shipped with the TDM source. So depending on whether that one's X11 or Wayland would determine which system the resulting TDM binary would support. Linking to both is not possible.

I wonder if the installer could offer an option for which platform to use then. The starting page has several options under Advanced Settings, there could be one new checkbox for "Use Wayland" in the Linux version.

Just a thought for the future... if it's too complicated it isn't an emergency in my book; We should be able to run TDM on Wayland as is, except apps without native support have to go through a fake X11 session which is slower and not ideal especially for high-end games that can use the performance benefit.

[Linux testers needed: new window management and input handling]

6 hours ago, cabalistic said:

The prebuilt executables almost certainly won't. My understanding is you have to compile GLFW for Wayland, so you'd have to compile a custom TDM version with a Wayland-compatible GLFW build. I make no guarantees, though.

I see. I was hoping it's a builtin feature of GLFW, detecting whether it's X11 or Wayland and launching appropriately in each environment. You'd still require one engine binary though right... as in the same thedarkmod.x64 would know to operate on both renderers, you wouldn't need two separate thedarkmod_x11.x64 / thedarkmod_wayland.x64 engines? If it only requires a Wayland enabled GLFW build I hope it wouldn't be difficult to compile the official engine against one.

On my Linux distro (Manjaro) I see a package for glfw-x11 and one for glfw-wayland, both are offered officially. However you can only install one at a time, the packages are marked as conflicting each other. Hopefully they aren't required at runtime in this case, but as a dev you may need to link to each GLFW separately when building.

[Linux testers needed: new window management and input handling]

I'm still curious about a little detail if anyone happens to know the answer: Does the new window management and input system support Wayland natively... by which I mean using the pipeline without having to go through X11? I'm re-asking because I hear KDE Plasma 5.22 (coming next month) should fix all the final issues I was personally running into and kept me on X11, thus a switch may be on the table again.

[[ 2.10 ] New Frob Shader]

Just wanted to say I'm looking forward to seeing this lovely effect! The frob outline is definitely going to modernize TDM visually. I'm in favor of mixing it with the old method by default, the new and old highlight should work great together.

In the past I've also been confused whether I was frobbing an object or not... albeit the brightening is usually consistent and fairly obvious, there are rare occasions when you can't tell if the item was bright already. This will make it easier to understand what you're pointing at and less risky to use the wrong thing when two objects are close and you can accidentally click on either.

[Linux testers needed: new window management and input handling]

2 hours ago, Araneidae said:

Can't straightaway say I'm a huge fan of the new bright outline around frobbable objects instead of the older highlight mechanism which seems a little more subtle; can I switch between how frobbability is shown?

Big fan of the idea here, can't wait to try it out in the latest build It's good that there are cvars to tweak those effects though, some users may not like the new changes; I'd put the customized cvars mentioned above in autoexec.cfg to not lose them... that's what I did with the color correction cvars to make my own environment config.

[Linux testers needed: new window management and input handling]

Does the latest dev build available in the installer include this now? Or will the next one have it at least? Haven't fully understood if it's still experimental or made it in master.

[Linux testers needed: new window management and input handling]

As far as testing goes: I haven't tried compiling the engine from SVN for a while though I remember it worked relatively recently. Any thoughts on when the first TDM 2.10 beta is going to be released? I figure that's likely months away though so I may try the latest master engine if I can.

[Linux testers needed: new window management and input handling]

49 minutes ago, cabalistic said:

No performance improvements - why would you expect them from this change?

I have no idea about the state of Wayland support in GLFW currently, or what other parts of TDM still depend on X indirectly. I haven't tested it, but would not get my hopes up.

Alright. And that's because I imagined the method used to draw the window could have a minor impact on paint update latency thus on perceived performance, even if this obviously doesn't affect the work the renderer has to do before the drawing stage of each frame.

[Linux testers needed: new window management and input handling]

Yet another great improvement I'm delighted to hear about! Was directed here from the extra mouse buttons bug since I understand this should guarantee at least 8 mice buttons will work in the input selection. Though I'm intrigued by many questions upon seeing this. The first being if we should see any performance improvement and how much! Also does it mean there will be native Wayland support when using a WL desktop session instead of X11?

[Extra mouse buttons can't be mapped as controls]

13 minutes ago, cabalistic said:

It's a known limitation due to awful input handling on Linux: https://bugs.thedarkmod.com/view.php?id=5208

That whole input code needs a full rewrite, so I can't make any promises on a speedy resolution.

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.

[Fan Mission: Scroll of Remembrance, by MirceaKitsune (03/11/2020)]

21 minutes ago, Gerberox said:

I tried to play this mission but the base game noises are so loud I barely hear game noises like speach, closing doors or footsteps if they exist.

I set SFX volume to the minimum (!) and every other sound settings are on max.

 

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.

[Extra mouse buttons can't be mapped as controls]

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.

[Script: Per limb damage, skill system (WIP)]

1 hour ago, Dragofer said:

Nice work - I'm in particular curious how you were able to get persistant args to work, since I recently heard of them not working.

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.

[Script: Per limb damage, skill system (WIP)]

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.