Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature #7735: Implement protocol handling #7981

Open
wants to merge 5 commits into
base: master
from

Conversation

@JMcKiern
Copy link
Contributor

JMcKiern commented Feb 6, 2020

Basically does what #7735 asks for.

In openttd.cpp L475-483, I added cases for joining as a new company ("new") and joining as a spectator (""). These changes will affect the way a command line connection string (-n host:post#company) is parse but I think that would be ideal.

Let me know what you think.

@LordAro
Copy link
Member

LordAro commented Feb 6, 2020

I'd recommend "Feature" as the commit prefix

@JMcKiern JMcKiern force-pushed the JMcKiern:protocol-handler branch from 1cb904c to 278477d Feb 6, 2020
@JMcKiern
Copy link
Contributor Author

JMcKiern commented Feb 6, 2020

I haven't actually changed any installation code. So far, this is only another command line option. It still needs to be added to the installation so that clicking a link would open OpenTTD.

Also, I forgot about "ask the player for confirmation before beginning to connect"...

src/network/network.cpp Outdated Show resolved Hide resolved
src/openttd.cpp Outdated Show resolved Hide resolved
src/openttd.cpp Outdated Show resolved Hide resolved
} else if (strcmp(name, "companypassword") == 0) {
scanner->join_company_password = value;
} else if (strcmp(name, "version") == 0) {
/* Nothing for now */

This comment has been minimized.

Copy link
@nielsmh

nielsmh Feb 7, 2020

Contributor

I think having multiple versions handling in from the beginning would be ideal. Have a per-platform function for launching a different installed version (by version string) that as a fallback just does nothing.
By having fully functioning multiple versions handling in from the beginning, any installed version can be registered as the primary URL handler, and will always be able to re-launch any other installed version.

This comment has been minimized.

Copy link
@JMcKiern

JMcKiern Feb 8, 2020

Author Contributor

Hey @nielsmh, I'm wondering how the program would look for other versions that are installed? I tried installing 2 versions of OpenTTD using the Windows installers but only the latest version is kept. This leads me to think that each version would have to be installed in different user-chosen locations...

This comment has been minimized.

Copy link
@nielsmh

nielsmh Feb 9, 2020

Contributor

Yes it would have to be a new thing done by something. I don't have a bulletproof idea yet, but something with versions of the game (that support URL handler) registering itself when it starts. So if you have a bunch of different portable versions with this feature, the first time you run one it registers itself with version and path, and you end up with all of them registered and available for URL handlers.

Perhaps also a mode where earlier versions can be registered so an URL-handler-supporting version can convert the URL into the older commandline parameters format and start those.

This comment has been minimized.

Copy link
@JMcKiern

JMcKiern Feb 10, 2020

Author Contributor

Hmm, yeah, i see what you mean. What information would we need to store? Is it just version number and filepath for each executable? Presumably this could be stored in a simple config file, ignoring weird characters (eg a newline) in the file path. I guess binary file could be used instead to allow for this.

Maybe for registering old versions, a -r (--register) option could be added that would take the path of an openttd executable and the new version would find its version number and register it?

Also, there would need to be some way to tell if the older cli parameters would need to be used. Could that just be a hardcode if version < some_version: use old cli or is that too rigid/fragile?

This comment has been minimized.

Copy link
@nielsmh

nielsmh Feb 10, 2020

Contributor

On Windows I would do it in registry.
Key name HKCU\Software\OpenTTD\Versions\<version>
Default value = (string) path to exe file
Value NetworkJoinMode= (dword) 0 for classic, 1 for -U parameter support

The <version> in the key name ("folder") should be the network version of the build, which should usually be the same as the product version string in the exe file's version resource. This means the main URL handler will be able to verify that the exe file pointed to is the actual version intended before launching it, and abort if it's not a match. That would work for even very old versions.

As for registering old versions/versions not supporting the URL handler, it could either be done in a manual way, or an automatic-ish scanner. Manual would be prompting the user to find the exe file for a specific version when they try to join a server where they don't have the version for, or as you suggest having a call to register a specific version. Automatic scanner would probably be best as a separate downloadable tool.

On Unix'y systems, I'd put the database in a similar format (maybe an INI format) in the user's profile ~/.openttd/.
On macOS, the right way might involve a PList of some kind.
I'm not sure how you could verify the version before launching in either of those, apart from maybe a checksum of the binary file.

This comment has been minimized.

Copy link
@JMcKiern

JMcKiern Feb 11, 2020

Author Contributor

Ok, cool.

I don't actually have access to a macOS machine (nor have I even heard of PLists!) but I can give it a go anyway.

A prompt does make sense. And i suppose the automatic scanner idea can be made at a later date.

I'll have a look into all this whenever i get some time

Should i just continue in this pr or should i make a pr on my fork to (temporarily) separate the changes? I've never added this much in a pr before...

@nielsmh nielsmh changed the title Close #7735: Implement protocol handling Feature #7735: Implement protocol handling Feb 8, 2020
@JMcKiern JMcKiern force-pushed the JMcKiern:protocol-handler branch from 84f2c2d to 1053bf9 Feb 8, 2020
src/openttd.cpp Outdated Show resolved Hide resolved
@nielsmh nielsmh dismissed their stale review Feb 13, 2020

Critical issues resolved.

@JMcKiern JMcKiern force-pushed the JMcKiern:protocol-handler branch from 7740311 to 1f43d0e Mar 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.