Skaruts

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.

Thanks for the feedback. ... on some systems. I thought I read somewhere that the interpreter comment wasn't needed anymore in python 3. Maybe I'm remembering wrong. I don't use python often enough to remember things... If this is actually required, then I'll add it in, ASAP. Thanks. I didn't know that module existed. Thanks again. This was force of habit from coding in GDScript in Godot. Tasks aren't really being useful in this script (at least not yet), as there's only ever one task, so maybe that's why I didn't notice any issues. (I think tasks should've been a queue, as well.) Tbh, I don't really care about using built-in functions as member variables, or in small ephemeral scopes. Under those circumstances it should never cause any conflicts (unless python has some pitfall that I'm not aware of that makes it so). But it was the way I needed it, in order to support more complicated args. This is code I brought in from another script where the index is advanced manually depending on the parameters of each argument. But yea, I might as well simplify it in this script, though. I'm intending to keep this tool simple to use. I've been aware of argparse, but since I never do anything too complicated, I figured it would take me longer to learn it than it would to parse args with some simple code. I confess I'm not too patient to learn python, since I don't use it much. I've been intending to dive into argparse at some point... I didn't remember that about len. Although the string part is intentionally explicit. I personally don't like having empty string comparisons hidden. I prefer explicit code overall. If there's a more explicity alternative to `not tasks`, would prefer it.

I renamed this tool, to be a bit more specific. I've been working on a GUI based version of this, which already has more functionalities, and it's easier to use.

Alright, here's v4: https://www.mediafire.com/file/ov8m8hsxw83v844/sk_cooks.pk4/file @nbohr1more

I personally don't mind it at all. That was my initial intention anyway, to just stick with a simple iteration number. I went with 3.1 mostly because I was unsure in this case. I'll bump it up to 4, then. I'll post it later today.

Oh! I had no idea. Wouldn't it be better to bump the version in the pk4 then, just to be consistent and avoid generating any confusion?

Here's version 3.1, which fixes the issues above. https://www.mediafire.com/file/82unapzjq8f08np/sk_cooks.pk4/file Hopefully everything is good now. @nbohr1more sorry to bother you with this again.

Bummer... This is actually a mistake on my part. Gonna have to release a new version with a fix. Maybe I could take the chance to also fix the fact that you could keep the guard asleep by going around through the sewers, which I completely forgot to fix. I removed the switches but kept the lamps off, though. I don't think there's any gameplay changes there, unless you liked having the lights on (you can lit oil lamps with a candle, but you need water arrows to put them out, though). Iirc, the only light I moved is the candle in the gatehouse, though I don't think it changes the gameplay that much. The streetlamp is the only significant lighting change that I can remember, but specific to Normal difficulty. The loot changes aren't that significant. I just adjusted them a bit for visibility. The new secret is the only more significant change.

Updated mission to version 3. @nbohr1more Changes:

@OrbWeaver, indeed 7z LZMA compressions don't work. I'll remove it from the script then.

Hmm let me investigate. I packed my BTC mission with 7z and it worked fine, but I confess I haven't tested any of the archives created by this script. I didn't think this could be a problem. Gonna check... (And yes, the goal was better compression.)

I've just created a little python script to make packing missions a bit more convenient. It zips everything into the pk4 for you, while also excluding unwanted files that you list in a .pkignore file. https://github.com/Skaruts/tdm_packer It's in an experimental state. It should work fine, but there's probably things missing that I couldn't think of.

Hey everyone. I'm working on an update for this mission that I will release soon. If anyone has any further bugs to report, please let me know. I've already made a few changes based on what I learned since release, thanks to all your feedback, gameplay videos, etc, and I've also addressed some issues that I hadn't addressed yet. Most notably: