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:

Might not be the case here, but make sure you're not using any materials with no-shadows there. I once fell in the trap of using one without noticing, so I just thought I'd mention it. I might also try to replicate the problem in a simplified test map, to see if the problem persists.

Might be worth a try. I browsed the source code yesterday a little, but I had no idea where to even start looking for it. I've been building a sort of starter-project for it, but it's not public yet. But my support for DR is not ready for production or anything. Everything seems to work fine, except I'm having issues with textures, and tbh I'm not sure I'm gonna make it. I am about to make my repo public regardless of that, though, but I still need to get a lot of stuff in order. Meanwhile, if you'd like to move forward without DR, you could try NetRadiantCustom or TrenchBroom. Personally I recommend NRC (although TB might be a bit easier to start with). The plugin I'm using is FuncGodot (formerly known as Qodot). It's currently the most recommendable. Patches and NURBS aren't supported by any plugins yet, btw.

Actually I think I found what's causing issues with my textures: DR changes the texture's Horizontal and Vertical Shift when a face gets slanted. E.g., my test door is facing -Y and sitting flat on the ground, which is at 0 in Z, so the v-shift is 0. When I move the bottom vertices of the door 8 units forward, and then re-fit the texture, the v-shift turns to 4 (3.97241). If I do the same but backward, the v-shift turns to 90.7035. But these values depends on the distance the face is from the world origin, and sometimes if I move the top vertices instead, the values don't change. I can't make sense of it... The other editors don't do this, so the plugin's import code doesn't account for it. Do you think you could help me understand the logic behind this? If I could understand it, maybe I could get the plugin working with it.

I'm not using the Quake 3 engine, I'm using the Godot engine. The results seem ok, except when faces are slanted, but I'm not sure why it happens. I'm trying to find out. I don't know anything about the Q3 engine, so I'm not the one to say what's correct and what isn't about the map format. When I said "correct", I just meant that it's the same value that is displayed in the editor. But there are differences between the Q3 format from DR and from other editors I've tested, like TrenchBroom and NetRadiant Custom. They keep the texture values as they are in the editor. One other difference is that DR exports entity brushes with coordinates relative to the `origin` spawnarg, for example. Though DR is also the only editor that enforces the `origin` spawnarg. (I know there are two Q3 formats, and I'm using the equivalent one on all editors.) I'm importing maps into Godot using a plugin. I've made some changes to it to accommodate for the differences in the map format and some editor specific stuff (e.g. DR uses "rotation" matrices instead of euler "angles").

So..., texture issues are being the only road block I'm having so far in trying to use DR with Godot, but I'm not exactly sure why yet. However, I've noticed when exporting maps in quake3 format, that the texture values don't match the ones in the editor. This is the door face in the map file: hs vs rot hscale vscale ( 24 64 0 ) ( -24 64 96 ) ( 24 64 96 ) darkmod/door/wood/board_brown_nails_hinge 64 256 -180 -0.375 -0.375 0 0 0 The horizontal shift is the only correct value. Is this a bug?

Someone else wrote that in the OP, I just edited the source link into it. There's not going to be any voices.

Switching systems is a longer term time and effort investment than a way to compile a program. Especially because I am willing to invest some time learning linux. Mint, probably. I don't have any strong preferences, I just want something reliable and low maintenance, where I can focus on work.

None of this is relevant, though. I will be switching OS and experimenting at some point, but I have other priorities to worry about in my life and no willingness to be adding that on top right now. Meanwhile, this is what I have to work with, and I'm trying to find out if there's a way I could still compile DR with it. @OrbWeaver I could use virtual box to run a linux distro, but could I compile to a windows executable from it? (I presume I can't.)

I'd still be on XP if they hadn't dropped support. I didn't say anything to that effect. I just grew to hate having to keep switching OS due to their business model that keeps imposing that. Been doing that for nearly 30 years now. I don't expect Linux to be paradise. I just hope it's less infuriating than MS products. Either way, that's besides the point here.

Unfortunately WSL is also for Windows 10, minimum. (This is why I'm going to switch to linux in the near future. I'm fed up with MS's bs and complications.)