Skaruts

Sorry, I hadn't noticed your reply before. It's using Godot 4.4. (I think it should work fine with 4.4.1, too.)

That was a problem with hotkeys, though, not with the actual data saving. The hotkey itself (ctrl+s) wasn't working on Linux, for some reason. Thanks, anyway.

I think it's largely because the amount of work that it takes adds up with each mission that it involves, and it becomes way more than anyone alone can chew. Correct me if I'm wrong, but I think all existing campaigns were made by several people, so it requires people getting together and committing to it. I had some ideas on a set of about 6 missions that I wanted to turn into a full campaign, due to story continuity, but... at some point I realized that it's a tremendous undertaking. It took me a year to make a small, simple mission. At that pace it would take me 6 years to make that campaign, which is already way too long. With experience I might get things done quicker, but it's already taking me longer than a year to make each of the other missions I've been working on... the ETA on that campaign idea only keeps looking worse. I'm better off releasing each mission on its own and build a series of missions over time, like most people do. Finishing works keeps motivation up.

I agree with you from that perspective. But the companies don't see it that way, though. I stopped buying any game that contains DRM since around 2010, due to all the reasons why they're a problem to paying customers. Day one of Assassin's Creed II I was comfortably playing a pirated copy to see how I liked the game, while paying customers were all waiting for hours for Ubisoft to unclog their DRM servers. That was the moment I decided to never buy a DRM game again. Problem is, I've been pretty much alone in that. That's actually the real problem. Most people are ok with DRM.

On the contrary, it makes more sense in a singleplayer game. The point of DRM is to prevent piracy (especially during the first weeks of release). A singleplayer game doesn't have any inherent need to connect to any servers like a multiplayer game does, so the only way to authenticate the game is to add that in in the form of a DRM. A multiplayer game doesn't necessarily need a DRM. It can be authenticated as you connect to official servers or an official online store or something like that. The need for online authentication arrived when physical copies became obsolete, because they could no longer use the old annoying anti-piracy methods, all of which were also very weak, so they needed new annoying ones that couldn't be so easily bypassed. Singleplayer games always had some form of DRM. Except they used to be annoying to everyone, now they're only annoying to the paying customers. Although it's worth keeping in mind that stuff that was made 20 years ago or more, didn't use online DRMs. Many of them used CD/DVD copy protections, which never become obsolete. But they were all weaker anti-piracy methods.

What good would it do to know that a game will die in 2 years? That wouldn't fix the problem that the people that will still want to play it at that point, can't. Is a non-solution what the initiative is really asking for? And how is a company supposed to predict how long they'll support a game anyway? Games can flop and have to be shut down within a year or less. Regulations have to accommodate to cases like these, and you can rest assured companies will find ways to use this to their advantage.

I'm not sure what people are asking is feasible for companies to provide. For example, when it comes to DRM servers getting shut down, how are companies supposed to turn of DRM then? Those things are made to be really hard to remove, change or turn off, and many are made by 3rd party companies. People are asking companies to deactivate a thing they didn't make themselves, and which one of its core functions is specifically to resist deactivation as much as possible. And in some cases the DRM is intertwined with the game's systems, such that removing it will break the game. When it comes to online games, if the game only supports official servers, is it easy to add support for private servers in the end, and without introducing more bugs and regressions? I personally don't know, but my assumptions is that if it was easy, then people would often create unofficial patches to bypass official servers. My prediction is that these things will not go away until consumers stop buying games that include them. So maybe that means never, because a lot of people don't really care about it. There's always the possibility that we must come to terms with the fact that some games have a finite shelf life, like so many other things, and those of us that don't like it can simply consume other games (it's what I do). OR the problem may go away if someone makes a business out of providing end of life support for those games. Something like what GOG does, which is something companies are often happy to engage with, because they may still gain some more money from it while being relieved of all the related costs. I don't think governments will ever be able to mandate anything substantial. And that is if they ever do anything at all. The EU doesn't seem willing, and I heard something about companies moving against SKG now (and maybe understandably).

Alright, fair enough.

If you want your settings to persist without worries, you can store your non-default settings in a separate cfg file, including your key binds. You can make an autoexec.cfg or autocommands.cfg (one or the other, not both), which will be automatically executed when the game starts. If you put your preferred settings in there, they'll always be left intact when you update the game, even if the update changes Darkmod.cfg or DarkmodKeybinds.cfg. You can also execute other cfg files from inside you autoexec.cfg with the "exec other_file.cfg" command. This is what my autoexec.cfg looks like (abbreviated): echo "--- LOADING AUTOEXEC CFG ---" seta sensitivity 5.5 seta pm_bobroll 0 seta tdm_music_volume -22.4 // seta com_maxFPS "70" seta com_maxFPS 120 seta con_fontSize 8 seta logFile 1 seta tdm_download_list_sort_by 1 seta tdm_download_list_sort_direction 1 seta tdm_mission_list_sort_direction 0 seta tdm_mission_list_title_style 0 bind HOME "exec gameplay" bind END "exec mapping" com_smp 1 tdm_player_wait_until_ready 0 // run other custom cfgs exec windowed_mode exec gfx exec mapping Some keybindings are a bit annoying to figure out, especially the "impulses". You have to change them in the game and then see what changed in the keybindings file, or something like that, so you learn which bind command corresponds to which ingame keybinding.

I just noticed you included a / in there, because Godot uses / for all paths, and all path validity checks just failed when I was testing the code. I'm presuming I don't need to worry about it, as the zip file will probably always contain the compatible one, and it may be ok to not check for that character. But I'm a bit confused at how / causes problems, though, so I'm not sure what to think. The python version uses \ instead (I think), which may be why I never noticed this before, but maybe that's because I'm on windows. If that's the case, then it will misreport every path as invalid on linux.

Just published a more juicy update than usual, which includes the latest suggestions. Ended up getting back to this project way sooner than I expected. Alpha 0.4 - https://github.com/Skaruts/tdm_packer_2/releases/tag/alpha-0.4 Maybe I'll start bringing some of the features from the python version into this one, now. They're long overdue.

I see. I suppose I may be able to go even a bit further and support arbitrary variables, so you could do something like this and have less worries. ---------------------------------------------------------------------------------------------------- FM Title : $title Author : $author Build Date : $pack_date Version : $version ----------------------------------------------------------------------------------------------------

@Frost_Salamander Sorry for the delay. The .pkignore editor is in the Package -> Pack tab. You can completely ignore the the Files tab as it currently serves no purpose. It was intended for editing other files (scripts, xdata, etc), but I couldn't get it to work properly so I left it for sometime in the future. (As it stands it's best to always confirm the list of files that are packaged, as the filtering may still not be 100% reliable.) I like the idea of automating the versioning, especially naming the pk4 after it. For the darkmod.txt side of it, it would require a different setup. Last time I worked on this, I tried to separate the darkmod.txt editing into separate UI fields, but it was being a huge pain to get them all working properly, so I left it on stand-by as well. I'm not sure about the readme, though. Could you show me an example of how it looks like? Yes, for now the console is the only way of providing feedback. I'd like to improve on this at some point. For packaging, I could get a progress bar going, with the pack listing next to it. I'll see if I can get back to this project soon. I had to let it go for a while due to burnout.

@datiswous Might be worth considering at some point, if people find them useful. But I think as of yet they're still experimental and mostly untested, and maybe even subject to drastic changes, so I don't know if that would be a good idea.

I completely forgot about the location stuff and the ambient sounds. In this mission it's would probably just be two locations. Should be pretty straightforward. The key points for location_separators would be the balconies and the entrance window.