-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix bug in spawn_util #405
Conversation
Return False not True in order to skip the current file (this_file)
So it seems it was just a case of a logic error. If the version of 'afile' is greater than the blender version, then this is the version that should be used. 'this_file' should be discarded, so False should be returned This works in blender 2.93.15 now. However, this is the only version that I have tested it with |
Wow not sure how that snuck through. I do find it rather confusing though that I can't produce the error locally - but this indeed works for you locally? Can you share a screenshot of your hostile mobs folder to show all files present? And thanks a million for diving in and proactively making a PR, hoping we can approve and merge this today (just bear with me while I attempt another live test later). |
I'm away from the machine where I did the testing, so I can't take screenshots now (it's a college computer). However, I can confirm from memory that there were three warden rigs in the hostile mobs folder - pre-2.8.0, pre-3.0.0 and an unversioned one. Reload mobs worked on blender 3.4, and I downloaded 2.93 specifically to test the error, and that's the screenshot in #403. I can also confirm that after the changes, reload mobs worked in blender 3.3 and 2.93, when I tested it with the changes on my own machine. I can only imagine there's a discrepancy between the rigs we have or the blender versions we're using... |
Thanks for sharing the details. Do you remember the detail of whether it was an MCprep upgrade or a fresh install in that 2.93 instance? I'm looking back, we had this line of code/entire function last modified ahead of the 3.4.0 release - which was the same release that the warden was introduced (#318) with 3 split up files even at that time. Even the lines of code where we call Furthermore, testing this change just based on our unit tests, I actually start getting this assertion to fail in our unit test runner. It's true there could be something wrong with the unit test, but I need to figure out first what is going wrong better. Also, I head turned slightly - funny that pull/405 is for issue 403, so close to being one and the same! |
Alright, I've figured out the culprit - the algorithm is too greedy it seems up front in returning "true, is eligible", and shouldn't really be exiting early until it's tested all files in the list. I'm going to check out your branch and make some contributions, so you can still get the code contribution credit, just be aware I'm making a number of changes. I'm creating a new unit test called Still doesn't explain why this hasn't been an issue till now, but I at least understand where things are going wrong. Could always be the order that files were listed or loaded in rig lists? So it more just happened to work before. |
OK, so when I ran it in 2.93, I ran it from pycharm. I cloned the repo to my projects folder. From a while back, I had copied the mcprep_resources from the 3.4.1 addon to this repo. I used a pycharm plugin blend charm to mark the mcprep addon dir as a blender addon which meant I could run/debug the addon from the ide. The plugin installs the addon to the instance of blender you are using when you hit run. So if you were hoping I used a conventional method of running blender, I didn't. It would be curious to see, though, if its just the order of the blend files in the folder that causes some users to get an error as you were saying, or maybe the way different os handle spaces in filenames? |
If we find a versioned file with the same basename, check recursively to see if it's eligible. If it's not, we have to allow for a check to see if there are any more versioned files that are eligible. The previous version only allowed for one check, and could return a result without finding an eligible versioned file, even if there was an eligible versioned file (unchecked), so the previous fix could still have produced incorrect result. If we do find an eligible versioned file, we can return False, because we want that file to be used instead. Otherwise we can just continue to the next iteration for the next check. If there are no eligible versioned files, it will fall through to return True anyway.
Ok. After another look, I realised that the code only allowed for 1 check for an eligible versioned file, even if there were two. So I guess my previous fix just happened to work because of the order of the files in the list. The new fix should work, regardless of the order of the files, as it was originally intended to do. At this stage, I wouldn't be surprised at all if the error had only popped up depending on the order of the files in the list. I wonder if a simple sort() would have worked as a hacky fix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly some stuff regardding comments, but otherwise looks good
Thanks for reviewing, and @CFeeney333 for making further changes. I'm going to ask to hold on for a bit until I can tack on a couple changes I've made and am continuing on with locally, I agree with your assessment of it being more chance that it was working at all before. |
Previously this function would try to exit early true after only inspecting this_file on its own, when in reality it would always need to compare against all files in the list.
Hey @CFeeney333 can you give me write/push access to your MCprep fork? Then I can push my one commit up and we can merge, and you'll appear in the history correctly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So of course I'd approve the changes I've made. Seeking input from @StandingPadAnimations
I don't like how complicated I made this function become, but even after spending some time looking at it, I didn't see a way to (substantially) simplify it. We have to look at all filenames in the list before we can determine if this_file should return true. That was really the crux of the issue before, it was returning true (I imagine) for the warden.blend
when it hadn't yet checked to see if it should prefer warden pre3.0.0.blend
. Unit tests now demonstrate this working as intended.
# If no matches (the most common case), then this file is eligible. | ||
return True | ||
res = util.min_bv(tuple_ver, inclusive=True) | ||
if res is False: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inclusive
is set to True
by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, I spent a lot of time starting and it and it ended up helping me read it having the argument specifically there. I nearly just removed the function call in favor of bpy.app.version to make it easier to read, but we can do that in the 3.5 release (even though bpy.app.version is safely available in 2.79, no reason to break the compatibility lower just for this).
sorted_eligible = sorted(other_eligible, key=lambda x: x[0]) | ||
latest_allowed = None | ||
for tple, afile in sorted_eligible: | ||
if util.min_bv(tple, inclusive=True) is False: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll have to look further in depth later today, but here's the things I found at this moment
FYI @StandingPadAnimations likely to merge tomorrow, no sweat if you don't have time. Happy to hear input too from you @CFeeney333 to verify this still makes it work well on your side, that would actually be a good sanity check since I still have yet to produce the error myself. |
Whoops, forgot about this. Looking over it again I think it should be fine to merge (we can ignore min_bv for now, I'll be doing some version check changes in 3.5 anyway) |
Darn, even with my unittest still not working. I'm quite sure though we still need to loop over files. Thanks for the screenshot, I've extract that and will do some more testing on it today, creating or updating the test script. |
This test now correctly fails on older versions of blender, while it passes on 3.0 and up, it fails under 2.90.
Alright, this is progress at least: The unit tests now fail for the expected versions of blender, consistent with your screen recording (even though blender 2.93 still works fine for me). Next stop: Actually making the function work as expected. Test results csv
This is after running the command I realize the "run all" control does not exist yet in the windows bat script, so one would have to manually specify the first entry in their
|
Wait, the occasion that the exception occurs is the code without the changes. You are aware of that? ie. doesn't that mean the function now works as expected? (The exception occurs on my master branch as I hadn't merged the changes) I just noticed in the test results it says the rig is by 'DiaDanAnimates' and not 'DigDanAnimates'. Does that mean anything? |
TBH surprised this was the only typo from my image-to-text copy.
Alright I take it back, the only reason my tests were failing was because I had a typo in the rig list I copied from you (my image-to-text reader picked up @CFeeney333 I'm really hoping this is somehow it was not working on your machine due to I don't want to push this release out if we think this isn't working. And I know the original logic was flawed for sure, it needs to operate over the entire list before checking if a given file is the right one. So even though your initial change was working for you, I believe it's still only by chance in essence (no different to how it was working before). Though let me know if you somehow see it differently and I'm misreading all of this still somehow. |
OH just now saw this, totally misunderstood that! So, to your understanding, it's all working now? And yes, twas a typo. |
No worries. Yes, it's all working now... sorry for any confusion |
Return False not True in order to skip the current file (this_file)