I am having this issue too...If the codes are added to the codes database then JGecko U can download all of them for instance.
I can only check it out on the weekend and it's Monday so it will take time. Anyone else having this issue? @CosmoCortney
I am having this issue too...If the codes are added to the codes database then JGecko U can download all of them for instance.
I can only check it out on the weekend and it's Monday so it will take time. Anyone else having this issue? @CosmoCortney

Never happened to me but didn't test it with MK8If the codes are added to the codes database then JGecko U can download all of them for instance.
I can only check it out on the weekend and it's Monday so it will take time. Anyone else having this issue? @CosmoCortney
Last weekend I did some testing and the memory reading request size can be increased from 0x400 to at least 0x5000 without problems so dumping memory could be faster I believe. I will also do benchmarks later to see how much faster it is or if at all because sending more requests is slower of course.
Yes, if it turns out to be true. There is also another trick that could be used which is compressing the data before sendingDoes that mean searching would be faster?
That would be really good! I really hope it turns out to be true!Yes, if it turns out to be true. There is also another trick that could be used which is compressing the data before sending
All of mine for mk8 were besides the ones located in the 1XXXXXXX rangeI see. A lot of codes' addresses are shifted by 0x2000 for some reason :/
A bug report: JGecko U freezes when selecting "memory viewer" when connected and code(s) activated. Tested on MK8.
Yeah, it's the TCP Gecko's fault that it freezes when trying to update the memory viewerAlso, after it freezes, if you resize it, it glitches out.

same for almost all my WWHD codes above 11000000All of mine for mk8 were besides the ones located in the 1XXXXXXX range
Right-clickHave the same freezing issue with JGecko U. Also, may I ask why the but "Edit" and "Delete" is gone? It's now much more difficult to change codes and so on...
003F6F6C 000000??
Right-click
you can remake it, do an unknown search (it looks 8 bit), then when the gauge id higer, search greater than. when it's less, search less than. when its equal, search equalHey, how do you convert codes like this to the Wind Waker HD version? This is for the GameCube Wind Waker, and is called the "Auction Bidding Gauge Height Modifier" and is for the US Version.
Code:003F6F6C 000000??
you can remake it, do an unknown search (it looks 8 bit), then when the gauge id higer, search greater than. when it's less, search less than. when its equal, search equal
jgecko u freezes my wiiu when trying to use a codeRight-click

you can remake it, do an unknown search (it looks 8 bit), then when the gauge id higer, search greater than. when it's less, search less than. when its equal, search equal
...Honestly, that was my first thought, but given how it's coded in an inaccessible (as of now) memory range, I wasn't sure if that'd do any good.
I'm only making it for Windows and testing it on Linux possibly but I can't on Mac so it's not getting supported, sorry. There are a lot of useful right-click functions already. Regardless, here is the code for the popup menu if people know a fixWeird, tried that on macOS since I do not have Windows, but it doesn't work somehow...
private void addContextMenuListener()
{
checkboxList.addMouseListener(new MouseAdapter()
{
@Override
public void mouseReleased(MouseEvent mouseEvent)
{
handleContextMenu(mouseEvent);
}
});
}
private void handleContextMenu(MouseEvent mouseEvent)
{
int rowIndex = getSelectedCodeListIndex(true);
if (rowIndex >= 0)
{
if (mouseEvent.isPopupTrigger() &&
mouseEvent.getComponent() instanceof JList)
{
// Select the row
checkboxList.setSelectedIndex(checkboxList.locationToIndex(mouseEvent.getPoint()));
// Show the context menu
contextMenu.show(mouseEvent.getComponent(),
mouseEvent.getX(),
mouseEvent.getY());
}
}
}





