Skaruts

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

Possibly. I'll need to know the rules.

@nbohr1more Added this to the python version. Seems to be working great. Also complains when the mission folder is invalid. Gonna port it to the GUI version.

Is this a problem specific to the server and not the game? I just need to know what kind of error or warning to display. Also, I could actually enforce this, rather than just warn about it, if that would be preferable.

Quite possibly. I could even do this on the python version too. Spaces are easy to look for. For special characters I'll need to know more about what's supported. I suppose that includes the pk4 name, right?

This is an experimental GUI app for managing and packing Dark Mod missions. It's a successor to FM Packer but with a GUI, that I've been working on for some time. It's now at a stage where I feel somewhat comfortable sharing. Having a GUI unlocks potential for more in depth management of fms, which I intend to explore in the future. You can download the binaries here: https://github.com/Skaruts/tdm_packer_2/releases Currently: it can pack your selected mission into the pk4 at a click of a button it provides an editor for a .pkignore file where you specify which files to exclude from the pk4 it gives you a handy tree view of both the included and excluded files (Shift+LMB to fully expand/contract branches) it can launch TDM or DarkRadiant for the selected mission, or run a second installation of TDM to test your pk4 in isolation (see the menu Settings->Paths) it automatically writes your map sequence into the appropriate file all maps, except the ones in the map sequence, are auto excluded from the pk4 Important: This is still an experimental alpha version, so backup your missions before using it. Note: For now I provided binaries for Windows and Linux. I don't have a Linux system to test the binaries yet, though, so they may or may not work properly. As a last resort, one can still run this app from the source code by running the Godot Engine itself from the terminal with the "--path path/to/project" argument. (Godot itself is just a simple executable and requires no installation.)

Just updated this to version 0.5. It was mostly polishing work and improving the arg parsing, but I also added a couple new commands for creating/editing the .pkignore file with it. Also renamed it to FM Packer. I hadn't noticed before that it wasn't automatically excluding .lin files and the savegames folder. Now it is.

@OrbWeaverdo you think you could point me to the part of the code where vertex manipulation is handled? Maybe by looking at it I could figure out how the texture shifting is calculated as a consequence of moving vertices around.

Yea, me too. If a mission drags on for too long I start getting bored and burning out. I need to have a somewhat frequent sense that I'm getting somewhere and achieving something. I also get overwhelmed when large missions have too many little things to do and too many paths to choose from. I tend to keep a mental note every time I find a fork on the road, to come back later and try the other path, so if there's too many forks my brain explodes... What drove me to make a small mission was more of a need to keep it small for a first mission, but I don't intend to make any future missions much bigger. Or at least not larger than necessary. As @chakkmanmentioned, small missions are easier to enrich with interesting details.

Added the interpreter comment. Also fixed the built-in function shadowing thing, because it started bugging me since you got me thinking about it. The rest of the stuff I'll eventually get to it.

At least Windows 7 does. It's how I've always ran python scripts. I wasn't specific in the readme just because I don't know what other systems -- if any -- can do that too. I just wanted to keep the instructions as clear as possible. So if I'm understanding correctly, that comment allows you to omit the explicit python call on Linux? (Btw, I think I was confusing it with another comment that people used back in python 2, which iirc was no longer needed in python 3, so nevermind that.) Yea, the syntax highlighting can be a little annoying, but when it's a small thing like that, it can bother me more to have to rethink it, than to just go with it. Also by ephemeral scope I just meant the init function. Being a member variable means you need to do *task.type*, so I don't see it ever being a problem. There is a part of me, however -- the highly responsible lua coder part of me -- that is telling me I shouldn't open lazy exceptions, especially in a language with too many pitfalls, like python... That's actually very true. One of these days I'll give it a go, then. I'm thinking in terms of what is instantly clear to the eyes and requires no brain effort to parse. When possible, I like to write code that way. If I see `== ""`, I don't have to spend a moment determining what exactly is the condition being evaluated, or in some cases what the variable even is. Especially when I look at the code in six months. In this case the difference is probably negligible, but it's a personal convention. I think the only conditions I ever use implicitly are the booleans.