PS2 XtremeEliteBoot+'s Dashboard Special Xmas Showcase 2022-12-25

[Berion]

Or close in [ CODE ] tag.

 

[KRumble]

It's been quite eye opening and in some cases painful seeing the way users that are struggling with errors approach developers, I'd like to give a solid "well done sir" to you on this project and the patience it just take to even reply to some of these ingrates.
Keep up the good work, the scene moves so fast sometimes and a few months away and everything's changed again, very interesting catching up today, will be trying your app at some point in the next few days

 

[hawmie]

It's been quite eye opening and in some cases painful seeing the way users that are struggling with errors approach developers, I'd like to give a solid "well done sir" to you on this project and the patience it just take to even reply to some of these ingrates.
Keep up the good work, the scene moves so fast sometimes and a few months away and everything's changed again, very interesting catching up today, will be trying your app at some point in the next few days

if that's a retort at me, i'm a full stack dev myself so i know how to approach Devs. My critiques don't mean i'm coming from an angry place or meaning to "Belittle". my critiques are based on my own experience in packaging, deploying, and maintaining code bases/software/packages that are used by the mass public.

 

[Berion]

Isn't in readme there is mention of unpacking XEBPLUS to root of USB, not unpacking XEBPLUS contents to root of USB?

 

[hawmie]

Isn't in readme there is mention of unpacking XEBPLUS to root of USB, not unpacking XEBPLUS contents to root of USB?

Not really no. The readme doesn't even say to extract anything, it completely lacks any installation instructions whatsoever other than how to get the password for the archive. It doesn't even mention USB other than using ps2bbl to auto boot from USB, the only mention of instructions i found was on this site from the dev himself that basically stated to "extract to usb" which is problematic because once extracted you get a folder called xebplus_xmas_showcase, inside this folder is a folder named XEB , inside that XEB folder is another folder named XEB, first i tried extracting the showcase folder to root, didn't work. Then i tried to copy the first XEB folder to root of USB, didn't work, then i tried to extract just the contents and it didn't work, i finally got it to work by going into the showcase folder, then into the XEB folder and copying the second XEB folder to the root of USB. If you would like to take a look at the readme to verify, i've copy and pasted to pastebin:
https://pastebin.com/cj2q1MUq

 

[Berion]

If that so then you have right. However, keep in mind that XMAS version was prepared in a hurry, and on Cuba they have power loss very often and for many hours.

In future, better docs will be prepared.

 

[hawmie]

Well here's hoping that it might be open sourced eventually. If it ever gets a public repository i wouldn't mind helping add functionality, translate, or fix bugs.

 

[HWNJ]

The code is public.
In fact, your already have the code (it is unpacked in plain text to RAM every time you launch XEB+ in your PS2, seriously).
And, also, it is available to download in our Discord.

 

[HWNJ]

However, keep in mind that XMAS version was prepared in a hurry, and on Cuba they have power loss very often and for many hours.

Well, no...
Documentation wasn't prepared in a hurry.

The documentation says "so drop it somewhere and launch it".
As simply as that. A folder called "XEBPLUS" is provided, so... drop it somewhere and launch it.
Translates to: extract the folder somewhere and launch it. That's simple plain English to me.
The Xmas Build was actually "frozen" * in September, at a kinda-stable state. Then, in Xmas, I want back to the September's SDK, did a quick change so it displays a version in the splash and compiled it.
Everything developed from September to December is NOT included.

* I made that trimmed version when the SDK was in a stable enough state to allow me to release something that works, I removed the incomplete stuff back there and the things I knew where buggy due to issues with the SDK. Then I packed that code and the SDK from that time in a ZIP file for a later release, in case the SDK had a new regression or another "big" mess, which happened in less than 3 weeks.
The documentation was written from Sep to Oct with just a small "proofread" in Xmas.

 

[hawmie]

Well, no...
Documentation wasn't prepared in a hurry.

The documentation says "so drop it somewhere and launch it".
As simply as that. A folder called "XEBPLUS" is provided, so... drop it somewhere and launch it.
Translates to: extract the folder somewhere and launch it. That's simple plain English to me.
The Xmas Build was actually "frozen" * in September, at a kinda-stable state. Then, in Xmas, I want back to the September's SDK, did a quick change so it displays a version in the splash and compiled it.
Everything developed from September to December is NOT included.

