Homebrew Need to test a simple lua script/3dsx, can anyone help?

  • Thread starter Thread starter ksanislo
  • Start date Start date
  • Views Views 3,947
  • Replies Replies 44

ksanislo

Well-Known Member
Member
Joined
Feb 23, 2016
Messages
386
Reaction score
229
Trophies
0
Location
Seattle, WA
XP
532
Country
United States
We're trying to determine why basic http in lua seems to have problems on some 3DS systems but not others while running as a .3dsx file.

Can I get some volunteers to grab the following archive: http://3ds.intherack.com/files/lpp-test.zip

Unzip it under your smdh:/3ds/ folder, and launch it via your regular HBL method.

Expected functional output should say:

Last version: FIX

Though some systems end up saying something along the lines of:

Last version: http://rinnegatamante.netsons.org/ORGANIZ3D.txt
or may just crash and force a reboot, or print garbled output.


After you've tested this, can you please report back with how it ran, and what 3DS model and firmware version you're using as well as including the region your system is, and also what method you used to launch HBL (ninjhax/oothax/menuhax/hb_launcher_loader.cia or otherwise)

Thanks so much for your assistance!
 
I can try if you really need help. But do i need a specific system? i have 3 of them so just asking.

The problem so far is that this seems to work just fine on my 2DS running luma 11.0 U, using the hbl_launcher_loader 1.2 to start things up... but I've got Wolvan (of Homebr3w fame) reporting that his o3DS XL on 11.0 E fails with the exact same thing, I need enough of a spread of different systems/versions/regions to figure out where the problem really is.
 
The problem so far is that this seems to work just fine on my 2DS running luma 11.0 U, using the hbl_launcher_loader 1.2 to start things up... but I've got Wolvan (of Homebr3w fame) reporting that his o3DS XL on 11.0 E fails with the exact same thing, I need enough of a spread of different systems/versions/regions to figure out where the problem really is.
I have a 3DS with official firmware a 3DSXL with luma and new 3DS with luma all USA region, so is that enough help, should i try all 3?
 
If you have the time that would definitely be a solid start, at least for the USA region.
I'll do it right now. Thank nintendo for VC suspend play :P

--------------------- MERGED ---------------------------

We're trying to determine why basic http in lua seems to have problems on some 3DS systems but not others while running as a .3dsx file.

Can I get some volunteers to grab the following archive: http://3ds.intherack.com/files/lpp-test.zip

Unzip it under your smdh:/3ds/ folder, and launch it via your regular HBL method.

Expected functional output should say:

Last version: FIX

Though some systems end up saying something along the lines of:

Last version: http://rinnegatamante.netsons.org/ORGANIZ3D.txt
or may just crash and force a reboot, or print garbled output.


After you've tested this, can you please report back with how it ran, and what 3DS model and firmware version you're using as well as including the region your system is, and also what method you used to launch HBL (ninjhax/oothax/menuhax/hb_launcher_loader.cia or otherwise)

Thanks so much for your assistance!
So far i am looking at 2 screens that shows "Last version: http://rinnegatamante.netsons.org/ORGANIZ3D.txt" The probem is the top screen is flickering trying to display it and the text is so long the end of it appears on the bottom screen and is appears to be cut off. Both systems using luma 6.1.1 11.0.0-33 U (meaning is region USA)
 
I'll do it right now. Thank nintendo for VC suspend play :P

--------------------- MERGED ---------------------------


So far i am looking at 2 screens that shows "Last version: http://rinnegatamante.netsons.org/ORGANIZ3D.txt" The probem is the top screen is flickering trying to display it and the text is so long the end of it appears on the bottom screen and is appears to be cut off. Both systems using luma 6.1.1 11.0.0-33 U (meaning is region USA)

Strange... This worked for me, and it always works for everyone if it's a .cia instead... I was kind of hoping that it was something specifically related to the european otherapp rop bin somehow...

--------------------- MERGED ---------------------------

Also, thanks for testing! The help is definitely appreciated!
 
Can confirm that on a 11.0.0-33U system the top screen displays "Last version: http://rinnegatamante.netsons." Also behind this the rest of the strings becomes a flickering mess in the background.
While the flickering bottom screen finnishes with "org/ORGANIZ3D.txt"
Old3dsXL 11.0.0-33U Using both hbloader cia and OoT3Dhax

xcvhoh1
 
Last edited by MikeModder007,
We're trying to determine why basic http in lua seems to have problems on some 3DS systems but not others while running as a .3dsx file.

Can I get some volunteers to grab the following archive: http://3ds.intherack.com/files/lpp-test.zip

Unzip it under your smdh:/3ds/ folder, and launch it via your regular HBL method.

Expected functional output should say:

Last version: FIX

Though some systems end up saying something along the lines of:

Last version: http://rinnegatamante.netsons.org/ORGANIZ3D.txt
or may just crash and force a reboot, or print garbled output.


After you've tested this, can you please report back with how it ran, and what 3DS model and firmware version you're using as well as including the region your system is, and also what method you used to launch HBL (ninjhax/oothax/menuhax/hb_launcher_loader.cia or otherwise)

Thanks so much for your assistance!

@ksanislo you're not using a descriptor, target application is not well known if can access http:C (you can check it using Core module but the best is to use a proper descriptor from R5 of lpp-3ds).
 
I reccomend you using socket module to download the string. In my case, I use sockets to download a lua file with the variables, and then I run it with dofile. I made a function for it if you are interested.
With sockets you can output progress, and improve the download speed. (Max: 128KB/sec)
 
I reccomend you using socket module to download the string. In my case, I use sockets to download a lua file with the variables, and then I run it with dofile. I made a function for it if you are interested.
With sockets you can output progress, and improve the download speed. (Max: 128KB/sec)

With sockets you'd have to reimplement all of the fancy things that http:C handles on its own for you like chunked encoding. Personally, I still say it would be easier to either just not use Lua at all, or to stick with .cia builds. I'm just not sure how this ends up broken only when run as 3dsx.
 
PRobably everyone testing this will report that it doesn't work until you provide a descriptor since lpp-3ds uses other services by default that broke http:C and without a descriptor you'll not have access to both soc:U/http:C.
 
PRobably everyone testing this will report that it doesn't work until you provide a descriptor since lpp-3ds uses other services by default that broke http:C and without a descriptor you'll not have access to both soc:U/http:C.

It worked for me with only the 3dsx and the lua script last night. I'm not sure why that would have been the case if it required the xml, but we can add one and try again.
 
It worked for me with only the 3dsx and the lua script last night. I'm not sure why that would have been the case if it required the xml, but we can add one and try again.

Working or not without an XML it's just a matter on what application Ninjhax will choose as target.
 
Working or not without an XML it's just a matter on what application Ninjhax will choose as target.

So, if it picks the wrong target, it ends up broken in the same manner that it seems to be in general? If that's the case, that implies that ninjhax itself is what is broken and it can't enable http:C in many cases even when defined with the xml file.
 
So, if it picks the wrong target, it ends up broken in the same manner that it seems to be in general? If that's the case, that implies that ninjhax itself is what is broken and it can't enable http:C in many cases even when defined with the xml file.

If descriptor is used, it forces to use a target which currently has access to the requested service.
 
Well... that's not much help. The piece that is probably the most important for determining what a best process to choose is assigned to a static memory location from ninjhax it seems:

void (*getBestProcess_2x)(u32 sectionSizes[3], bool* requirements, int num_requirements, processEntry_s* out, int out_size, int* out_len) = (void*)0x0010000C;

This function is set by the *hax. That's why apparently on some systems it will work and on some others it won't.
 

Site & Scene News

Popular threads in this forum