lynx

err, did you run that in the folder with the baf files? If there are no bcs files there any more, then no problem. The other errors are fine as well.

Are we still talking about CopyGroundPilesTo? Who is running it, hopefully not the pc?

If you had to do it manually, I suggest a backup.

Open WSL and move to the same folder, then run this to remove redundant files:

Quote

rm *.bcs

grep -L Player6 * | xargs rm

Perhaps it doesn't want to do it if you target non-walkable terrain — did you check that?

does it work if you run it on a specific file, eg. weidu YUXTHRET.BCS

you need to run weidu on each of those files. If your shell or weidu can't handle that many at once, try with a loop or limiting the glob and doing it in steps (for example [a-k]* then [l-z]*).

Sorry, it uses a regex, not a glob, so the command is:

weidu --biff-get ".*bcs" 

Then you can try to decompile them all:

weidu *
rm *bcs

Then you either work with all the files or exclude those not mentioning Player6. That's why I was asking about WSL — I can tell you what to run, otherwise it's up to you:

# this will remove every file not referencing Player6
grep -L Player6 * | xargs rm

# if you get errors about xargs, just get the list of files and delete them manually:
grep -L Player6 *

Let me know if this phase went well.

Wait, what? Are you saying if you run weidu from the same dir where chitin.key is (eg. the base game dir), weidu errors out?

Ok, maybe that's one level too deep for weidu to find chitin.key. Try creating another temporary dir in the game dir and do it from there.

Do you perchance have access to that linux-shell-on-windows thing (I think it's called WSL)? Either way, you'll need a console open to run weidu.

Anyway, the mod does these things:

1. Looks for all scripts that reference Player6 and decompiles them to BAF.

2. Runs the perl scripts to upgrade each script.

3. Recompiles them and puts them into override.

(and almost the same thing for dialogs)

Judging from some of your log output, it seems like it failed already at step 1. So I suggest you move to 10pp/temp/baf (create it if it doesn't exist), run weidu --biff-get "*.bcs" and see if that manages to extract them all.

It's an oddly phrased question — the answer is the exe. Anyone that got JoinParty called on them will be there, unless they lost the party overflow game.

That's an error from windows, so I can't be of much more use. I know other people hit it with other mods as well, but I think in general it can be ignored?

As a last resort, you could install the mod semi-manually, in steps, but then it won't be uninstallable. Let me know if you want to try this.

ground piles are indeed containers, but they don't have any or any predictable scripting names you could use to target them.

Why? It's the last mod to be installed, so weidu won't touch anything before that.

PST is a hardcoded mess, but some of this resurrection stuff is nicely specified with ini files. But you're not modding for pst, so that's useless.

Copying piles is a safer alternative, since they might get destroyed with time otherwise. Teleporting the pc to the temple alone can lock you into areas that require the full party to travel from.

That's odd indeed. It's certainly not a deliberate design choice. I suspect something is insufficient in its forking implementation or something went wrong when adding the capture of return status support to AT_NOW. Or it's just AV sabotage ...

I've pushed an updated mod, so now amilowhatever shouldn't be a problem any more.

There's no powershell involved here, but maybe you're mistaking perl for it.

Looking at the code, I invoke perl for each file separately, so any leaks would be cleaned up immediately afterwards. I then suspect the leak to be in weidu.

Nope.

Btw, I'll make the mod just skip empty files. Also, looking into ways to see if your leaking is from your perl distribution itself or the mod.

Yeah, no need to reinstall just because of that. I guess it could help a bit at runtime, but I don't know if significantly.

Looks like you ran out of RAM and the swap file windows uses wasn't enough to compensate.

Oh and don't worry about biffing.

you need to change the path to point to the actual file ... but since you know it's RoT, there's no point.

We were trying to figure out if it's intentionally empty or not. You're saying it's empty from the get go. So just delete the file and 10pp won't barf on it.

That's good as well. You can then run:

weidu --change-log path\to\aminota.bcs

That will tell you where the file is from. Well, unless you already know it's from NeJ?

Thanks, true and added.

Ok, let's find out where that file is from, so we can check if it's supposed to be empty or not. I don't get any hits on g3 or shs github nor the original games, so you'll have to do the searching.

You can try to do a regular file search in your game install for aminota.baf (not bcs).