* I made that trimmed version when the SDK was in a stable enough state to allow me to release something that works, I removed the incomplete stuff back there and the things I knew where buggy due to issues with the SDK. Then I packed that code and the SDK from that time in a ZIP file for a later release, in case the SDK had a new regression or another "big" mess, which happened in less than 3 weeks.
The documentation was written from Sep to Oct with just a small "proofread" in Xmas.

I'll take a look sometime later this week, i don't typically use discord just matrix and IRC, but i might just hang around abit.
i would change "drop it somewhere and launch it" to "Copy XEB folder to root". there being 3 different folders after extraction makes "drop it somewhere and launch" not so clear.

 

[HWNJ]

i would change "drop it somewhere and launch it" to "Copy XEB folder to root". there being 3 different folders after extraction makes "drop it somewhere and launch" not so clear.

You can drop the only folder, "XEBPLUS", anywhere you want. Extract it to the root of the pendrive, the "APPS" folder, a new folder you create named "Malarkey", or maybe, call it "PS2" so it makes some sense and no malarkey...
It is what it says, "drop it somewhere" where "it" stands for "the XEBPLUS folder".

 

[hawmie]

You can drop the only folder, "XEBPLUS", anywhere you want. Extract it to the root of the pendrive, the "APPS" folder, a new folder you create named "Malarkey", or maybe, call it "PS2" so it makes some sense and no malarkey...
It is what it says, "drop it somewhere" where "it" stands for "the XEBPLUS folder".

When you extract it you get 3 folders "xmas showcase" and 2 folders both named "XEB" so its not the only folder. "drop it somewhere and launch" isn't clear for an end user, i'm not quite sure why you seem agitated by that? i'm not meaning to come off rude or anything i'm just making a suggestion and stating that the current installation instructions of "drop it somewhere and launch" isn't clear, if you don't want to update it that's fine, but it is lacking clarity. "drop it" drop what? which folder out of the 3,Or the elf itself? "somewhere" wheres that? in the root of a pendrive or in a subfolder in the root? it'll get even more confusing once launching from memory card/autolaunch gets further implemented.
i do have a further question, Do you have the folder path hardcoded? if you pass by reference it could mediate any error from folder names being a problem, you just build the folder structure from the path the elf is launched from, which would allow it to launch from any folder name / any subfolder etc instead of crashing when the folder name doesn't match with the variable. which seems to be what causes the crash because you're looking explicitly for usb:XEB/XEB/XEBPLUS_XMAS.ELF and building the structure from there instead of using something like

XEB_DIRECTORY = GetCurrentDirectory();

and building it from wherever the current path is.

a very crude and basic example of doing something like this would be something like

#include <iostream>
#include <filesystem>

int main() {
    std::string CFG_Directory;
    std::string Apps_Directory;

    // Get the current working directory
    std::filesystem::path current_path = std::filesystem::current_path();
    std::cout << "Current working directory: " << current_path << "\n";

    for (const auto& entry : std::filesystem::directory_iterator(current_path)) {
        if (std::filesystem::is_directory(entry)) {
            std::string directory_name = entry.path().filename().string();

            if (directory_name == "APPS") {
                std::cout << "APPS directory found\n";
                // Handle APPS directory here
            }

            if (directory_name == "CFG") {
                CFG_Directory = directory_name;
                std::cout << "CFG directory found: " << CFG_Directory << "\n";
                // Handle CFG directory here
            }
        }
    }

    return 0;
)

 

[HWNJ]

When you extract it you get 3 folders "xmas showcase" and 2 folders both named "XEB" so its not the only folder.

Sadly, your archiver seems to be broken.
Use WinRAR.

i'm not quite sure why you seem agitated by that?

Because you're mentioning a non-existing issue. And I don't mean the fact you point that the language in the instructions could be a bit more clear and specific. What I mean is the fact you have something messed in your end, since you're even mentioning wrongly named folders. Details below, please keep reading. Instructions are clearly understood when you have a proper extractor and a proper release package.

