incorrect directory detection

[abenkovskii]

incorrect directory detection

[Felger]

That makes sense. I likely need to change it to "xenonTank/." to get the regex working, it's getting a false match on the xenonTank part of xenonTankRadial directory.

[abenkovskii]

it should probably be automatically applied to all patches in the program rather than in the config because current behavior is not obvious enough. It gives the creator of *.prnl file the ability to prune directory he is not aware of.

[abenkovskii]

Imagine situation: mod X in version v has a folder <obsolete_part_name> under it's parts directory and the same mod in version v + 1 in addition to <some_obsolete_part_name> folder also has a folder named <obsolete_part_name><useful_part_suffix>. If prune list was created before update it is likely to prune both folders.

[Felger]

Making sure I understand your request. As it stands now, an entry of
FASA/Apollo
Will also prune the unintended directory of:
FASA/Apollo72

However, if we update this to:
FASA/Apollo/.

It will not prune the contents of FASA/Apollo72, which is the expected behavior. I'll put out some updated prnls for that sometime soon.

[abenkovskii]

No I think this is the code bug. Do you know that not only you are writing prnls?

[Felger]

Maybe I don't understand the issue, can you post a prnl to pastebin or something where you're having issues, along with a description of what's happening so I can take a look?

[abenkovskii]

It is not an error in the concrete prnl (otherwise I could easily fix it myself) it is a bug in pruner.exe that may cause some problems if someone (modmaker for example) forgets to add '/' at the end of the line that describes directory path.

[Felger]

I think I understand, though it'd help to have an example of what you're talking about to make sure.

If so, though, it's expected behavior. Here's how autopruner figures out if it should prune a given file:

1. Read in the prunelist specified by the user, store in an array.
2. Work through the GameData folder procedurally
3. For each relevant file (certain directories files are excluded, like ATM) get the full path, like this:
   /users/abenkovskii/apps/KerbalSpaceProgram/GameData/Squad/Parts/Engines/mainsail.cfg
4. Compare that file to each item in the prunelist.
5. If a match is found anywhere in the string, prune the item (append .pruned)

So, if you have a prunelist item like this:

/Squad/Parts/FuelTank/XenonTank

And two files like this:

 /users/abenkovskii/apps/KerbalSpaceProgram/GameData**/Squad/Parts/FuelTank/XenonTank**Radial.cfg

 /users/abenkovskii/apps/KerbalSpaceProgram/GameData**/Squad/Parts/FuelTank/XenonTank**.cfg

Then you'll get a match on each of them due to the bolded area matching both. To avoid this, you must be specific:

/Squad/Parts/FuelTank/XenonTank.cfg

Will only match the second item, but no the first. Now, this exposes a minor bug, in that regex will interpret the . as a wildcard, so it's possible to match to something like this:

/users/abenkovskii/apps/KerbalSpaceProgram/GameData/Squad/Parts/FuelTank/XenonTankacfg

But unlikely.

[abenkovskii]

1. Now I found the place in the code where it checks if file marches (it wasn't easy because I don't know perl).
2. Currently it searches not for mach anywhere in the string but only for mach from start of the path relative to GameData.
3. also regex will not interpret the . as a wildcard because it is inside a literal sequence (enclosed with \Q and \E).

[abenkovskii]

Then can someone explain why this behavior is chosen?

[Felger]

I should read my own changelog, forgot I sanitized the prunelist input to the regex last update.

The behavior is chosen because it's a simple matching method, doesn't require accounting for a ton of edge cases. If you want to prune a directory, you just need to add an explicity "/" to the end of your prnl entry.

If you have an alternative method, feel free to submit a PR or pseudo-code for how it ought to be handled and I'll consider it.

Regardless, I'm still hoping for an example to show the behavior that you'd like the script to avoid. I'm still not sure I understand how you're hoping for it to behave...

[abenkovskii]

pseudo-code:

function prune_dir (path dir_path, bool prune_all):
    for file in dir_path:
        if prune_all or file name exactly matches one of patterns:
          rename file
    for directory in dir_path:
        prune_dir(directory, prune_all or directory exactly matches one of patterns)

Am I missing something? What edge cases you are talking about?

[Felger]

Functionally, that's no different from simply adding a "/" to the end of a directory name in a PRNL now.

Also, if you want to prune all, we don't need a separate check. Just input something that'll match every filepath, like 000_Global does with "/".

[abenkovskii]

1. relying on correct user (prnl creator in this case) input without checking it isn't a good practice. Is it?
2. bool prune_all is for recursive call.

[Felger]

One way or another we're relying on correct user input. Making a specific check for directory name matching doesn't change that. Adding a closing "/" to signify a directory name is fairly common practice.

It basically boils down to, "I like it the way it is" so I'm disinclined to change it.

Working as intended

To be fair, if you want to change it, you're welcome to. Fork my repo, make the code change, test it, make a pull request, and I'll look at changing it. But I'm not personally going to put in the time to change the methodology.

[abenkovskii]

Well... It actually works reasonably fine. Plus I don't know Perl. Plus I ended up not using autopruner for my main mod build (ActiveTextureManagement is awesome). So I'll close this issue.