Fix a number of crashes involving unknown nodes, also fix fishbuckets on_place #3914

MrRar · 2023-09-03T20:07:48+02:00

MrRar commented

2023-09-03 20:07:48 +02:00

~~You can reproduce the crash by placing a fish bucket on top snow above an unknown node.

I also noticed that the code always uses pointed_thing.above so I fixed that and also added a function to mcl_utils to figure out where a node should be placed (either above or below). Looks like the rest of the code could also use improvement but at least it does not crash now.~~

Cora fixed a bunch of related crashes in Mineclona so I am replacing my commit and cherry picking all her commits here.
https://codeberg.org/mineclonia/mineclonia/pulls/549

Here is the list of fixes from that PR:

Crash when placing snow layer on unknown nodes
Crash when snow layers on unknown nodes are flooded
Crash when placing fishbucket on snow on top of unknown nodes
Crash when placing chorus flower and stem on unknown
Crash when placing mob spawners on unknown
The fishbucket on place to actually replace buildable_to

Fixes: #3913 #3915 ~~You can reproduce the crash by placing a fish bucket on top snow above an unknown node. I also noticed that the code always uses pointed_thing.above so I fixed that and also added a function to mcl_utils to figure out where a node should be placed (either above or below). Looks like the rest of the code could also use improvement but at least it does not crash now.~~ Cora fixed a bunch of related crashes in Mineclona so I am replacing my commit and cherry picking all her commits here. https://codeberg.org/mineclonia/mineclonia/pulls/549 Here is the list of fixes from that PR: - Crash when placing snow layer on unknown nodes - Crash when snow layers on unknown nodes are flooded - Crash when placing fishbucket on snow on top of unknown nodes - Crash when placing chorus flower and stem on unknown - Crash when placing mob spawners on unknown - The fishbucket on place to actually replace buildable_to

👍 2 🚀 1

MrRar force-pushed fish from 61357a9ee3 to 43377ee4b9

2023-09-04 20:23:25 +02:00

Compare

MrRar changed title from ~~Fix fish buckets crash on place~~ to Fix a number of crashes involving unknown nodes, also fix fishbuckets on_place

2023-09-04 20:31:24 +02:00

ancientmarinerdev reviewed 2023-09-05 01:44:32 +02:00

ancientmarinerdev left a comment

Looks sensible for the most part, we should always check a def is there before trying to use it as there is no guarantee. I did highlight one change that may need a double check.

mods/ITEMS/mcl_buckets/fishbuckets.lua Outdated

					
				@ -28,0 +22,4 @@

					local pos = pointed_thing.above

					local n = minetest.get_node(pointed_thing.above)

					local def = minetest.registered_nodes[minetest.get_node(pointed_thing.under).name]

ancientmarinerdev commented

2023-09-05 01:40:48 +02:00

pos was pointed_thing.above, but for def, we pull pointed_thing.under, so it looks like this has semantically changed. Is that intentional?

MrRar commented

2023-09-05 15:05:30 +02:00

Yes. If under has the buildable_to property it will be used otherwise it uses above. buildable_to would be used for replaceable nodes like top snow. If above is used unconditionally, top snow will not be replaced when a fish bucket is placed on it.

Emojigit referenced this pull request

2023-09-11 14:35:43 +02:00

[mcl_buckets] Check whether node is nil for fishbuckets #3930

ancientmarinerdev approved these changes 2023-09-29 20:45:17 +02:00

ancientmarinerdev left a comment

Thanks for raising the PR.

👍 1

ancientmarinerdev added this to the 0.85.0 - Fire and Stone milestone 2023-09-29 20:45:30 +02:00

ancientmarinerdev added the

#P1 CRITICAL

label 2023-09-29 20:45:39 +02:00

ancientmarinerdev force-pushed fish from 43377ee4b9 to 1bbd4c6f62

2023-09-29 20:46:45 +02:00

Compare

ancientmarinerdev referenced this issue from a commit

2023-09-29 20:47:10 +02:00