isn't clear for an end user, i'm not quite sure why you seem agitated by that? i'm not meaning to come off rude or anything i'm just making a suggestion and stating that the current installation instructions of "drop it somewhere and launch" isn't clear

I get it and I understand your point.

"somewhere" wheres that? in the root of a pendrive or in a subfolder in the root?

Somewhere as in any place you want.

"XEB"

There's no folder called "XEB" in the official release. Where did you downloaded your file from?

Do you have the folder path hardcoded?

No.

it'll get even more confusing once launching from memory card/autolaunch gets further implemented.

Launching from MC is implemented in the Xmas version, but it is slow. It was "speed-up" later in development by ROMFS-ing the icons in the theme.

you just build the folder structure from the path the elf is launched from

That's what XEB+ does.

which would allow it to launch from any folder name / any subfolder etc instead of crashing when the folder name doesn't match with the variable

It crashes only when files are missing.

because you're looking explicitly for usb:XEB/XEB/XEBPLUS_XMAS.ELF

It is not. Or your archiver application is messed up or you downloaded a repack.

GetCurrentDirectory();

*cough*

System.currentDirectory()

*cough*

a very crude and basic example of doing something like this would be something like

Mate, you're basing everything in pure guessing. And, by the way, your code is wrong, from the very first line.
Please, check the source before guessing, 'cause, ya know what? It already does all of that.
For example:

Wanna give it a look? Dump it from the RAM or get it in our Discord: https://discord.gg/ZCzd2gefGH

 

[hawmie]

Sadly, your archiver seems to be broken.
Use WinRAR.
View attachment 45429

Because you're mentioning a non-existing issue. And I don't mean the fact you point that the language in the instructions could be a bit more clear and specific. What I mean is the fact you have something messed in your end, since you're even mentioning wrongly named folders. Details below, please keep reading. Instructions are clearly understood when you have a proper extractor and a proper release package.

I get it and I understand your point.

Somewhere as in any place you want.

There's no folder called "XEB" in the official release. Where did you downloaded your file from?

No.

Launching from MC is implemented in the Xmas version, but it is slow. It was "speed-up" later in development by ROMFS-ing the icons in the theme.

That's what XEB+ does.

It crashes only when files are missing.

It is not. Or your archiver application is messed up or you downloaded a repack.

*cough*

System.currentDirectory()

*cough*

Mate, you're basing everything in pure guessing. And, by the way, your code is wrong, from the very first line.
Please, check the source before guessing, 'cause, ya know what? It already does all of that.
For example:
View attachment 45431
Wanna give it a look? Dump it from the RAM or get it in our Discord: https://discord.gg/ZCzd2gefGH

sorry i meant "XEBPLUS" folders i was paraphrasing because i'm on mobile. I downloaded it from the given site in this thread at the time,used 7 zip to extract also my code isn't "wrong" it's just very basic c++ given as an example, based on the assumption that the crash was caused by a NotFound exception being thrown, which seems to be the case from your snippet. (i would add a false check so if the file doesn't exist it prints a static error screen instead of black screening, and flashing a barely visible error)
also, you correcting GetCurrentDirectory(); you're right, but i was referencing a function that will "GetCurrentDirectory();" (hence the name) as a placeholder until i had enough time off work to write a crude example. the name of the placeholder used was so if you replied to my comment before further explaining, you would still understand what i was getting at.
and as far as the file integrity is concerned the file checksum returns what i presume it should

SHA1 hash of xebplus_xmas_showcase.rar:
b389daa6a7f89e5d8d491734c9a4214a39e5131b

but yeah, i still get 2 different XEBPLUS folders (the second XEBPLUS folder is inside the first) and both of those folders are inside the xebplus_xmas_showcase folder, But it seems that i shouldn't be getting 2 separate folders i should just be getting one XEBPLUS folder if that's the case i'll use a VM later today to rule out it being a problem with my environment

