Skip to content

Conversation

@danny8376
Copy link
Contributor

This is mainly for scripting, for fixing not ideal hold b to cancel behavior

fdummy -o -s 9:/t1 2000000
ask -o -s "WAH"
cp 9:/t1 9:/t2
# on fast drive, press b on the ask above will also let cp catch the button press
# also, if you press b to cancel the cancel, it'll also register again,
# as the copying process is too fast that the delay between two button checks is way too short
# (it's checked every 1MiB transfer currently)

fdummy -o -s 0:/test 100
ask -o -s "WAH"
cp 0:/test 1:/test
# similar thing will also happen when cp very small file,
# as it's done very quickly, then it check button press
# altough, it's technically done, the prompt will still appear

@d0k3
Copy link
Owner

d0k3 commented Jul 10, 2023

Not so sure about that one. The way it's done just seems overly complicated, and we don't actually have a fast drive. Wouldn't it be better to make sure the B keypress is not registered multiple times?

@danny8376
Copy link
Contributor Author

danny8376 commented Jul 11, 2023

Not so sure about that one. The way it's done just seems overly complicated, and we don't actually have a fast drive. Wouldn't it be better to make sure the B keypress is not registered multiple times?

well, the 2nd case of my example will likely trigger this issue with literally any sd card i believe
assuming you unlock write permission beforehand, which indeed the issue we have during implementing new 3ds.hacks.guide finalizing script
yeah, 0x100 bytes might be too extreme, but a few KiB file will surely trigger this constantly
I mean we encounter this when we're copying GM9Megascript from sd to sd, it won't trigger on every sd card but do trigger on 2 of 3 total testers when we consider we're actually using slow sd card

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants