Open PS2 Loader Project Feature Requests

Quote:

---

Originally Posted by dlanor

Yes, exactly, except that the 'enabling' should not be done from the OPL GUI.

I never said that the childsafe mode should be possible to either enable or disable through the GUI. That was part of the childsafe feature itself, as the program used by the untrusted users does not contain any way to disable it. So they have no loophole...

What I suggested was just to implement the CFG variable, leaving the manipulation of it entirely up to the user and his text-editor (like the TextEditor subprogram of uLE).

The only truly childsafe application is one where it is impossible to use the application itself to bypass its protection status. And that is the advantage of my simpler proposal.

---

Oh ok I see ... then no offense, but personally, I really dislike this behavior. It is too restricting to be usable.

Quote:

---

Originally Posted by dlanor

That would be utterly useless, as it only takes one child/customer to learn that code and then inform all the others.
That would work of course, but despite its complex method it is easily rendered useless.

Regardless of what password is used, in a game parlor environment it is only a matter of time before one gamer manages to peek at a password entry made by staff, and the same goes for a large family with lots of gaming kids. Sooner or later one of them will peek at mom or dad entering the password. And once one of them knows it, it is just a matter of time until they all do.

---

That is your point of view.

I consider that you can find a way (moment) where there is no risk to enter the password. Put the kids to sleep, if you can't manage this situation, then the problem is somewhere else :)

My assumption is that the settings are set for good, and the need to change them is really seldom. For this rare case, I don't want to go through a complicated process, involving using other tools.

Quote:

---

Originally Posted by izdubar

Oh ok I see ... then no offense, but personally, I really dislike this behavior. It is too restricting to be usable.

---

I think this is the point of child-proofing. I want to make it almost impossible for someone who does not know my personal configuration to mess with it. After reading what dlanor said, it makes better sense to me personally.

I'd be able to edit the config file in my laptop, put it in a usb and transfer it in the proper place via uLE. It's not that hard, since I've done the same when editing my fmcb config file.

I wasn't sure what it would take to make this secure for people with kids, but now that I read what dlanor had in mind, I'm all for this. I have nieces/nephews and friends who come over and love messing with my settings. Very frustrating when this happens.

would it be possible to build a ftp client into OPL like in ULE it would be nice to have this in OPL it would make it easier for testing purposes and also no body cant use it that don't know how to use FTP and this would make it easier editing your config file.

What I propose can be exactly the same to what Dlanor explained but still, can do more.

Simple mode (and restrictive for me): Set a secured user password once and then don't take the risk that someone see your password, so never enter it from OPL. Instead do the same "complicated" stuff using an external way to "reset" the password and overwrite the config file when needed = 100% compatible in the way it behave as Dlanor solution

Advanced mode: Set a secured password, use it to unlock OPL settings when no-one spy around. More flexible so why not giving more power when it doesn't hurts :)

Quote:

---

Originally Posted by izdubar

What I propose can be exactly the same to what Dlanor explained but still, can do more.

Simple mode (and restrictive for me): Set a secured user password once and then don't take the risk that someone see your password, so never enter it from OPL. Instead do the same "complicated" stuff using an external way to "reset" the password and overwrite the config file when needed = 100% compatible in the way it behave as Dlanor solution

---

Yes, that should work. And if the password is edited that way it can even be set to something that the virtual keyboard is unable to enter, making it completely safe.

Quote:

---

Advanced mode: Set a secured password, use it to unlock OPL settings when no-one spy around. More flexible so why not giving more power when it doesn't hurts :)

---

Sure, I have no problem with that.

However, like you said the complete version of what you want might take some time to implement and debug, so it could be a good idea to implement this in two steps.

The first step could then be to implement the five changes I suggested earlier, in that simple form. This could give those who can accept TextEditor as control interface what they need to use this almost immediately, as these changes are so easy to implement and debug.

The second step would be to add the GUI routines for password definition and checking, with the latter also implying a new modification of the conditional blocking of the two setting menus (the global settings and the compatibility settings), but with the other three changes from the first step still valid for the advanced form as well. This could give you and others who want full control from the OPL GUI what you want, though it might take a little longer to get there.

Best regards: dlanor

Feel free to point and laugh and call me a retard if this doesn't make sense or is completely impossible, but I was playing around with a couple of games the last 2 days and it got me curious. Once you start a game via USB or SMB, would it be possible to (maybe as a toggle-able compatibility setting) have OPL switch between the SMB "core module" (I am not too familiar with this sort of coding) and the USB core based on a game calling for a certain function that the current module isn't compatible with?