edit:
tried a fresh environment and chased the issue down abit
its a bug in the way my version of 7zip was running
since you have to extract the archive without the password to get the Distribution agreement password, and then extract again with the password, 7zip would extract an XEBPLUS folder and the Distribution agreement, then when you extract again and use the password, 7zip would see that theres already a folder called XEBPLUS so instead of asking to overwrite, it would just place another XEBPLUS folder inside the first XEBPLUS folder. so i would end up with a folder called xebplus_xmas_showcase inside would be a folder named XEBPLUS inside that would be another XEBPLUS folder inside that would be the elf and everything else. TL;DR
my version of 7zip didn't play well with how this was packaged

 

[HWNJ]

my code isn't "wrong" it's just very basic c++ given as an example

Then what do you call this?

#include <iostream>

It should be

#include <iostream.h>

As I said, wrong from the very first line.

SHA1 hash of xebplus_xmas_showcase.rar: b389daa6a7f89e5d8d491734c9a4214a39e5131b

It is b389daa6a7f89e5d8d491734c9a4214a39e5131b, so the issue is in the archiver app you're using. As I said, try WinRAR. I've seen 7zip mess it with so many things in some builds.

But it seems that i shouldn't be getting 2 separate folders i should just be getting one XEBPLUS folder if that's the case i'll use a VM later today to rule out it being a problem with my environment

Good luck!

since you have to extract the archive without the password to get the Distribution agreement password

Well, there's no need to "extract it" to a folder. Open the license from the rar file, as in, open the file in 7zi, then double click the TXT.
Of course, 7zip will extract it to a temporary folder so you can read it, but you get the point I mean.
Then, grab the password and extract the contents of the RAR.

since you have to extract the archive without the password to get the Distribution agreement password, and then extract again with the password, 7zip would extract an XEBPLUS folder and the Distribution agreement, then when you extract again and use the password, 7zip would see that theres already a folder called XEBPLUS so instead of asking to overwrite, it would just place another XEBPLUS folder inside the first XEBPLUS folder. so i would end up with a folder called xebplus_xmas_showcase inside would be a folder named XEBPLUS inside that would be another XEBPLUS folder inside that would be the elf and everything else. TL;DR

Seems like you're constantly extracting to subfolders over and over...

 

[hawmie]

Then what do you call this?

It should be

#include <iostream.h>

this is actually wrong,
<iostream> is the usual header
<iostream.h> is the old header, no longer supported by some compilers
Some (old) compilers use .h files. Modern compilers usually use <iostream> (without the .h extension).

 

[Berion]

7-Zip v24.08 unpacking that to:

└── XEBPLUS
  └── APPS
  └── GSM v0.23x
  └── GSM.ELF

7-Zip v23.01 not unpacking it at all.

Sorry HWC but the way it is distributed is cancerous. WinRAR is MANDATORY for that archive (or any mass archiver which using official unrar.dll, which means also Windows).

 

[hawmie]

7-Zip v24.08 unpacking that to:

└── XEBPLUS
  └── APPS
  └── GSM v0.23x
  └── GSM.ELF

7-Zip v23.01 not unpacking it at all.

Sorry HWC but the way it is distributed is cancerous. WinRAR is MANDATORY for that archive (or any mass archiver which using official unrar.dll, which means also Windows).

that's disheartening, My daily OS is arch , and winrar on Linux was a buggy mess the last time i tried it. (Only command line is compatible).

 

[HWNJ]

this is actually wrong,
<iostream> is the usual header
<iostream.h> is the old header, no longer supported by some compilers
Some (old) compilers use .h files. Modern compilers usually use <iostream> (without the .h extension).

We're in the PS2SDK compiling environment, so...

 

[HWNJ]

Sorry HWC but the way it is distributed is cancerous. WinRAR is MANDATORY for that archive (or any mass archiver which using official unrar.dll, which means also Windows).

This was something made exclusively for the Xmas build.
Also, blame it on 7-Zip. Before doing that Xmas release, I tested it with 7-Zip 19.00 x64 and, also, Directory Opus 12.12.
In both cases, it was PROPERLY extracted.
So, the regression is on 7-Zip's side. Report it to them, please.

Edit: I just redo the very same test from years ago, with the very same WinRAR version. No issues found. Video evidence in the RAR below: