Buried in Time (Journeyman Project 2)

[vr041]

Just a heads up: the first link isn't helpful at all in cases like this. When you're running ScummVM through Retroarch (the multi-emulator front-end for a RetroPie), that entire guide for adding games to ScummVM becomes utterly irrelevant, as the interface is completely different for it, as is the method of adding games to the SD card which serves as its hard drive.

We do not recommend using that method. It is in fact what they're doing is utterly irrelevant and should never happen in the first place. It is just plainly stupid to ask people to create some files manually while the ScummVM detection system does it all.

And before you object, this is finally coming to an end because there is a dev who finally stopped this insanity and rewrote the core interface in a way with proper engineering.


Eugene

I'm honestly not sure if you're saying this because you've personally never worked with a Raspberry Pi, but if your post is to be taken as you having worked with them before, it's really hard not to read this response as either gatekeeping, a pathological hatred of the Raspberry Pi hobbyist community, or a combination of the 2.

Yes, ScummVM in most situations where there is local drive access, is designed to grab the files you need. If we were talking about ScummVM on a platform, like PC for example, where the files could be fetched locally, you'd absolutely have a point. However we're talking about ScummVM running on a Raspberry Pi, with no local access to optical disc drives.

So what were those of us running Retropie's meant to do?

Say "well, I'd really love to run Scumm VM on this Retropie rig I've built, but because one of the lead developers for ScummVM doesn't like people doing that, because ScummVM can't locally access the files it needs, I guess I shouldn't innovate?

Seriously, what's the solution here?

For the ScummVM dev community to run a repository with files and hope that Disney or someone else, doesn't find an excuse to come after them, when they decide that the repository fails to do enough to ensure it isn't being abused for piracy?

Massively redesigning ScummVM so that it now has to network interface with PC's remotely, scan their drives for relevant files and add the, when WinSCP can just as easily allow you to remote access the Raspberry Pi and drag and drop the files in the correct file location anyway?

I mean you're saying it's insanity, but where is the insanity here of simply manually logging into the Pi, copying the files over directly?

Because it takes physical work and practically no work at all for that matter?

I wonder what you'd think of those of us who were AMSTRAD CPC users as kids, getting game mods in magazines as kids, where we actually had to program in 1 or 2 pages of code in Basic, to make a game mod work.

[criezy]

I mean you're saying it's insanity, but where is the insanity here of simply manually logging into the Pi, copying the files over directly?

I cannot speak for Eugene, but I think you misunderstood what he wrote. The way I am reading it, he was not objecting to the way to get the files to the Pi. We support many platforms that do not have access to an optical drive (such as Android and Apple phones). And the way to get the file to those devices differs depending on the device (although we do also provides ways to help transfer the date using cloud sync or LAN access, we do not claim they are the only methods that should be used).

What I think he was objecting to is the way the old libretro scummvm core detects the games by requiring the user to create a .svm or .scummvm file. ScummVM can automatically detect and run games without doing that (the games files are sufficient to identify a game). And the new libretro core, that is now officially supported (see https://github.com/scummvm/scummvm/pull/4683), supports this I think.

[vr041]

I mean you're saying it's insanity, but where is the insanity here of simply manually logging into the Pi, copying the files over directly?

I cannot speak for Eugene, but I think you misunderstood what he wrote. The way I am reading it, he was not objecting to the way to get the files to the Pi. We support many platforms that do not have access to an optical drive (such as Android and Apple phones). And the way to get the file to those devices differs depending on the device (although we do also provides ways to help transfer the date using cloud sync or LAN access, we do not claim they are the only methods that should be used).

What I think he was objecting to is the way the old libretro scummvm core detects the games by requiring the user to create a .svm or .scummvm file. ScummVM can automatically detect and run games without doing that (the games files are sufficient to identify a game). And the new libretro core, that is now officially supported (see https://github.com/scummvm/scummvm/pull/4683), supports this I think.

I appreciate that, but the problem is that it's still placing a political dispute (no matter how technically valid Eugene's points might be) over end-users simply trying to make the best of things for now, in a manner which needlessly and pointlessly takes it out on end-users. People can argue that it's insane to have to create SVM files (personally I don't care because firing up notepad, saving a text file and changing a file extension on a text file, is how I do key mappings for my Retropie setup anyway), but as it stands, it's literally the only game in town for playing SCUMM games on Retropie.

When Retropie 4.9 does come out (4.8 was released around 18 months ago), then if it gets around this issue, great. However until then, there's no point in ranting at end users, telling them not to do what's needed to make games work, or even bring up that it's currently the only option available - simply because one or more of the devs have a gripe with it, no matter how valid that gripe might be.

And yes, it literally what this amounts to:

We do not recommend using that method.It is in fact what they're doing is utterly irrelevant and should never happen in the first place. It is just plainly stupid to ask people to create some files manually while the ScummVM detection system does it all.

If it's not being recommended and it's the only method available, then the only logical conclusion that can be drawn is that what is recommended is that people don't play ScummVM games on Retropies for the foreseeable future - period. It may not be the intention, but that's absolutely gatekeeping.

Likewise there's this:

And before you object, this is finally coming to an end because there is a dev who finally stopped this insanity and rewrote the core interface in a way with proper engineering.

Like I said, this is all well and good for when Retropie 4.9 comes out, but what, are people simply not meant to be enjoying ScummVM ported games on Retripie in the interim, while 4.8 is the most current version?

Is there even an eta yet on when Retropie 4.9 drops?

I haven't seen one.

I can appreciate the frustration which comes from people pouring blood sweat and tears into porting old games for people to relive and enjoy, only for someone else to use older and less well-polished versions in other projects. However taking out those frustrations on end-users, is going to do nothing to address those issues and it's only going to alienate other people, who didn't need to be alienated in the first place.

[sev]

Moderatorial: Locking the topic with pointless drama and gross off-topic. The user has been banned for violating several forum rules, particularly for personal attacks.

ScummVM even has an official Raspberry Pi port. I have no idea what you're talking about. We love as many platforms as possible, and we work hard on simplifying the user experience, not making it more complicated with 10-step game addition procedures. Moreover, I personally added "--auto-detect" flag to ScummVM and brought it to zero steps for running known games which is specifically useful for front-ends.