Fix a number of crashes involving unknown nodes, also fix fishbuckets on_place (#3914)

ancientmarinerdev merged commit a620d24ec8 into master

2023-09-29 20:47:11 +02:00

ancientmarinerdev deleted branch fish

2023-09-29 20:47:15 +02:00

ancientmarinerdev commented

2023-09-29 20:48:01 +02:00

Squash merged this as I cannot see why it shouldn't be 1 commit.

👎 3

cora commented

2023-09-29 23:40:17 +02:00

The reason why it shouldn't be 1 commit: If someone want's to bisect an issue at a later point it's going to be a lot easier if they don't end up with 1 huge commit where they have to sort out what broke it but that is your problem.

But if you squash because you feel the amount of commits is a matter of aesthetics at least preserve the authorship. I did not "co-author" this. I made every single commit.

If I used this logic I could credit myself for every upstream PR I make in mineclonia.

The reason why it shouldn't be 1 commit: If someone want's to bisect an issue at a later point it's going to be a lot easier if they don't end up with 1 huge commit where they have to sort out what broke it but that is your problem. But if you squash because you feel the amount of commits is a matter of aesthetics at least preserve the authorship. I did not "co-author" this. I made every single commit. If I used this logic I could credit myself for every upstream PR I make in mineclonia.

❤️ 2

ancientmarinerdev commented

2023-09-30 23:48:42 +02:00

The reason why it shouldn't be 1 commit: If someone want's to bisect an issue at a later point it's going to be a lot easier if they don't end up with 1 huge commit where they have to sort out what broke it but that is your problem.

There is only 1 logical place this could likely go wrong, and squashing won't change that. Absolutely no harm can come from checking the def is there.

But if you squash because you feel the amount of commits is a matter of aesthetics at least preserve the authorship. I did not "co-author" this. I made every single commit.

If I used this logic I could credit myself for every upstream PR I make in mineclonia.

Whatever it said was the default, I clicked. I'll double check next time. I didn't realise it would be an issue. You'll get the full credits in the release. It's all your work. I have no issue with you getting credit and I appreciate you fixing this.

You've virtually rewritten every PR I've put in so far, with some snarky comment. It's quite amusing how much disdain you have for me. You've also unnecessarily squashed most MCL2 PRs. Of all the things you could throw at us, I'm surprised you're taking this line ;). I don't mind. The amount of work you created for yourself through this has been quite something. It's your time though, and if you want to spend it that way, you're free to.

> The reason why it shouldn't be 1 commit: If someone want's to bisect an issue at a later point it's going to be a lot easier if they don't end up with 1 huge commit where they have to sort out what broke it but that is your problem. > There is only 1 logical place this could likely go wrong, and squashing won't change that. Absolutely no harm can come from checking the def is there. > But if you squash because you feel the amount of commits is a matter of aesthetics at least preserve the authorship. I did not "co-author" this. I made every single commit. > > If I used this logic I could credit myself for every upstream PR I make in mineclonia. > Whatever it said was the default, I clicked. I'll double check next time. I didn't realise it would be an issue. You'll get the full credits in the release. It's all your work. I have no issue with you getting credit and I appreciate you fixing this. You've virtually rewritten every PR I've put in so far, with some snarky comment. It's quite amusing how much disdain you have for me. You've also unnecessarily squashed most MCL2 PRs. Of all the things you could throw at us, I'm surprised you're taking this line ;). I don't mind. The amount of work you created for yourself through this has been quite something. It's your time though, and if you want to spend it that way, you're free to.

cora commented

2023-10-01 01:57:37 +02:00

What you say clearly shows that you have not read a whole lot of it.

But just about everything you say is 100% besides the point. I have credited you and evryone else for every single thing I have backported while you gladly take my work but stick other people's names on it. And don't pretend like anyone else was involved in doing this by saying "us". You did this completely by yourself.

What you say clearly shows that you have not read a whole lot of it. But just about everything you say is 100% besides the point. I have credited you and evryone else for every single thing I have backported while you gladly take my work but stick other people's names on it. And don't pretend like anyone else was involved in doing this by saying "us". You did this completely by yourself.

ancientmarinerdev commented

2023-10-01 03:45:32 +02:00

I clicked the squashed merge button, then clicked merge on the auto-generated message. Chill.

26 additions, 14 deletions. 12 lines added. 7 commits. 1.7 lines per commit. I think you're a little too fixated on being top of the number of commits, and it means absolutely nothing. There are no prizes, no medals in open source. You simply contribute code to software people enjoy.

If you're objecting to me suggesting you're throwing unnecessary rubbish at the project, and it's specifically me you're talking to. It seems you're suggesting your focus is not on the action, but on me. I guess this has been personal to you for a little bit too long. 10 months now. You do realise anger you hold consumes you more than it ever consumes the person you're angry about. It's time to move on. Let it go. Be kind to yourself.

I clicked the squashed merge button, then clicked merge on the auto-generated message. Chill. 26 additions, 14 deletions. 12 lines added. 7 commits. 1.7 lines per commit. I think you're a little too fixated on being top of the number of commits, and it means absolutely nothing. There are no prizes, no medals in open source. You simply contribute code to software people enjoy. If you're objecting to me suggesting you're throwing unnecessary rubbish at the project, and it's specifically me you're talking to. It seems you're suggesting your focus is not on the action, but on me. I guess this has been personal to you for a little bit too long. 10 months now. You do realise anger you hold consumes you more than it ever consumes the person you're angry about. It's time to move on. Let it go. Be kind to yourself.

cora commented

2023-10-01 04:52:55 +02:00

