Thanks, that’d be appreciated; git bisect is your friend here, which does the binary search for you. You can start by marking the current revision as “bad” and “v1.10.5” as “good”.
Alternatively, you can try pip-installing the various “1.10.6.devX” builds from here: https://archive.panda3d.org/branches/release/1.10.x/panda3d/
I am happy to poke the buildbot to generate a dev wheel for any previous commit, if that makes things easier.
Still, if you shared any pointers on how the issue manifests itself, I may be able to offer suggestions of which commits may be related.
Ooh, I’d completely forgotten about that feature! Thank you for mentioning it–I’ll very likely use it!
Hmm… That’s tempting–it would save my rebuilding each time…
Still, I think that I feel slightly more comfortable with the other method: I remain uncertain when using Git, but by rebuilding myself I’ll feel more confident of which commit is being tested, that I’m not mistakenly testing a Python 2 version, and won’t have to poke you to build additional wheels!
It’s a slow way, but I’m tired today and so don’t mind taking things easy a little bit.
Sure!
As you may recall, in A Door to the Mists the player can climb various objects. In the level after the prologue, there’s an area that is essentially a “pit”, with stone ledges that the player can climb onto. Most of this works as expected–save for one specific ledge, which the character under 1.10.6 refuses to catch on to.
Via some printouts placed in my climbing logic, it seems that a particular ghost-collider, intended to detect the presence of too low a ceiling when attempting a climb, is somehow colliding with the ledge that the player is trying to climb. This causes it to think that there’s a ceiling in the way, and so to refuse to climb.
Ah, I think we did actually update Bullet in the thirdparty packages:
However, this was late December, and so the fix should have been applied.
To make sure that the problem is in Panda3D and not in one of the thirdparty packages, I would suggest building both v1.10.5 and v1.10.6 before you start building other commits.
How would I build 1.10.5, if not by reverting to an older commit of the 1.10.x line?
[edit]
Okay, this is weird: I built 1.10.5 from source, cloned from GitHub–and the problem showed up under that version.
You mentioned an update in the version of Bullet being used–could the wheel of 1.10.5 have been using the old version, and the wheel of 1.10.6 and the cloned build of 1.10.5 have been using the newer one?
[edit 2]
In case it’s relevant, I believe that my 1.10.5 build used the commit with hash da0fe8be3eb91873e73a04b552b968a42ccabbdc, and the commit-message “readme: change link to 1.10.5 release”. If I’m not much mistaken that should be this one.
[edit 3]
I’m going to switch to installing the wheels that were linked-to earlier; perhaps that’ll provide more insight…
[edit 4]
Update:
It looks like the problem appeared in the wheels between the following two:
Last working: panda3d-1.10.6.dev11-cp36-cp36m-manylinux1_x86_64
First non-working: panda3d-1.10.6.dev26-cp36-cp36m-manylinux1_x86_64
If I’m correct in associating the value in the download URL that comes after “download/” with the id-number of a given commit, then the issue would appear to have been introduced between January 21st of this year and February 22nd of this year, possibly inclusive.
Unfortunately there don’t seem to be Linux 64-bit builds between those two points (only one 32-bit build, which pip3 doesn’t seem to want to install), so I don’t have a narrower frame yet…
Looks like I actually merged that PR 29 days ago. That’s around 22 Feb. Ahhh, shoot.
I guess this is why we really shouldn’t update thirdparty packages in minor releases.
What to do, what to do… Maybe I should just downgrade Bullet and rebuild the wheels? I can’t update the ones on PyPI, though, not without making a -post1 version number. Maybe that’s for the best, though.
I wonder what change was made in Bullet that incurred this issue. If it’s something that’s not too difficult to work around, perhaps it would be better that I accommodated it in my code. After all, is it feasible for me to avoid the update for the rest of the game’s development?
Sure! I’ll give that a shot, and report back, I intend!
[edit]
Okay, the build is done and installed, and indeed, the issue seems to no longer be present in that build!
So, where does this leave us going forward, in particular with regard to future versions of the engine?
I was about to ask whether you had tried the changes yet, and then I noticed your edit. Discourse doesn’t send out notifications about edited posts. It is generally fine to make a new reply to a thread if it adds substantially new information, or if people might otherwise benefit from getting a new notification.
If it works, then I’ll go and push the new builds to PyPI ASAP. I think pip will prefer the .post1 version automatically, so the right things should happen.
We’ll reconsider the Bullet upgrade for 1.11.0. Maybe by then, the bug will already have been fixed in Bullet.
Ah, fair enough, on all counts–I saw that it updated the “latest posts” view, so I though that an edit would be sufficiently visible. I’ll try to remember in future to prefer double-posting here for such purposes!
Fair enough, on all counts! And thank you for this.
In the meantime Bullet made a new release, 2.89, so hopefully it is more stable than a snapshot mid development.
For the future it might be useful to freeze modifications and create a release candidate build maybe one month before a new maintenance release, so one can test if the future new release will not break anything in their game or app.
I think we should be tagging and branching the panda3d-thirdparty repo, and being very careful not to update upstream libraries that are prone to breakage (like Bullet, which is almost always the culprit with this sort of issue) in a release branch.
Or, we should just put the contents of the panda3d-thirdparty repo into the main panda3d repo.
@Thaumaturge I’ve uploaded Linux wheels for Panda3D 1.10.6.post1 to PyPI. I think other platforms are unaffected, so they can just continue using 1.10.6.
I think deploy-ng should automatically grab 1.10.6.post1+opt as well, but I’m not 100% sure.
Ah, thank you very much! I can confirm that both Pip and deploy-ng seem to take what seem to be the appropriate wheels:
“panda3d-1.10.6.post1-cp36-cp36m-manylinux1_x86_64.whl” for Pip, and
“panda3d-1.10.6.post1+opt-cp36-cp36m-manylinux1_x86_64.whl” for deploy-ng
I’m surprised: was Bullet only updated in the third-party package for one platform?
Hmm… I’m not sure that this would necessarily help in the case of large or complex projects: one won’t necessarily discover lurking bugs so quickly. In this particular case, I only discovered the issue in question because I happened to try climbing in a spot that happened to be affected by it; climbing in other places had worked.
That said, the same is true for all such changes, so I don’t think that this is an argument for not updating at all.
In addition, I’m not sure of how I feel about having to rigorously test every feature for every minor release. Major releases would be another matter, of course.
That looks like very good progress, and I’m glad to read of it! Well done to all the devs, and thank you for all of your work on Panda3D!
Also, congratulations to the new part-time dev, D. Lawrence, on their appointment, and to Ashwini Jha for having their Summer of Code project selected.
