Thanks so much for this release @sgold
1 Like
I think it would be nice to have PR #881 on this beta. The behavior of joystick buttons on LWJGL3 is different of how it used to be on LWJGL2. #881 fixes it.
More about the issue here: [SOLVED] ActionListener: onAction called for no reason - #8 by Pesegato
By the way, it is not solved (I don’t think it’s solved until it’s fixed on the official jME).
1 Like
@fba It seems pr #881 has a failing check !?
https://github.com/jMonkeyEngine/jmonkeyengine/pull/881
1 Like
That’s right, it says AppVeyor was unable to build non-mergeable pull request. I don’t know what’s causing this. I tried some workarounds that I found on some forums over the internet, like closing and re-opening the request or editing the file and commiting it again, but none of these worked. Can anyone help me with this?
You could try redoing the change and only changing the part that needs changing… instead of redoing imports, converting static * imports, etc… Perhaps it will merge easier if there is less to merge (and anyway it’s a good practice anyone to only change what you are actually changing.)
Edit: yeah, looking at it in the conflict tool it seems like all of the merge conflicts are related to the things that were changed that didn’t even need changing.
1 Like
It looks like that was something my IDE (Eclipse) did to me. Anyway, I changed now only what’s really important and the AppVeyor message persists.
Yes, because the commits aren’t flattened or anything… so you get the original big commits that have merge conflicts and then your commit that undoes that commit.
There should be a way to flatten the PR, I guess. I’ve never done it.
It seems like the problem has something to do with the depth value on the appveyor.yml file. I forked the jME repository and removed the clone_depth: 1 line and it seems to work.
Generally, we would rather merge flattened PRs, though. If you can please figure out how to flatten it then we are more likely to merge it.
I mean, you may be right about that setting but it doesn’t change the fact that we’d rather not merge PRs that are many commits, some of which are just undoing the other ones… it makes the history look really strange.
1 Like
In Github, you can just select “stash and merge” from the merge button drop-down, that’s what flattens the PRs.
Not sure how easy fba can flatten them on his own, probably involves force pushing the branch or rather simply open a new branch/pr with the changes.
But the first method doesn’t work here due to merge conflicts unfortunately
1 Like
I thought there was a way for contributors to flatten their own PRs… if not then that’s dumb and I wonder how others were able to do it.
Anyway, I guess closing the PR and making a new one is the only option in the shitty git software.
2 Likes
Certainly not the only version but always the most simple one
I closed the problematic PR and opened a new one, now everything is okay. The new PR is #980.
1 Like
I’m back online after a 5-day absence.
I hope people have begun testing the beta1 release. I’ll begin testing tonight, but I’m not equipped to test on Linux, OSX, or Android platforms. I’d appreciate some help.
Regarding PR 980, I’m curious: how long has the issue existed in jMonkeyEngine?
2 Likes
Pretty sure that 980 is lwjgl3 specific… so “not long” in the geologic sense but also probably doesn’t affect many people one way or the other yet since extra steps are required to use lwjgl3 “out of the box”
2 Likes
I’ve been running my project in Win & Linux without any hiccups. LWJGL 3.
1 Like
There is, but it’s slightly messy, and can occasionally come across as… Rude…
What you do is run a git rebase -i <parent-commit> on your local branch, squashing and reordering commits as necessary. Then you git push --force to over-write the PR branch.
Be careful!
You only really want to do this right before merging a PR, or if everyone involved is on board. If someone tries to pull from the branch after your do this, they will likely have a merge mess in their local repo unless they cleaned out the old commits first…
1 Like
Yeah, push --force is ugly. It can cause all kinds of issues if everyone isn’t on board with it.
For this fix to be included in 3.2.2, it should’ve been in the master branch prior to Step 6:
Step 6 took place on 21 December.
An exception could be made if enough people asked for one, but so far I haven’t seen that for PR 980.
If JME 3.3 isn’t released in the next couple months, then there probably ought to be a 3.2.3 release. I see no reason PR 980 couldn’t be in JME 3.2.3 .
3 Likes
Great work! I for one appreciate the releases very much. Also tells that the project is alive and well. Lowers the threshold to take the engine out for a spin. When answer to your every question of “how I use feature x” is “just use the master”… Those without the stomach for this place must move on…
1 Like