My responses seem appropriate to the situation. I think his logic is bunk and I've already voiced that.
I dont like the idea of inserting a blob of code for 2 games to run on just 1 type of console. I was looking into alternative MPU settings instead, or even a way to implement it that isnt just inserting a blob.
*2 very popular games. FTFY
The "extended (application) RAM mode" was called like that for a reason: https://www.3dbrew.org/wiki/Memory_layout#FCRAM_memory-regions_layout
Took the words out of my mouth, lol
Logical fallacy, but i digress. Even a way to integrate it into the cfw would be more ideal.*2 very popular games. FTFY
The "extended (application) RAM mode" was called like that for a reason: https://www.3dbrew.org/wiki/Memory_layout#FCRAM_memory-regions_layout
MPU isn't sufficient
Except its not.
Rei commented in that PR, so I'm pretty sure he's aware of it already. I posted that PR for the benefit of wolvak...
I never said he wasn't aware if it, but from talking to my friend (who will remained un-named unless he wants to post here), it was broken. He couldn't get ReiNAND to boot until he modified the injector.
Thats not a 'fix' to anything. That's an alternative method to what im doing. A slightly 'cleaner' way even. But i dont really plan on editing loader that much after i iron out the bugs, so not sure it'll be all that useful.
Again, lies. If he had the older release from the other day, that was a byte i neglected when pulling out the shiny patch.
He was using the build after the shiny patch one. I don't know why he would be lying to me, but whatever.
Well, there were three builds pushed yesterday:
That's a horrible way to do things, it makes seeing the differences impossible unless you can remember every line of the first commit...
It was very small edits within a small time span. It merges the commits or rather 'edits' them so theres no reason for remembering anything.. it's better than having 100 'oops' commits.
Generally, changing history in a public repo is a bad idea.
I know what it does, but it's a horrible way to manage it. I'd rather have 100 'oops' commits and a real commit history than trying to aim for the least amount of commits possible.
You cant find anything in a 100 'oops' commits. And im not trying to aim for the least amount.. just meaningful commits. That's how bilis taught me to do it and thats what makes sense the most. If i commits something saying "Added features X" and "feature X" doesnt work the way i intended, you bet i'll ammend real quick if i catch it in time.. otherwise i'll commit as a fix.
And yet, you committed something, made a release with a bug, amended the commit, made another release with a bug, and amended the commit again. So there were three releases off one "commit", with nobody able to actually see that a change was made to the code itself (Since the commit is still marked as happening when the first commit was done).
If you catch it "in time" I guess it would be fine, but given that there were hours between the initial commit and the amends, and it clearly caused confusion on this thread, I wouldn't consider that "in time."
