[BUG][PACKTOOL] Non-fatal error popup when deleting talismans.

[namida]

Steps to reproduce:
1. Add two talismans to same level.
2. Delete first talisman.

Error message pops up. If you select not to terminate the program, there do not appear to be any further effects aside from the talisman box listing the (now only) talisman as "Talisman 2". This, too, fixes as soon as you select another level then come back to this one.

EDIT: VERY minor side-note: Miners is incorrectly listed as "Mimers" in the talisman editor's dropdown box.

[namida]

Other issues I've noticed:

- When I try to save over an already-existing pack, I get an error message and the save fails.
- The tool doesn't save to the folder I select to save in, but rather, creates its own subfolder within that folder.
- The tool doesn't default to the last used folder for loading / saving, or even to the "levels" folder, but rather to the main NL folder.
- Postview texts become corrupt after using the tool (at least if talismans are edited). Not sure if this applies to preview texts as well.

[Nepster]

Steps to reproduce:
1. Add two talismans to same level.
2. Delete first talisman.
Error message pops up.

Fixed. I only ever tested removing the last items in lists.

EDIT: VERY minor side-note: Miners is incorrectly listed as "Mimers" in the talisman editor's dropdown box.

Oops. Fixed.

- When I try to save over an already-existing pack, I get an error message and the save fails.

Raymanni already noticed this in version 1.0 and I fixed this in version 1.1 (at least I hope so). Which version do you use?

- The tool doesn't save to the folder I select to save in, but rather, creates its own subfolder within that folder.

I had to choose two out of three of the following properties:
- Save directly in the folder the user selected.
- The pack toolkit produces a folder that only contains the pack files, so that the user can simply zip and publish it.
- Small risk of data loss for the user. While I do have a warning message, I didn't consider this enough. Otherwise people might save their new pack in the folder "levels" and then rant about losing all their other packs...
Out of these I considered the first one to be the least problematic to be left out.

- The tool doesn't default to the last used folder for loading / saving, or even to the "levels" folder, but rather to the main NL folder.

Thanks. I changed it to: Last selected folder in the pack toolkit; if not available, then "levels" folder; if not available, then pack toolkit folder.

- Postview texts become corrupt after using the tool (at least if talismans are edited). Not sure if this applies to preview texts as well.

Sorry, but I cannot reproduce this bug. Could you please add some more details, in particular examples how it should be compared to what the pack toolkit produces.
Note that the pack toolkit does not store the pre/postview texts at the very end of the file, but directly after the skill information.

[namida]

I did have V1.0; redownloaded latest versions of all tools (based on the main "everything except styles" download).

Re: Saving in folder, I disagree that this is optimal, especially since the user has no control over the subfolder name. A warning is given in cases where it still might overwrite data, which can still be the case - it's just a bit less common to actually trigger it unintentionally. Furthermore, the user can only "simply zip and publish it" if the pack doesn't use any custom styles or music, and doesn't use any custom graphics that the toolkit app doesn't recognize (I noticed many of these did NOT get copied into the subfolder in these cases).

Re: Postview text corruption, this still occurs for me on V1.1. As an example, from LPIII's final level:

Before using packtool (click to show/hide)

Code: [Select]

$POSTTEXT
  LINE CONGRATU-FREAKIN-LATIONS!!
  LINE Amazing, simply amazing.
  LINE You've overcome every obstacle, and
  LINE beaten even the legendary Fierce levels.
  LINE You are truly an exceptional master of
  LINE Lemmings, there is no doubt.
  LINE Thanks EricLang & ccexplore for Lemmix;
  LINE Akseli, DynaLem, minimac and Nepster
  LINE for pre-release testing; and to the
  LINE Lemmings Forums community in general
$END

After using PackTool (click to show/hide)

Code: [Select]

$POSTTEXT
   LINE CONGRATU-FREAKIN-LATIONS!!
   LINE
Amazing, simply amazing.
   LINE
You've overcome every obstacle, and
   LINE
beaten even the legendary Fierce levels.
   LINE
You are truly an exceptional master of
   LINE
Lemmings, there is no doubt.
   LINE
Thanks EricLang & ccexplore for Lemmix;
   LINE
Akseli, DynaLem, minimac and Nepster
   LINE
for pre-release testing; and to the
   LINE
Lemmings Forums community in general
 $END

Note how, aside from that the text isn't on the same line as the "LINE" keyword anymore,  there's also an extra indent that isn't present on other lines in the file. Let me know if you'd like me to send you some files that I know will reproduce this.

[Nepster]

I hopefully fixed the text corruption, though I still cannot reproduce it.

Re: Saving in folder, I disagree that this is optimal, especially since the user has no control over the subfolder name. A warning is given in cases where it still might overwrite data, which can still be the case - it's just a bit less common to actually trigger it unintentionally. Furthermore, the user can only "simply zip and publish it" if the pack doesn't use any custom styles or music, and doesn't use any custom graphics that the toolkit app doesn't recognize (I noticed many of these did NOT get copied into the subfolder in these cases).

Ok, how exactly do you suggest the pack toolkit should behave?

[namida]

Save to the exact folder the user suggests. Just like it currently does if the subfolder already exists, give a warning if the folder is not empty. Unless it deletes unrelated folders, saving in the "levels" folder itself may cause oddities but won't destroy data.

Alternative options are to specifically blacklist the "levels" folder, or to allow selection of the subfolder name independantly of the pack's title. Or at the very least, seperate "Save" and "Save As", and use the input folder (not a subfolder of it) when loading a pack rather than creating from scratch. This last option alone is probably sufficient; this mainly causes problems when modifying an existing pack rather than when creating a new one.

[Nepster]

Thanks. The next version 1.2 will remember the file path where the pack was loaded and suggests this path when saving again, so that the old pack will be overwritten. Given your feedback, I will try this first and see whether this alone is sufficient to eliminate the problems with changing an existing pack.
If you still encounter problems in the next version, please tell me again and I will implement your suggestion.