You can read into this, or frame it any way you like.

If you absolutely felt like this had to be squashed you should have done so doing an interactive rebase of the branch instead of "just clicking the merge button". However, you clearly do not apply these standards to other PRs.

Maybe you should let it go lol.

You can read into this, or frame it any way you like. If you absolutely felt like this had to be squashed you should have done so doing an interactive rebase of the branch instead of "just clicking the merge button". However, you clearly do not apply these standards to other PRs. Maybe you should let it go lol.

cora commented

2023-10-01 05:14:33 +02:00

At least the commit message clearly shows the history of this. I guess i believe you when you claim incompetence instead of malevolence; it just looks kind of weird when you do it while saying how much of a professional you are every chance you get.

I just don't get why you are seemingly incapable of admitting a mistake of even just apologizing. If you weren't so damn self righteous every single time it would be a lot easier to deal with you.

If you had simply said "I'm sorry i just clicked squash-merge" or whatever it would have been fine.

At least the commit message clearly shows the history of this. I guess i believe you when you claim incompetence instead of malevolence; it just looks kind of weird when you do it while saying how much of a professional you are every chance you get. I just don't get why you are seemingly incapable of admitting a mistake of even just apologizing. If you weren't so damn self righteous every single time it would be a lot easier to deal with you. If you had simply said "I'm sorry i just clicked squash-merge" or whatever it would have been fine.

erlehmann commented

2023-10-01 11:13:02 +02:00

You've also unnecessarily squashed most MCL2 PRs. Of all the things you could throw at us, I'm surprised you're taking this line ;)

The most you could prove with this line would be that @cora may be a hypocrite, but not that she is factually wrong.

1.7 lines per commit. I think you're a little too fixated on being top of the number of commits, and it means absolutely nothing.

From my POV @cora is doing stuff that makes it easier to diagnose and fix regressions in the future – and you are not.

Squash merge is basically making it harder to debug and fix stuff in the future. Not impossible, just a bit harder.

Imagine you find a bug in one of the commits that you squashed – you can not simply do git revert on it.

I guess i believe you when you claim incompetence instead of malevolence; it just looks kind of weird when you do it while saying how much of a professional you are every chance you get.

I think how and when people use squash merge has something to do with how much they care about future maintenance.

To me, @ancientmarinerdev does not seem like a person who values maintainability as much as I do. So it makes sense!

Furthermore: At work I figured out that there exist people who never use git bisect, claiming that it is basically useless. These people all use squash merge. The people who do use git bisect tend to not use squash merge. Both are self-perpetuating scenarios – if you use squash merge, git bisect becomes useless.

In the case of my co-workers, using squash merge could be partially justified by mobile app developers, because AFAIK the platform APIs change so often that dealing with regressions often means ripping out a lot of code and replacing that. On the other hand I have yet to meet an embedded developer at work who chooses squash merge, they advocate rebasing their stuff.

> You've also unnecessarily squashed most MCL2 PRs. Of all the things you could throw at us, I'm surprised you're taking this line ;) The most you could prove with this line would be that @cora may be a hypocrite, but not that she is factually wrong. > 1.7 lines per commit. I think you're a little too fixated on being top of the number of commits, and it means absolutely nothing. From my POV @cora is doing stuff that makes it easier to diagnose and fix regressions in the future – and you are not. Squash merge is basically making it harder to debug and fix stuff in the future. Not impossible, just a bit harder. Imagine you find a bug in one of the commits that you squashed – you can not simply do `git revert` on it. > I guess i believe you when you claim incompetence instead of malevolence; it just looks kind of weird when you do it while saying how much of a professional you are every chance you get. I think how and when people use squash merge has something to do with how much they care about future maintenance. To me, @ancientmarinerdev does not seem like a person who values maintainability as much as I do. So it makes sense! Furthermore: At work I figured out that there exist people who never use `git bisect`, claiming that it is basically useless. These people all use squash merge. The people who do use `git bisect` tend to not use squash merge. Both are self-perpetuating scenarios – if you use squash merge, `git bisect` becomes useless. In the case of my co-workers, using squash merge could be partially justified by mobile app developers, because AFAIK the platform APIs change so often that dealing with regressions often means ripping out a lot of code and replacing that. On the other hand I have yet to meet an embedded developer at work who chooses squash merge, they advocate rebasing their stuff.

ryvnf commented

2023-10-01 13:05:06 +02:00

If you're objecting to me suggesting you're throwing unnecessary rubbish at the project, and it's specifically me you're talking to. It seems you're suggesting your focus is not on the action, but on me. I guess this has been personal to you for a little bit too long. 10 months now. You do realise anger you hold consumes you more than it ever consumes the person you're angry about. It's time to move on. Let it go. Be kind to yourself.

