Skaruts

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)