Also, this was released as a beta firmware which means there are still some bugs to iron out. Did R4i release theirs as official firmware?
Of course they did they are masters at coding they have no beta's everything is perfect with them
Also, this was released as a beta firmware which means there are still some bugs to iron out. Did R4i release theirs as official firmware?
Well considering the "bricker code" is apparently meant to hit upon leaving system settings I would assume neither of those are related.....unless the first got hit after using data management but when exiting system settings instead,
Idk too many rumours and speculation at this point I would tend to lean that gateway users are pretty much safe but couldn't say 100%
With any luck they don't use the methods in 2.0 final, I think they have proved their point now and assuming they update their fpga, and the clones can't I would assume 2.0 final would be fairly incompatible for them anyway
Well considering the "bricker code" is apparently meant to hit upon leaving system settings I would assume neither of those are related.....unless the first got hit after using data management but when exiting system settings instead,
Going as far as killing your own potential userbase in hopes of getting a few more sales looks like a desperation to me, and it's a very bad sign for those who stay on 5.x or 6.x hoping for GW to support these firmware versions.But if it is true that Gateway put in this kill code, then they must be pretty furious about the clones. There aren't an infinite number of 4.x units out there and every bricked unit is one less customer. Even if someone bought a competing product, that person is still a potential future customer. I myself went through three different DS flash cards because I saw a better product than my existing one.
You should realize that apart from the redirection, all the Gateway code isn't in memory after the "emunand" is booted. The brick actually happens when you boot the launcher.dat, but you REALIZE the console is bricked only when exiting system settings (because the console reloads the real nand's firmware -> which is bricked) or you shut it down and power it up again. If you stayed in emunand without doing those things, you might not realize you're bricked for a long time, actually XDWell considering the "bricker code" is apparently meant to hit upon leaving system settings
Well there's no way to know if the person in either case was using the region-free patch or some other modification. If not the case, we know that messing around with data management/settings in emuNAND can cause bricks simply as a bug in the beta firmware. The sysNAND does not recognize the changes made and you end up with memory leaks or worse. This isn't intentional or part of any bricking code.OK, Let's shelve the argument of "moral behavior or not" for now and agian, let's just focus on one thing:
Is that 100% safe to use a GW card with unmodified launcher?
Here are two instances from GW bricking reports:
1) BSOD after using Data Management in EmuNAND
http://gbatemp.net/threads/bricked-3ds-xl-help.360464/
2) BSOD after couple hours of sleep mode
http://bbs.tgbus.com/thread-5360192-1-1.html
*As far as I know, the sleep mode bricking thing even happens with retail cards, but the difference is, sleep mode brick usualy causes a "semi-brick": can boot, can show the poweroff screen, but can't play games etc. not a BSOD.
So my question is:
What code have instances above triggered? GW bricker code? Native OS code??
(If there is no bricker code at all will they still get bricked??)
Well there's no way to know if the person in either case was using the region-free patch or some other modification. If not the case, we know that messing around with data management/settings in emuNAND can cause bricks simply as a bug in the beta firmware. The sysNAND does not recognize the changes made and you end up with memory leaks or worse. This isn't intentional or part of any bricking code.
You forgot http://gbatemp.net/threads/3ds-ing-bricked-never-even-use-clones.360657OK, Let's shelve the argument of "moral behavior or not" for now and agian, let's just focus on one thing:
Is that 100% safe to use a GW card with unmodified launcher?
Here are two instances from GW bricking reports:
1) BSOD after using Data Management in EmuNAND
http://gbatemp.net/threads/bricked-3ds-xl-help.360464/
2) BSOD after couple hours of sleep mode
http://bbs.tgbus.com/thread-5360192-1-1.html
*As far as I know, the sleep mode bricking thing even happens with retail cards, but the difference is, sleep mode brick usualy causes a "semi-brick": can boot, can show the poweroff screen, but can't play games etc. not a BSOD.
So my question is:
What code have instances above triggered? GW bricker code? Native OS code??
(If there is no bricker code at all will they still get bricked??)
Yep, that's the case.So, let me see if i understand it correctly:
The Gateway team put some code in their firmware to brick consoles that used clones? CONSOLES? Not the flashkarts?
They should get sued to oblivion if that is the case...
PS:Good job Neimod and Yellow8, not only you are not preventing pirates by releasing your exploits, you are helping them getting rich and you allow them to become bold and brick consoles too...
I know this post probably isn't helpful to anyone, but in all honestly there should have been no card for the 3DS released until it was fully opened up, allowing for homebrew and the like.
So, let me see if i understand it correctly:
The Gateway team put some code in their firmware to brick consoles that used clones? CONSOLES? Not the flashkarts?
They should get sued to oblivion if that is the case...
PS:Good job Neimod and Yellow8, not only you are not preventing pirates by releasing your exploits, you are helping them getting rich and you allow them to become bold and brick consoles too...
Nice "ethics" you have there...