Skaruts

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.

A bit more on the technical stuff:

Nice little mission. Had a bit of fun. Could be improved, but it's not a bad start, I think. I'll try to add my 2 cents on top of what other people already said. On gameplay/map related stuff: On the more technical stuff

Just released a minor update with autosaving added to it. https://github.com/Skaruts/tdm_packer_2/releases/tag/alpha-0.3.1

Not outside the realm of possibility, but I have very little experience using mods. I use one for displaying alerts and stuff, but it's the only one I've ever used. I don't even remember what it's called anymore.

Yea, I'm gonna go with autosave. Saving tiny files like these is quick enough that I think I can do it whenever you make changes, maybe with a couple seconds delay so that it only saves when you stop making changes. I think it should be fine. I can't think of a reason that hotkey wouldn't work either. Ctrl-z is one of Godot's default UI binds and the input is detected internally by the CodeEdit node itself (which is fully implemented by Godot), so it wasn't set up by me. But as far as I can tell I did set up ctrl-s the same way (in the l suffix one). And it works on windows, at least.

During this week I managed to bring this up to version 0.7.2, and it's probably gonna remain where it is while I work on the gui tool (and other stuff), unless I or someone else finds any severe problems. https://github.com/Skaruts/tdm_fm_packer/releases I added a command --check [materials, skins, xdata, entities, etc] for checking for files that have no definitions in use, or optionally (-d) for individual unused definitions. There's still stuff missing, but I think it's already a good start. The same command with a different parameter can also check the mission's files for problems, like uppercase characters on the mission's folder name, and usage of spaces or special characters on file paths. It may take a couple seconds to parse large maps and retrieve information. My mission takes 0.8 secs, but parsing Iris takes about 3.8 seconds. My pc is old and slow, though. I'm considering maybe adding a cache to it, so the map doesn't have to be parsed every single time.

In that case, I'm a bit lost. It's the same as mine. I exported two versions of the app with a different setting on the hotkey, just now. If you can try them out to see if they work. I uploaded them temporarily to the releases: https://github.com/Skaruts/tdm_packer_2/releases/tag/alpha_0.3 I would prioritize the one with the l suffix, and if that one still doesn't work try the one with the u suffix. I don't suppose this will fix it. I changed the input mode of the hotkey to unicode (u) and keycode (l, for "latin keycode") instead of the physical location of the key. Since your keyboard is querty, I'm not sure this will make any difference, but if you could try them out, we could know for sure. All the default key bindings that godot ships with are using latin keycodes, and that includes undo/redo which work on your end, so I'm wondering.... (You can copy the data folder from your tdm packer folder into the new ones, so you don't have to set the paths again)

Is your keyboard querty? I don't know how Godot handles those things. I'll have to double-check the controls are set up correctly. Do other hotkeys work? Like undo (ctrl+z), redo (ctrl+y / ctrl+shift-z)?

You can press ctrl+s. The hotkey is from the text editor itself, so you must click the text editor for it to gain focus and receive input. I've been on the fence about just having a global save functionality that just saves all mission files at once, whenever you do ctrl+s. Might make it easier on users and also on me, because individual saving is harder to work with. Or... I could add a timer, that counts down a couple seconds and auto-saves, after you make some changes. That could work too.

I'm inclined to believe that's some TDM or Linux sided quirk. The program just uses whatever path you give it. It only cares that the executable is in there. I can't reproduce this on windows. Unless it has something to do with Godot not being able to set the current-working-directory (CWD) to the game's path when launching it. If that's the cause, I can't do anything about it, unfortunately.

@datiswous by the way, is the executable icon a little cardboard box? (And showing everywhere, window, filesystem, taskbar, etc?) Just wanted to be sure I set the icon properly. Yes, you need to edit by hand, for now (and save). I may do something with the trees at some point, but that will probably be a rabbit-hole of its own. There are no handy UI buttons for now either. As far the text editors go, you still have all the hotkeys you might expect: ctrl-s, ctrl-z, ctrl-shift-z, etc. Including multi-cursors, if I didn't forget to turn them on. Yes, you have to save the .pkignore in order for it to rebuild the trees. Damn... that's a bummer. I don't know what to do about it, as I'm just using Godot's api to execute a process. Have you tried running the console version of TDM Packer? I don't know if it will show any useful information. I didn't export with debug, so probably not. Yes. If you have more than one map in the map sequence it will create a tdm_mapsequence.txt, instead of a startingmap.txt. This is something I still have to look deeper into, though. I've never made any campaigns, so this feature is probably not reliable as is, and I'm not even sure I'm on the right track. I only looked into the files of NHAT. Just to clarify it, I made it this way because I tend to have lots of small test maps and even some local backups, or different versions of the main map. Excluding them all by hand in the .pkignore would be quite tedious. Since I couldn't think of a reason why one might want to include unused maps in the pack, I just went with the assumption that there probably isn't one.

Yea, I should've linked directly to the releases. Sorry about that. Fixed it. I don't know what else to call it. Or maybe you mean I should include the app name in it? I should've done that, indeed. It didn't even occur to me, for some reason. Maybe tdm_packer_a0.3_linux.tar.gz would be an improvement.

@peter_spy @Frost_Salamander I've actually been working on that kind of thing in the python version. I'm gonna have to do the same for this version, but some of those things are already usable in the other one in the dev branch, through the --validate command. https://github.com/Skaruts/tdm_fm_packer/tree/dev I've been doing this in that version because it's easier to iterate and test. Once I get to the point things seem to be going ok, I'll bring them to this one. I forgot to update the readme, though, but you can use -h to see how it works. (EDIT: actually, I forgot to update the help too, omg... ) (EDIT2: got that sorted.) Beware though that the paint is still fresh. It may not be working 100% reliably. Needs more testing.