You suggest that @cora has a malevolence towards MineClone 2, ignoring the fact that she has done a lot of work reviewing MineClone 2 contributions and pointing out serious things like duping and potential item metadata injection exploits, even though she is the owner of a competing project in a sense.

> If you're objecting to me suggesting you're throwing unnecessary rubbish at the project, and it's specifically me you're talking to. It seems you're suggesting your focus is not on the action, but on me. I guess this has been personal to you for a little bit too long. 10 months now. You do realise anger you hold consumes you more than it ever consumes the person you're angry about. It's time to move on. Let it go. Be kind to yourself. You suggest that @cora has a malevolence towards MineClone 2, ignoring the fact that she has done a lot of work reviewing MineClone 2 contributions and pointing out serious things like duping and potential item metadata injection exploits, even though she is the owner of a competing project in a sense.

ancientmarinerdev commented

2023-10-01 15:06:05 +02:00

A pile on. 2 friends join in. I'm getting Kabou vibes here.

You've also unnecessarily squashed most MCL2 PRs. Of all the things you could throw at us, I'm surprised you're taking this line ;)

The most you could prove with this line would be that @cora may be a hypocrite, but not that she is factually wrong.

1.7 lines per commit. I think you're a little too fixated on being top of the number of commits, and it means absolutely nothing.

From my POV @cora is doing stuff that makes it easier to diagnose and fix regressions in the future – and you are not.

Squash merge is basically making it harder to debug and fix stuff in the future. Not impossible, just a bit harder.

Imagine you find a bug in one of the commits that you squashed – you can not simply do git revert on it.

I guess i believe you when you claim incompetence instead of malevolence; it just looks kind of weird when you do it while saying how much of a professional you are every chance you get.

I think how and when people use squash merge has something to do with how much they care about future maintenance.

To me, @ancientmarinerdev does not seem like a person who values maintainability as much as I do. So it makes sense!

Furthermore: At work I figured out that there exist people who never use git bisect, claiming that it is basically useless. These people all use squash merge. The people who do use git bisect tend to not use squash merge. Both are self-perpetuating scenarios – if you use squash merge, git bisect becomes useless.

In the case of my co-workers, using squash merge could be partially justified by mobile app developers, because AFAIK the platform APIs change so often that dealing with regressions often means ripping out a lot of code and replacing that. On the other hand I have yet to meet an embedded developer at work who chooses squash merge, they advocate rebasing their stuff.

Weird take, and I'm surprised it is from you, because usually your analysis is good, even if your conclusions are on the paranoid side of risk averse. Did you see the code? Changing:

if def._mcl_snowless then

to:

if def and def._mcl_snowless then

Any programmer worth their salt would view them as non-changes. They are defensive and much safer. They ARE not going wrong, and if they are, the stack trace is going to be well easy to fix. However, Cora usually tests every change, so I'm quite confident it hasn't gone wrong. I see no possible future where that will every need bisecting. Cora squash merges a lot more stuff with a higher complexity value, so unfortunately as Knight in Shining Armour mk 2, you've thrown a lotta shade on Cora there. In fact when MCLA started, one of the biggest stated criticisms of MCL2 was that we didn't squash merge and git history was a mess. You've virtually just smashed Cora's project and approach...

I think you probably need to spend more time around mcla than here if your goal is to support Cora. I don't think your intentions here are to help us.

A pile on. 2 friends join in. I'm getting Kabou vibes here. > > You've also unnecessarily squashed most MCL2 PRs. Of all the things you could throw at us, I'm surprised you're taking this line ;) > > The most you could prove with this line would be that @cora may be a hypocrite, but not that she is factually wrong. > > > 1.7 lines per commit. I think you're a little too fixated on being top of the number of commits, and it means absolutely nothing. > > From my POV @cora is doing stuff that makes it easier to diagnose and fix regressions in the future – and you are not. > > Squash merge is basically making it harder to debug and fix stuff in the future. Not impossible, just a bit harder. > > Imagine you find a bug in one of the commits that you squashed – you can not simply do `git revert` on it. > > > I guess i believe you when you claim incompetence instead of malevolence; it just looks kind of weird when you do it while saying how much of a professional you are every chance you get. > > I think how and when people use squash merge has something to do with how much they care about future maintenance. > > To me, @ancientmarinerdev does not seem like a person who values maintainability as much as I do. So it makes sense! > > Furthermore: At work I figured out that there exist people who never use `git bisect`, claiming that it is basically useless. These people all use squash merge. The people who do use `git bisect` tend to not use squash merge. Both are self-perpetuating scenarios – if you use squash merge, `git bisect` becomes useless. > > In the case of my co-workers, using squash merge could be partially justified by mobile app developers, because AFAIK the platform APIs change so often that dealing with regressions often means ripping out a lot of code and replacing that. On the other hand I have yet to meet an embedded developer at work who chooses squash merge, they advocate rebasing their stuff. Weird take, and I'm surprised it is from you, because usually your analysis is good, even if your conclusions are on the paranoid side of risk averse. Did you see the code? Changing: `if def._mcl_snowless then` to: `if def and def._mcl_snowless then` Any programmer worth their salt would view them as non-changes. They are defensive and much safer. They ARE not going wrong, and if they are, the stack trace is going to be well easy to fix. However, Cora usually tests every change, so I'm quite confident it hasn't gone wrong. I see no possible future where that will every need bisecting. Cora squash merges a lot more stuff with a higher complexity value, so unfortunately as Knight in Shining Armour mk 2, you've thrown a lotta shade on Cora there. In fact when MCLA started, one of the biggest stated criticisms of MCL2 was that we didn't squash merge and git history was a mess. You've virtually just smashed Cora's project and approach... I think you probably need to spend more time around mcla than here if your goal is to support Cora. I don't think your intentions here are to help us.

