Posted by: the bigg
« on: October 25, 2010, 05:21:31 AM »Yes.
Posted by: Miloch
« on: October 25, 2010, 02:15:12 AM »The simplest solution would be to use MKDIR save before running sc#addwmpare; the 222 version of sc#addwmpare will execute MKDIR save on its own (unless you can think of a case where it'd be beneficial to have GET_FILE|DIRECTORY_ARRAY, *_BASH_EACH and the like silently skipping over missing directories).Ok, whatever works. I don't use it or know of it being used outside of messing with saved games.
MKDIR I guess does nothing if the folder already exists?
Posted by: the bigg
« on: October 24, 2010, 01:51:34 PM »According to the source code, it fails because there is no save directory; an empty regexp is translated to "everything but . and ..", and an empty save/ directory simply results in an empty array being saved. The simplest solution would be to use MKDIR save before running sc#addwmpare; the 222 version of sc#addwmpare will execute MKDIR save on its own (unless you can think of a case where it'd be beneficial to have GET_FILE|DIRECTORY_ARRAY, *_BASH_EACH and the like silently skipping over missing directories).
Posted by: Miloch
« on: October 24, 2010, 11:59:49 AM »Yes, it appears to.
As long as you're in there, there appears to be a slight glitch with the sc#addWmpAre function, in that if you set inclSv to 1, it will fail if no saves are present. Though I didn't write this code, I'm thinking it should be fixable by putting some actual regexp in GET_DIRECTORY_ARRAY? So instead of:
GET_DIRECTORY_ARRAY save save ~~
GET_DIRECTORY_ARRAY save save ~.+~
If that doesn't work, maybe we need some sort of DIRECTORY_EXISTS regexp parameter.
As long as you're in there, there appears to be a slight glitch with the sc#addWmpAre function, in that if you set inclSv to 1, it will fail if no saves are present. Though I didn't write this code, I'm thinking it should be fixable by putting some actual regexp in GET_DIRECTORY_ARRAY? So instead of:
GET_DIRECTORY_ARRAY save save ~~
GET_DIRECTORY_ARRAY save save ~.+~
If that doesn't work, maybe we need some sort of DIRECTORY_EXISTS regexp parameter.
Posted by: the bigg
« on: October 24, 2010, 09:25:57 AM »Does the newly uploaded beta work satisfactorily for you?
Posted by: the bigg
« on: October 23, 2010, 08:06:53 PM »No stealthy fix because this one is anything but an one-liner.
I think ungrouping those is the only available solution.
I think ungrouping those is the only available solution.
Posted by: Miloch
« on: October 23, 2010, 07:59:57 PM »Hey, if you've already done one ninja-fix and re-upload, why not another? 
(it's not like anyone else is using this feature, as yet)
Um, if not, is there a way I can fix locally short of ungrouping such components?
(it's not like anyone else is using this feature, as yet)Um, if not, is there a way I can fix locally short of ungrouping such components?
Posted by: the bigg
« on: October 23, 2010, 07:38:35 PM »(GROUP_ENABLED ~BG2 NPCs~ AND GAME_IS ~bg2 tob~) OR (GROUP_ENABLED ~BG1 NPCs~ AND GAME_IS ~tutu tutu_totsc bgt~)This will be the behavior in 222, then.
Posted by: Miloch
« on: October 23, 2010, 06:57:19 PM »However, since GROUP constraints act as REQUIRE_PREDICATE, it ends up working like REQUIRE_PREDICATE (GROUP_ENABLED ~BG2 NPCs~ OR GROUP_ENABLED ~BG1 NPCs~) AND GAME_IS ~bg2 tob~ AND GAME_IS ~tutu tutu_totsc bgt~.Well that is fairly counterproductive, because the game will never be *both* BG2 and Tutu. Should be a disjunction of two conjunctions, not vice-versa:
(GROUP_ENABLED ~BG2 NPCs~ AND GAME_IS ~bg2 tob~) OR (GROUP_ENABLED ~BG1 NPCs~ AND GAME_IS ~tutu tutu_totsc bgt~)
Now, I could remove the constraints from this component, based on the assumption there will always be an Edwin present regardless of platform. But my request was to look for all constraints for the GROUP and treat them as a conjunction (primarily for mod-added NPCs). By that, I meant the selected group - the BG2 NPC group is autoskipped here, so it shouldn't be looking at the constraints for it. Doesn't make much sense to remove the constraints from all GROUPs either. Any chance of restoring the v221 beta behaviour, only with the "conjunctive constraints" added (sounds a bit like "conjugal visits" eh)?
Posted by: the bigg
« on: October 23, 2010, 06:29:20 PM »Multiple groups still work properly. However, since GROUP constraints act as REQUIRE_PREDICATE, it ends up working like REQUIRE_PREDICATE (GROUP_ENABLED ~BG2 NPCs~ OR GROUP_ENABLED ~BG1 NPCs~) AND GAME_IS ~bg2 tob~ AND GAME_IS ~tutu tutu_totsc bgt~.
GROUP constraints are documented in the GROUP tutorial.
GROUP constraints are documented in the GROUP tutorial.
Posted by: the bigg
« on: October 23, 2010, 06:07:05 PM »That's what you get for requesting translations.
Posted by: Miloch
« on: October 23, 2010, 04:15:30 PM »So I've got the Edwin component in both the "BG1 NPCs" and "BG2 NPCs" group, i.e.:
GROUP ~BG2 NPCs~ (GAME_IS ~bg2 tob~)
GROUP ~BG1 NPCs~ (GAME_IS ~tutu tutu_totsc bgt~)
In v220.11 this was working as expected - I was getting prompted on both BG2 and Tutu. As of v221, it's skipping Edwin on Tutu, apparently acting as a conjunction instead of a disjunction (that is, should get prompted if either group is chosen or detected). I did choose to install components of the BG1 NPCs group - those that aren't in 2 groups work fine.
Moreover, it just says "SKIPPING: [Edwin Odesseiron]" - I thought there was a slightly more descriptive message previously (like "because it fails its requirements" - then again, I guess it wasn't getting skipped previously so maybe that was just for GROUPs).
Lastly, the "GROUP accepts a constraint" thing is not documented AFAICT.
GROUP ~BG2 NPCs~ (GAME_IS ~bg2 tob~)
GROUP ~BG1 NPCs~ (GAME_IS ~tutu tutu_totsc bgt~)
In v220.11 this was working as expected - I was getting prompted on both BG2 and Tutu. As of v221, it's skipping Edwin on Tutu, apparently acting as a conjunction instead of a disjunction (that is, should get prompted if either group is chosen or detected). I did choose to install components of the BG1 NPCs group - those that aren't in 2 groups work fine.
Moreover, it just says "SKIPPING: [Edwin Odesseiron]" - I thought there was a slightly more descriptive message previously (like "because it fails its requirements" - then again, I guess it wasn't getting skipped previously so maybe that was just for GROUPs).
Lastly, the "GROUP accepts a constraint" thing is not documented AFAICT.
Posted by: the bigg
« on: October 10, 2010, 06:40:53 AM »It's using this:
log_and_print "%s [%s%s\n" (get_trans (-1020)) package_name (get_trans (-1037));
WeiDU is pretty inconsistent on this - in some cases the [ (or whatever) is hardcoded in the formatting string, in others it's supposed to be translated.
log_and_print "%s [%s%s\n" (get_trans (-1020)) package_name (get_trans (-1037));
WeiDU is pretty inconsistent on this - in some cases the [ (or whatever) is hardcoded in the formatting string, in others it's supposed to be translated.
Posted by: Miloch
« on: October 10, 2010, 05:39:50 AM »'Skipping' (@-1020) is without the square bracket (or the space), while '] because it fails its requirements.' (@-1037) has it.So did you just hardcode the left bracket for "Skipping [component] because it fails its requirements", add a new string or what? I don't know if there are any languages where brackets will be different (maybe Chinese or something). I suppose you could also just drop the GROUP from @-1036 and use the same text for both GROUPs and components.
Posted by: the bigg
« on: October 09, 2010, 04:19:14 PM »Actually, I just fixed that line without making it translatable. Now it is actually translatable.
Of course, 'Skipping' (@-1020) is without the square bracket (or the space), while '] because it fails its requirements.' (@-1037) has it.
Of course, 'Skipping' (@-1020) is without the square bracket (or the space), while '] because it fails its requirements.' (@-1037) has it.