An unhandled exception occured. Details: Error information:
Version: 2.1.0 <class 'AttributeError'>: 'WindowsPath' object has no attribute 'isfile'
File "fomod_validator.py", line 195, in button_validate_clicked File "site-packages\pyfomod\base.py", line 458, in validate File "site-packages\pyfomod\base.py", line 703, in validate File "site-packages\pyfomod\base.py", line 724, in validate File "site-packages\pyfomod\base.py", line 282, in validate File "fomod_validator.py", line 194, in <lambda> File "fomod_validator.py", line 147, in validate_file
This happens for me on every single fomod I try - those working, those not working. Does this program have any dependencies I'm missing? Visual Studio? Java? I don't know... something? (Win7 x64 here)
The only time it doesn't crash is when I point it to a folder that doesn't contain fomod inside (in which case it throws an error that no fomod was found).
Very handly utility. A suggestion for another check: NMM doesn't like linebreaks inside description elements; it doesn't cause any errors, but the layout/formatting of the text in NMM will get messed up with odd indentations.
Your code checks for something that the managers don't care about. In this case:
----------------------------------------------------------------------------------------------- ModuleConfig.xml is invalid with error message:
Element 'typeDescriptor': This element is not expected. Expected is one of ( files, conditionFlags )., line 20 -----------------------------------------------------------------------------------------------
This is an "empty" page in that it only displays some information to the user. It doesn't set a flag nor install anything. Both Mod Organizer and NMM have fixed it so their installers ignore this "missing" information and do not produce any errors.
Basically you're validator is saying there is an error where the manager installers do not. I don't know if the XML doc says that one of these must be in there or not, but it works either way.
That's not even me, that's the schema itself, it shouldn't be valid (at least not in NMM). I can update the schema, but you'll have to provide me with some installers for me to test (I don't really have time to make them sorry, I also have hishy making flag-testing installers).
If you could point me to the version where nmm and/or mo changed that it would be super helpful.
And the type descriptor merely sets the type of the plugin (required, optional, etc.) no flags or anything :p
Oh wait, that's not complaining about the type descriptor itself, it's either the order of the tags which is screwed up or one of those tags doesnt exist, which I'm pretty sure are still required. I'm sorr, I'm very tired
Here's you a link to a stripped down version of the STEP Compilation. The first page is simply an "informational" page which is tossing out the error. It's part of the schema and that's why I didn't post it as a bug. Technically, you're correct to the schema. But simply try installing the file in MO (v1.3.11) and the latest version of NMM (link at top of this page). Neither of them toss out this error because it really doesn't make sense when you think about it. If it works without those tags, why require them?
As for version changelogs, I don't now. NMM changelog only goes back so far (that I could find)...nothing prior to v0.6x. I think MO has always ignored it.
Mhmm, so they're not required wth NMM or MO internal but MO external still complains (which I guess is based on an early version of NMM). Does anyone use MO external normally?
If they do they shouldn't. We always advise on STEP to only use the internal installer. Yes, it is based on an early version of NMM. The internal installer is superior at this point. MO will run the external installer automatically for the C based mods so there's no reason to run it manually.
There is also no way to check fileDependencies. Not to mention nestled dependencies within dependencies
Maybe a compare the flagDependency name and value with the conditionFlags to make sure they are valid? I think a lot of cutting and pasting is involved when people create fomod scripts because manually typing every line would be insane. Overlooking a variable that should have been changed would be a common error.
A couple of notes in case you did not know... 1. Mod Organizer does not like the .jpeg extension. It only recognizes .jpg 2. <flagDependency flag="aName" value=""/> is a valid condition.
Did you make the value an empty string on both the conditionFlag and the flagDependency? Because if you're referencing a value that doesn't exist in flagDependency you'll get that warning, no matter what that value is.
If so, can you show me the differences? Like a before -> after.
I set an empty string value on the flagDependency only, which explains the error message.
Wouldn't an empty string value be an exception to the rule requiring the same value to be present on both the conditionFlag and the flagDependency? The empty string value is being treated as just another non empty string value. The empty string value represents the absence of any value which is not the same thing (just like OFF is not another TV channel). Why would it ever be needed to be set on the conditionFlag when it is the default state regardless?
Am I totally in left field on this? Which mods did you use empty string flags? Do you still need the before and after?
An empty string is simply another value, like "boop", "foo" or "On". It is still matched normally, I see no evidence to the contrary. If you want to, you can test it and get back to me with the results.
Let me rephrase yesterday... Your util does not handle empty string flag values correctly. It is generating a false positive.The test mod I sent to you will demonstrate the problem. When I validate the mod with your util, it says there are 2 errors. This is incorrect. There are no errors in the mod. I am bringing this bug to your attention.
This worked well when finding some errors I'd made in my config file, but it did not give any warnings or errors about missing image files. I entered a few image file names as placeholders, but I haven't added any of the images yet and the folder that is supposed to hold them is empty. However, as I said, no problems were detected.
Is this a feature that is still to be added?
Anyway, this is a great utility and saved me from going through my config line-by-line for a hidden mistake.
Yes - when I went to execute it, I got an error (of which I do not remember). A quick Google search of the error pointed at the runtime. After I installed it, it launched and ran just fine.
[EDIT - Of course, when I uninstalled the runtime (so I could get the exact error for you), it still launches just fine. My system's a mess. I'll edit out my previous comment. ]
I tested on a few of my files before ganda released it and found the mod "little things" to have a few bad directories which I am now working on getting fixed asap. :D I never even knew about this and I dont think anyone else did either.
Give Feedback
34 comments
Details:
Error information:
Version: 2.1.0
<class 'AttributeError'>: 'WindowsPath' object has no attribute 'isfile'
File "fomod_validator.py", line 195, in button_validate_clicked
File "site-packages\pyfomod\base.py", line 458, in validate
File "site-packages\pyfomod\base.py", line 703, in validate
File "site-packages\pyfomod\base.py", line 724, in validate
File "site-packages\pyfomod\base.py", line 282, in validate
File "fomod_validator.py", line 194, in <lambda>
File "fomod_validator.py", line 147, in validate_file
This happens for me on every single fomod I try - those working, those not working. Does this program have any dependencies I'm missing? Visual Studio? Java? I don't know... something? (Win7 x64 here)
The only time it doesn't crash is when I point it to a folder that doesn't contain fomod inside (in which case it throws an error that no fomod was found).
-----------------------------------------------------------------------------------------------
ModuleConfig.xml is invalid with error message:
Element 'typeDescriptor': This element is not expected.
Expected is one of ( files, conditionFlags )., line 20
-----------------------------------------------------------------------------------------------
This is an "empty" page in that it only displays some information to the user. It doesn't set a flag nor install anything. Both Mod Organizer and NMM have fixed it so their installers ignore this "missing" information and do not produce any errors.
Basically you're validator is saying there is an error where the manager installers do not. I don't know if the XML doc says that one of these must be in there or not, but it works either way.
If you could point me to the version where nmm and/or mo changed that it would be super helpful.
And the type descriptor merely sets the type of the plugin (required, optional, etc.) no flags or anything :p
As for version changelogs, I don't now. NMM changelog only goes back so far (that I could find)...nothing prior to v0.6x. I think MO has always ignored it.
File: https://mega.nz/#!E1ckSTba!j0AUxUWvaWunD9QGZ-qOX73ab2Pdgc6fOpcgHuQPN8M
How deep does it look at conditional flags? I know it examines conditional install file/dir, and does not look at the flag values.
Maybe a compare the flagDependency name and value with the conditionFlags to make sure they are valid? I think a lot of cutting and pasting is involved when people create fomod scripts because manually typing every line would be insane. Overlooking a variable that should have been changed would be a common error.
A couple of notes in case you did not know...
1. Mod Organizer does not like the .jpeg extension. It only recognizes .jpg
2. <flagDependency flag="aName" value=""/> is a valid condition.
The flags are a good idea though, adding it now!
However, It seems you missed my note #2. An empty string for value will pass the condition check only if the flag has not been set (to any value).
Edit:
I re-ran the test to make sure I wasn't hallucinating again. I also suggested a bit of text for clarification.
Mismatched Flag Values
Line 105: The flag value that flagDependency is dependent on is never set (as a condition) during installation.
If so, can you show me the differences? Like a before -> after.
Wouldn't an empty string value be an exception to the rule requiring the same value to be present on both the conditionFlag and the flagDependency? The empty string value is being treated as just another non empty string value. The empty string value represents the absence of any value which is not the same thing (just like OFF is not another TV channel). Why would it ever be needed to be set on the conditionFlag when it is the default state regardless?
Am I totally in left field on this? Which mods did you use empty string flags? Do you still need the before and after?
Let me rephrase yesterday... Your util does not handle empty string flag values correctly. It is generating a false positive.The test mod I sent to you will demonstrate the problem. When I validate the mod with your util, it says there are 2 errors. This is incorrect. There are no errors in the mod. I am bringing this bug to your attention.
Is this a feature that is still to be added?
Anyway, this is a great utility and saved me from going through my config line-by-line for a hidden mistake.
[removed]
You don't need it, or at least shouldn't. Did you find anything to the contrary?
[EDIT - Of course, when I uninstalled the runtime (so I could get the exact error for you), it still launches just fine. My system's a mess. I'll edit out my previous comment.
Glad to hear that! :)
I never even knew about this and I dont think anyone else did either.
I think its an awesome tool.