ancientmarinerdev commented

2023-10-01 15:12:14 +02:00

If you're objecting to me suggesting you're throwing unnecessary rubbish at the project, and it's specifically me you're talking to. It seems you're suggesting your focus is not on the action, but on me. I guess this has been personal to you for a little bit too long. 10 months now. You do realise anger you hold consumes you more than it ever consumes the person you're angry about. It's time to move on. Let it go. Be kind to yourself.

You suggest that @cora has a malevolence towards MineClone 2, ignoring the fact that she has done a lot of work reviewing MineClone 2 contributions and pointing out serious things like duping and potential item metadata injection exploits, even though she is the owner of a competing project in a sense.

You ignore the fact her best friend, Kabou spent months attacking the project on her behalf. The reason she reviews those PRs is because she pulls them into MCLA and she wants the original author to fix them for her.

I don't know you very well, but usually your analysis and decisions is pretty spot on. Got a lot of respect for that.

I'm just not sure if you realise that the reason MCLA exists was a personal grudge project and to rewrite history. Did you every wonder why it kicked off from 0.81.0 (the last release Cora was involved in), rather than fork from 0.82 or 0.83? It's all to rewrite history in Cora's head so she was never not the maintainer, and I never was. Hence why she spend months rewriting and redoing PR's that were already merge. A massive waste of time. I think eventually 4 or so weren't merged and it would have been so much easier just to put revert commits in and keep the repo's in line for compatibility.

From the outside, it is quite clear Cora is the maintainer and you're the acceptable face of the operation.

> > If you're objecting to me suggesting you're throwing unnecessary rubbish at the project, and it's specifically me you're talking to. It seems you're suggesting your focus is not on the action, but on me. I guess this has been personal to you for a little bit too long. 10 months now. You do realise anger you hold consumes you more than it ever consumes the person you're angry about. It's time to move on. Let it go. Be kind to yourself. > > You suggest that @cora has a malevolence towards MineClone 2, ignoring the fact that she has done a lot of work reviewing MineClone 2 contributions and pointing out serious things like duping and potential item metadata injection exploits, even though she is the owner of a competing project in a sense. You ignore the fact her best friend, Kabou spent months attacking the project on her behalf. The reason she reviews those PRs is because she pulls them into MCLA and she wants the original author to fix them for her. I don't know you very well, but usually your analysis and decisions is pretty spot on. Got a lot of respect for that. I'm just not sure if you realise that the reason MCLA exists was a personal grudge project and to rewrite history. Did you every wonder why it kicked off from 0.81.0 (the last release Cora was involved in), rather than fork from 0.82 or 0.83? It's all to rewrite history in Cora's head so she was never not the maintainer, and I never was. Hence why she spend months rewriting and redoing PR's that were already merge. A massive waste of time. I think eventually 4 or so weren't merged and it would have been so much easier just to put revert commits in and keep the repo's in line for compatibility. From the outside, it is quite clear Cora is the maintainer and you're the acceptable face of the operation.

ancientmarinerdev commented

2023-10-01 15:20:17 +02:00

At least the commit message clearly shows the history of this. I guess i believe you when you claim incompetence instead of malevolence; it just looks kind of weird when you do it while saying how much of a professional you are every chance you get.

I just don't get why you are seemingly incapable of admitting a mistake of even just apologizing. If you weren't so damn self righteous every single time it would be a lot easier to deal with you.

If you had simply said "I'm sorry i just clicked squash-merge" or whatever it would have been fine.

I have no concerns admitting mistakes and apologies. See here:

MineClone2/MineClone2#3949 (comment)

If I spent time apologising to you for every nitpick you had about what I had done, I wouldn't have time for anything else. If your concern was in good faith, I would absolutely do that. However, when you pick fault with everything I do, I inevitably put it down to you trying to going me a dressing down in public due to a grudge you still hold.

