// We only want to know about main partitions (non-empty ones at that :P)
if((dirEnt.stat.attr & ATTR_SUB_PARTITION) || (dirEnt.stat.mode == FS_TYPE_EMPTY))
{
rv = fileXioDread(hddFd, &dirEnt);
continue;
}
// We only want to know about main partitions (non-empty ones at that :P)
if((dirEnt.stat.attr & ATTR_SUB_PARTITION) || (dirEnt.stat.mode == FS_TYPE_EMPTY) || !(strncmp(dirEnt.name, "PP.HDL.",7)))
{
rv = fileXioDread(hddFd, &dirEnt);
continue;
}
or add a second version of hddGetFilesystemList (hddGetPFSsystemList?) that adds this filter. It'll speed up load times drastically on those systems with large hard drives and many PP.HDL partitions that can't be accessed by PFS anyway. Or maybe (dirEnt.stat.mode !=FS_TYPE_PFS) would be a better filter?
We dont want any HDL/HDA patch shit in our sdk, HDL/HDA is warez and so it is.
Trying to go around it with lame stuff like this is to approve the existense of it.
That's BS. It exists. Deal with it. Ignoring it won't make it go away. It'll just screw up the homebrew scene when peope can't get a program to load in a timely manner. Just because you acknowledge the existence of something enough to get around the problems it causes doesn't mean you approve of it.
I'm not talking about supporting it. What part of the patch makes you think it's being supported? It's merely making GetFilesystemList not take freakin' forever if there are HDL partitions on the system by skipping them. How is that supporting it? Oh well, do whatever, I guess I'll just be the only one writing software that uses the hard drive that doesn't take a year and a half to load.
I don't know. I've never counted. I've got a 120GB HD. 3 or 4 gigs is PFS formatted. It took MCManager at least a minute (though I think closer to 2, I never timed it) to load before I changed it to not scan for partitions. I noticed a lot of people thinking HD programs were locking up on their systems they were taking so long.
I've never seen the code for HDL so I don't know which aspects of it make it a copyright violation so I can't answer to that. The point is that people aren't going to stop using it and reformat their drives just because someone releases some new homebrew that reads from the HD. They'll just stop using the homebrew 'cause it takes too long to load. I don't know if the mode!=PFS would work as well as the name filter, but if you did that, it'd be for ignoring ANY unaccessible partition, not necessarily HDL. To me getting a list of ACCESSIBLE partitions is a function that should exist anyway. (of course, by accessible, I mean accessible by PFS).
Piracy talk aside, hacking in code to work around one specific program is rarely a good idea. Finding out why it takes so long to scan invalid partitions rather than just skipping them would be a better goal, and possibly more acceptable to people here. Try submitting a patch that adds to the value of the software as a whole instead of one that bends it around a problem that's really just yours, not ours.
...and if you want a true debate on the merits of ps2dev supporting software like this, you'll have to come up with a better point than 'everyone is doing it!'.
Drakonite wrote:My HDD stuff doesn't take a year to load. But then again, I'm not a warezing bastard either.
It would if your average PS2 homebrew user ran it (assuming it uses GetFilesystemList).
HDL/HDA != Homebrew.
If your claim is that most people that would be running homebrew are warezing bastards, well, take a guess why I haven't released anything significant publicly for quite a while.
My point isn't everyone else is doing it. My point was it's a problem that exists and should be taken into account, whether you like it or not.
And the one specific program thing is why I suggested possibly making an alternate function that skips and non-PFS partition.
As far as WHY it takes so long, it's just the number of partitions, and the time consuming routines done on each. There's no way to fix it except by skipping some of them or for the user to remove them. If you have... say 60 PFS formatted partitions, it'd take just as long, I'm sure. So you look at how it affects the average user and you see they only have 1 or 2 PFS partitions and 58 other partitions and it's taking forever. You know your program can't do anything with those 58 partitions, so there's not really any need for your program to know about them, so you can skip them, thus saving time. If you're developing something that's not just for yourself, you have to take the average user into account, not your own situation. Just because you only have 3 or 4 partitions doesn't mean you should code like everyone does. If this wasn't about HDL partitions but some homebrew something that made shloads of custom partitions and took huge amounts of space, you wouldn't be arguing.
Drakonite wrote:If your claim is that most people that would be running homebrew are warezing bastards, well, take a guess why I haven't released anything significant publicly for quite a while.
That's your choice to release or not. Warezers always were and always will be. Another thing you'll just have to learn to deal with (or not and just be unhappy about it).
I see your point about any hdd with that many partitions, hdl or not, would be slow to start. However, I am unconvinced that adding a workaround for one program is a proper solution - it will only work until some other program creates a bunch of partitions as well.
I can see two ways of fixing this:
1) Use of threads in the homebrew program to enumerate the partitions while the UI continues to function, thus removing the 'lockup' impression the user is experiencing.
2) In ps2sdk, determine if it is indeed a speed issue or possibly a bug that causes the lengthy process and fix or optimize where any issues are found.
Either can be acomplished without the need to resort to yelling at us for not bending over backwards to support users who chose to run the hdloader software. You've managed to uncover a serious performance issue in ps2sdk, even if by the wrong means, so let's concentrate on the problem instead.
Drakonite wrote:If your claim is that most people that would be running homebrew are warezing bastards, well, take a guess why I haven't released anything significant publicly for quite a while.
That's your choice to release or not. Warezers always were and always will be. Another thing you'll just have to learn to deal with (or not and just be unhappy about it).
The PS2 scene is worse than any other I've ever seen.
There is no reason to put work into things when the only thing will be a bunch of warezers trying to steal as much as they can and bitching to make it to X or Y feature that you either don't want it to do, or is far more work than it's work on the PS2.
Sjeep did that "on purpose". I am strongly against any "workaround" in the current ps2sdk to support software which was made, on purpose, to choke the other homebrew software with tweaked partitions. If HDL was a homebrew software, I'd rather go on fixing it than workarounding it in the sdk.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
I was only yelling 'cause I got yelled at first, and because all of you seem to shut down your brains at the mere sight of the letters HDL. I apologize. I'm sure it seems a reasonable reaction to you. It doesn't to me.
As far as the speed of PS2SDK during GetFilesystemList, I don't think it's PS2SDK's fault; it's just the time it takes to get all that info from the HD, probably bottlenecked by the HD access and read speed. One way I can see to fix it easily without it mattering what format the partitions were would be to make it just return the dirEnt info (name, stat) since that's all you REALLY need to know on enumeration. Anything else (getting partition size, partition type, and all those other intensive things Get FilesystemList does) can be done through other functions when needed and on specified partitions, not on all. Doing it this way, you wouldn't have to skip anything. The problem I see with loading this info in the background is if the program or user tries to access the data before it's been completely enumerated.
In case that was too rambling to make sense: GetFileSystemList does more than it needs to, which makes it slower than necessary, and would probably be better split into multiple functions.
Last edited by KaylaKaze on Thu Apr 21, 2005 7:20 am, edited 1 time in total.
Drakonite wrote:There is no reason to put work into things when the only thing will be a bunch of warezers trying to steal as much as they can and bitching to make it to X or Y feature that you either don't want it to do, or is far more work than it's work on the PS2.
I understand where you're coming from. One of the reasons I haven't done any PS2 coding for months is because I was pissed about people complaining my interfaces weren't pretty enough (this from a guy who said he had his program all done but just needed to make the UI for it before release and then took forever to release beause of it [or it may still not be released yet]). As far as feature requests, I just ignore them, especially the one where they're all like "Can you use a easier to read font" :-)
pixel: Would you be supportive of a homebrew open-source HDL like program? I thought the problem you all had with HDL was that you felt it was about pirating commercial games, not about the manner in which it created, distributed, coded, etc.
To be really honest, I have as much pro and cons about a homebrew HDL software. pros is that hdl already exists, and having a homebrew one wouldn't do any more harm than hdl already did; and such software may still be cool as it could get lots of improvements from various locations. cons is that it's just not like us in any way, because it would still be a warez-enabled tool and used as it by 99.99% of the users of it.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
Kayla, first off, you have a point about getting jumped on. However, you have been around these forums long enough to have known it would happen, whether either viewpoint is right or wrong. Not saying you shouldn't have tried anyhow.
Second, I like Oopo's approach - if anything needs fixing, fix real problems in a general way for the good of all, rather than focusing on something that caters to a specific app that itself is extremely controversial.
My own view, as someone who tried the ps2menu-k+hdl combo (I know, heresy in these parts) with games that I own is that the loading speeds were really not that big a deal for me to make it worth it to use hdloader. I honestly could not see any perceived benefits of loading speeds for legally-owned games being compelling enough to overcome the obviously more serious and most likely use that others would put it to - warezing.
I have long since nuked that partition and software.
// We only want to know about main DEV USABLE partitions (non-empty ones at that :P)
if((dirEnt.stat.attr & ATTR_SUB_PARTITION) || (dirEnt.stat.mode == FS_TYPE_EMPTY) || !(strncmp(dirEnt.name, "PP.",7)))
{
rv = fileXioDread(hddFd, &dirEnt);
continue;
}
My storebought (still not entirely sure if CB types are actually legal) cheat device (Codebreaker 9) that I use for USB backup of savegames (not to mention the occasional cheat), creates a PP. type partition to put the codebase and HDD based copies of downloads and savegames, since ps2sdk's does not support "password protected" partitions of any type, why not filter them out along with the ___system and ___mbr ones (even if HDL does name its partitions with PP. at the beginning..???) even just to keep them out of the way of homebrew softs?
Well, staying out of the warez discussion, how about this.
Have hddGetFilesystemList() stay the same and add two new functons.
hddGetFilesystemNames(char names[], int maxEntries)
'just returns a list of the valid partition names'
hddGetFilesystemInfo(char *name, t_hddFilesystem *fs)
'Pass in the filesystem name and it returns the info in the fs pointer.
This would give people the flexiblity to do what they want.
I guess it might make sence to have hddGetFilesystemList() call the new
hddGetFilesystemInfo() so the logic is not duplicated.
That shows the problem is not here, but elsewhere. Either in fileXio or in the function *it* calls later on to access the hdd device.
Look deeper... deeeeeper....
Besides, writing new functions just for the hdd device is also silly. Fix the problem, don't work around it on a one-by-one basis. That's how code becomes unmanageable and overweight.