Let me explain what i have been doing, in the hopes that it will make what i am asking make more sense in context.

2 games for me have compatibility issues, those being Kingdom Hearts 2 and God of War (full DVD9, not downsampled), Both NTSC and being played on a V14 I believe (75001 slim). Both games are stored on a 300 GB SATA drive.

edit: Wanted to mention that once i got past the crashing parts (completing the gummi ship level or the ctuscene) I can load from the save after via SMB and continue playing normally until the next time i encounter those parts of the game, so it would seem to me that there is some specific function/s that the game is calling for that the USB core can process but the SMB core can't, since i am using literally the same media for both.

I am sure everyone knows about the "gummi ship" crash in KH2 via SMB, and the cutscene crash in GoW. But the thing that made me decide to ask is, when I get to those points, I can pull the HDD out of my computer (said crashes being via SMB obviously), plug it in to a SATA-USB adapter, and reload the game from literally the exact same data and continue on past the crash points.

I am guessing that there is no way to load the USB core into memory without forcing the game to restart if it is already running via SMB, but i just found being able to do that curious enough to ask those in the know.

Hopefully this post isn't wasting too much of people's time, because I am in Awe of the developers of OPL and while I don't know much right now, I just want to try and do something to maybe spark an idea or in some small way show my appreciation for this awesome piece of software.

@dlanor, @Izdubar: Guys - what is it again you dislike about the solution to build entirely configuration-less OPL? Aside from the fact the elf would have to be built (once a few months) the work to provide this is tiny and the result is bullet-proof - no possibility to tinker with settings.

With the lock in config, we're emerging a possible situation someone pulls out the card when opl is launched just before the config is read, then overwrite the settings - so it is not bullet-proof.

I think having a seperate 'childproof' version is a great idea. Since there is most likely a small number of people who would even use this, its a great solution for them without needing to make the main release so complicated for everyone.

This way only those who find a need for a childproof OPL can simply use that version for their kids and business. How often will they really need to make changes that would warrant putting a complicated childproofing solution that everyone has to deal with possible bugs and other needless possible side effects into a single release?

Quote:

---

Originally Posted by JNABK

I think having a seperate 'childproof' version is a great idea. Since there is most likely a small number of people who would even use this, its a great solution for them without needing to make the main release so complicated for everyone.

---

This is exactly my thought and why when the original conversation popped up decided to bring it up here. Just earlier tonight I was at a sports bar where they had a PS2 set up with Guitar Hero. I said to my friend "If this were my rig, I'd have it pimped out with OPL and an internal HDD (since it was a fat PS2 with network adapter)" but then remembered the settings issue.

Fortunately, people agree that it can be done and even better without much editing to release a regular and childproof version. This would definitely be beneficial to me in the future since I do have people come over and try to mess with my config. I'm sure if these same people went to the bar I was at, they would mess with it there, too.

Glad that the discussion in that other thread brought forth this idea and hopefully we'll have it available soon. Not necessarily in the next release if it's too complicated to implement it by then, but in the future it would be nice.

Quote:

---

Originally Posted by volca

@dlanor, @Izdubar: Guys - what is it again you dislike about the solution to build entirely configuration-less OPL? Aside from the fact the elf would have to be built (once a few months) the work to provide this is tiny and the result is bullet-proof - no possibility to tinker with settings.

---

Agreed. My only real objection to that solution was the extra work required and the extra size increase of future release packages (as release for non-programmers must then include both binaries).

But if everyone else is OK with those 'costs' then it is fine by me too.

Quote:

---

With the lock in config, we're emerging a possible situation someone pulls out the card when opl is launched just before the config is read, then overwrite the settings - so it is not bullet-proof.

---

That could be countered only by having the default flag state (with no CNF found) activating the childsafe mode, which would be an unpleasant design choice IMO.

You're argument here goes hand-in-hand with my earlier statement that the only truly childproof application is one that does not contain any method to remove its protection.

So this brings me 'on board' in supporting the plan for a separate childproof elf.

Btw: Full security is clearly impossible. People must be allowed to have gamesaves on their own MCs, and if they insert an MC with their own FMCB setup (made elsewhere) and reboot with that then all bets are off anyway... :lol:

Best regards: dlanor