It was a genuine mistake, and I absolutely will not apologise after the way you approached it and led the dogpile with friends.

Since the start, you've bashed me as too slow. You can see I'm slower than I was at the start, and I have put in invitations for someone to take over on the code side. I have absolutely no time for interactive rebases. I just came in to quickly review and merge some code. I had no idea that the drama would ensue. I always give you the benefit of the doubt, and always hope when you focus on a technical issue this is over and in the past. My biggest mistake is constantly assuming you're here in good faith (in the hope eventually things would simmer down).

I think the safest assumption here is that you feel mega-wronged by what happened in the past and super angry. You see it all as a slight of your character and you will spend every waking minute trying to service that anger when it boils over (which it does as regular intervals).

> At least the commit message clearly shows the history of this. I guess i believe you when you claim incompetence instead of malevolence; it just looks kind of weird when you do it while saying how much of a professional you are every chance you get. > > I just don't get why you are seemingly incapable of admitting a mistake of even just apologizing. If you weren't so damn self righteous every single time it would be a lot easier to deal with you. > > If you had simply said "I'm sorry i just clicked squash-merge" or whatever it would have been fine. I have no concerns admitting mistakes and apologies. See here: https://git.minetest.land/MineClone2/MineClone2/pulls/3949#issuecomment-71954 If I spent time apologising to you for every nitpick you had about what I had done, I wouldn't have time for anything else. If your concern was in good faith, I would absolutely do that. However, when you pick fault with everything I do, I inevitably put it down to you trying to going me a dressing down in public due to a grudge you still hold. It was a genuine mistake, and I absolutely will not apologise after the way you approached it and led the dogpile with friends. Since the start, you've bashed me as too slow. You can see I'm slower than I was at the start, and I have put in invitations for someone to take over on the code side. I have absolutely no time for interactive rebases. I just came in to quickly review and merge some code. I had no idea that the drama would ensue. I always give you the benefit of the doubt, and always hope when you focus on a technical issue this is over and in the past. My biggest mistake is constantly assuming you're here in good faith (in the hope eventually things would simmer down). I think the safest assumption here is that you feel mega-wronged by what happened in the past and super angry. You see it all as a slight of your character and you will spend every waking minute trying to service that anger when it boils over (which it does as regular intervals).

cora commented

2023-10-01 16:02:42 +02:00

I think the safest assumption here is that you feel

you know what happens when you assume lol

maybe don't do that and simply listen to what i say and not what you think you can interpret (you are not good at it).

I clicked the squashed merge button, then clicked merge on the auto-generated message. Chill.

I have no concerns admitting mistakes and apologies.

"hey ancient a simple apology would have sufficed"

"SHUT UP! I AM THE BEST APOLOGIZER: LOOK HERE ON THIS UNRELATED OCCASION I TOTALLY APOLOGIZED"

:D

> I think the safest assumption here is that you feel you know what happens when you assume lol maybe don't do that and simply listen to what i say and not what you think you can interpret (you are not good at it). > I clicked the squashed merge button, then clicked merge on the auto-generated message. Chill. > I have no concerns admitting mistakes and apologies. "hey ancient a simple apology would have sufficed" "SHUT UP! I AM THE BEST APOLOGIZER: LOOK HERE ON THIS UNRELATED OCCASION I TOTALLY APOLOGIZED" :D

cora commented

2023-10-01 16:08:22 +02:00

You ignore the fact her best friend, Kabou spent months attacking the project on her behalf. The reason she reviews those PRs is because she pulls them into MCLA and she wants the original author to fix them for her.

mmmh why did i fix them before even posting it here then though? Again assuming without even trying to falsify your claims.

> You ignore the fact her best friend, Kabou spent months attacking the project on her behalf. The reason she reviews those PRs is because she pulls them into MCLA and she wants the original author to fix them for her. mmmh why did i fix them before even posting it here then though? Again assuming without even trying to falsify your claims.

cora commented

2023-10-01 16:11:29 +02:00

If I spent time apologising to you for every nitpick you had about what I had done, I wouldn't have time for anything else.

So you say posting all this stuff, whatever it is, takes less time than simply saying i'm sorry ?

> If I spent time apologising to you for every nitpick you had about what I had done, I wouldn't have time for anything else. So you say posting all this stuff, whatever it is, takes less time than simply saying i'm sorry ?

cora commented

2023-10-01 16:51:24 +02:00

You've also unnecessarily squashed most MCL2 PRs. Of all the things you could throw at us, I'm surprised you're taking this line ;)

The most you could prove with this line would be that @cora may be a hypocrite, but not that she is factually wrong.

I don't think i did it with "most" mcl2 PRs, I haven't checked but from what I remember it was just a few of them. And only when there was a git history like

Add thing
Fix issue with thing
Remove debug code in thing

However I did not do it in a way that changed the author. So this is kind of besides the point.

> > You've also unnecessarily squashed most MCL2 PRs. Of all the things you could throw at us, I'm surprised you're taking this line ;) > > The most you could prove with this line would be that @cora may be a hypocrite, but not that she is factually wrong. I don't think i did it with "most" mcl2 PRs, I haven't checked but from what I remember it was just a few of them. And only when there was a git history like * Add thing * Fix issue with thing * Remove debug code in thing However I did not do it in a way that changed the author. So this is kind of besides the point.

ryvnf commented

2023-10-01 17:31:14 +02:00

You ignore the fact her best friend, Kabou spent months attacking the project on her behalf. The reason she reviews those PRs is because she pulls them into MCLA and she wants the original author to fix them for her.

Would it really be preferable if MCL2 contributors get no chance to fix bugs by themselves and issues would just get silently fixed by her when backporting them to MCLA? I think that is the alternative here.

I'm just not sure if you realise that the reason MCLA exists was a personal grudge project and to rewrite history. Did you every wonder why it kicked off from 0.81.0 (the last release Cora was involved in), rather than fork from 0.82 or 0.83? It's all to rewrite history in Cora's head so she was never not the maintainer, and I never was. Hence why she spend months rewriting and redoing PR's that were already merge. A massive waste of time. I think eventually 4 or so weren't merged and it would have been so much easier just to put revert commits in and keep the repo's in line for

The reason MCLA exists is because I reached out to cora about reviving it after noticing that she was removed as maintainer of MCL2 and the project started to make decisions both of us did not agree with (hamburgers, music, etc). We forked from 0.83 because that was the last version without those features and we wanted to review all changes past that point.

From the outside, it is quite clear Cora is the maintainer and you're the acceptable face of the operation.

This is not true at all. Me and cora always discuss things and make decisions together. My experience working with her has always been positive.

Certainly you can see that you are making a lot of assumptions about her intentions here.

> You ignore the fact her best friend, Kabou spent months attacking the project on her behalf. The reason she reviews those PRs is because she pulls them into MCLA and she wants the original author to fix them for her. Would it really be preferable if MCL2 contributors get no chance to fix bugs by themselves and issues would just get silently fixed by her when backporting them to MCLA? I think that is the alternative here. > I'm just not sure if you realise that the reason MCLA exists was a personal grudge project and to rewrite history. Did you every wonder why it kicked off from 0.81.0 (the last release Cora was involved in), rather than fork from 0.82 or 0.83? It's all to rewrite history in Cora's head so she was never not the maintainer, and I never was. Hence why she spend months rewriting and redoing PR's that were already merge. A massive waste of time. I think eventually 4 or so weren't merged and it would have been so much easier just to put revert commits in and keep the repo's in line for The reason MCLA exists is because I reached out to cora about reviving it after noticing that she was removed as maintainer of MCL2 and the project started to make decisions both of us did not agree with (hamburgers, music, etc). We forked from 0.83 because that was the last version without those features and we wanted to review all changes past that point. > From the outside, it is quite clear Cora is the maintainer and you're the acceptable face of the operation. This is not true at all. Me and cora always discuss things and make decisions together. My experience working with her has always been positive. Certainly you can see that you are making a lot of assumptions about her intentions here.

ancientmarinerdev commented

2023-10-01 20:05:14 +02:00

You ignore the fact her best friend, Kabou spent months attacking the project on her behalf. The reason she reviews those PRs is because she pulls them into MCLA and she wants the original author to fix them for her.

Would it really be preferable if MCL2 contributors get no chance to fix bugs by themselves and issues would just get silently fixed by her when backporting them to MCLA? I think that is the alternative here.

I'm just not sure if you realise that the reason MCLA exists was a personal grudge project and to rewrite history. Did you every wonder why it kicked off from 0.81.0 (the last release Cora was involved in), rather than fork from 0.82 or 0.83? It's all to rewrite history in Cora's head so she was never not the maintainer, and I never was. Hence why she spend months rewriting and redoing PR's that were already merge. A massive waste of time. I think eventually 4 or so weren't merged and it would have been so much easier just to put revert commits in and keep the repo's in line for

The reason MCLA exists is because I reached out to cora about reviving it after noticing that she was removed as maintainer of MCL2 and the project started to make decisions both of us did not agree with (hamburgers, music, etc). We forked from 0.83 because that was the last version without those features and we wanted to review all changes past that point.

She fell out with 3 people. Either the problem was everyone else other than her, or maybe there is another side to the story.

Cora merged hamburgers. Cora resigned. The original PR to add music was raised by Cora. It's weird she was fundamentally opposed to the things she was adding. She seems to be very good at saying the things you probably want to hear. It probably looks much less vengeful if the repo is in your name and she makes you believe it is your idea.

From the outside, it is quite clear Cora is the maintainer and you're the acceptable face of the operation.

This is not true at all. Me and cora always discuss things and make decisions together. My experience working with her has always been positive.

Certainly you can see that you are making a lot of assumptions about her intentions here.

Cora messaged me on the 11th of March. We didn't talk for a while. Cora got angry with me on the 27th March about something I said that was perceived as a slight. She said on the 29th March "stop the bullshit and I won't bother you". First PR I can see was on the 27th March. Maybe it's purely coincidental, but it don't look it. There are no assumptions made, just things you probably haven't seen.

> > You ignore the fact her best friend, Kabou spent months attacking the project on her behalf. The reason she reviews those PRs is because she pulls them into MCLA and she wants the original author to fix them for her. > > Would it really be preferable if MCL2 contributors get no chance to fix bugs by themselves and issues would just get silently fixed by her when backporting them to MCLA? I think that is the alternative here. > > > I'm just not sure if you realise that the reason MCLA exists was a personal grudge project and to rewrite history. Did you every wonder why it kicked off from 0.81.0 (the last release Cora was involved in), rather than fork from 0.82 or 0.83? It's all to rewrite history in Cora's head so she was never not the maintainer, and I never was. Hence why she spend months rewriting and redoing PR's that were already merge. A massive waste of time. I think eventually 4 or so weren't merged and it would have been so much easier just to put revert commits in and keep the repo's in line for > > The reason MCLA exists is because I reached out to cora about reviving it after noticing that she was removed as maintainer of MCL2 and the project started to make decisions both of us did not agree with (hamburgers, music, etc). We forked from 0.83 because that was the last version without those features and we wanted to review all changes past that point. > She fell out with 3 people. Either the problem was everyone else other than her, or maybe there is another side to the story. Cora merged hamburgers. Cora resigned. The original PR to add music was raised by Cora. It's weird she was fundamentally opposed to the things she was adding. She seems to be very good at saying the things you probably want to hear. It probably looks much less vengeful if the repo is in your name and she makes you believe it is your idea. > > From the outside, it is quite clear Cora is the maintainer and you're the acceptable face of the operation. > > This is not true at all. Me and cora always discuss things and make decisions together. My experience working with her has always been positive. > > Certainly you can see that you are making a lot of assumptions about her intentions here. Cora messaged me on the 11th of March. We didn't talk for a while. Cora got angry with me on the 27th March about something I said that was perceived as a slight. She said on the 29th March "stop the bullshit and I won't bother you". First PR I can see was on the 27th March. Maybe it's purely coincidental, but it don't look it. There are no assumptions made, just things you probably haven't seen.

cora commented

2023-10-01 20:34:38 +02:00

Note that it's you who is bringing all this shit up.

And then casually state "just let it go cora" lol.

This was about you changing authorship of code nothing else.

I get that you did it because you were too lazy to properly rebase the branch yet still felt it was "too many commits". I still think it's kind of bad form; if you're too lazy to do it properly you shouldn't have squashed it at all but whatever lol.

Note that it's you who is bringing all this shit up. And then casually state "just let it go cora" lol. This was about you changing authorship of code nothing else. I get that you did it because you were too lazy to properly rebase the branch yet still felt it was "too many commits". I still think it's kind of bad form; if you're too lazy to do it properly you shouldn't have squashed it at all but whatever lol.

kneekoo commented

2023-10-01 20:39:06 +02:00

The reason MCLA exists is because I reached out to cora about reviving it after noticing that she was removed as maintainer of MCL2 and the project started to make decisions both of us did not agree with (hamburgers, music, etc).

She removed herself, after she merged the hamburger PR as a result of feedback on the issue.

Also, to everyone, stop the noise.

> The reason MCLA exists is because I reached out to cora about reviving it after noticing that she was removed as maintainer of MCL2 and the project started to make decisions both of us did not agree with (hamburgers, music, etc). She removed herself, after she merged the hamburger PR as a result of feedback on the issue. --- Also, to everyone, stop the noise.

cora commented

2023-10-01 20:44:32 +02:00

i also understand you're doing your old tactic of throwing out every accusation you can think of and see what sticks and simply pretend everything else didn't happen, i won't participate in it.

If you don't feel an apology or even fixing this is warranted, alright, I have nothing more to say here.

i also understand you're doing your old tactic of throwing out every accusation you can think of and see what sticks and simply pretend everything else didn't happen, i won't participate in it. If you don't feel an apology or even fixing this is warranted, alright, I have nothing more to say here.

pepebotella referenced this pull request

2023-10-09 22:14:13 +02:00

Server crash when opening a chest that has an unknow node on it #3961

pepebotella referenced this pull request

2023-10-20 16:24:13 +02:00

server crash when def.wield_scale is not a number value #3971

Sign in to join this conversation.

No reviewers