Zandronum Chat @ irc.zandronum.com
#zandronum
Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001961Doomseeker[All Projects] Suggestionpublic2014-10-13 21:302019-07-19 14:38
ReporterMazterQyoun-ae 
Assigned ToPol M 
PrioritylowSeverityfeatureReproducibilityN/A
StatusassignedResolutionopen 
PlatformAllOSAllOS VersionAll
Product Version 
Target VersionFixed in Version 
Summary0001961: Port autoupdate
DescriptionImplement autoupdate functionality.
The suggestion of implementation is something like this:
Doomseeker never looks up for updates anywhere, instead it checks if server version is higher than the version client has (obviously, only in case if both client and server have release versions) and only then prompts client a dialog for update. This should prevent clients from prematurely updating before servers. Having a package in .zip (for Windows) and .tar.bz2 (for Macintosh and Linux) formats from port developers ready-for-autoupdate would be good as well.
Additional InformationAs an addition, Doomseeker could keep autoupdated ports where it keeps WADs and other data. This will allow clients to join servers with different versions, which is especially good when half servers have moved and half not just yet. Doomseeker can easily determine which port version server is running, and use appropriate binary.
Attached Files

- Relationships
related to 0002017acknowledged Point games in configuration to different executables basing on version. 

-  Notes
User avatar (0018738)
WubTheCaptain (developer)
2017-11-03 11:16

I oppose this suggestion as featuris/out of scope.

Writing a "package manager" is hard to get right, especially at larger scale as more engines are added in. So you want to write a package manager? (HN, reddit)

Is this ticket not already implemented for the Zandronum engine? The only distinction Doomseeker currently makes is stable vs testing binaries for Zandronum, but 0002017 is related. (This and the paths used for Zandronum testing downloads may become an issue for 0003246.)

It's also becoming increasingly discouraged to run unsigned code; in example 0003294 (macOS) and Windows Installers (0003292).

It all just sounds like to me this is mostly (historically) affecting Microsoft Windows operating system. Package management should be done at the operating system level (be it Windows Store(?), apt/dpkg, yum, Apple App Store, Homebrew or whatever). From my experience, this is currently working okay for GNU/Linux distributions (i.e. apt UnattendedUpgrades).
User avatar (0018742)
Zalewa (developer)
2017-11-03 15:00

Given how Windows 7 is still an awesome operating system and how Windows 10 is infamously hated for being a spyware, you can't realistically rely on Windows getting any kind of package manager - ever.

That said, there's Steam and GOG Galaxy and whatever garbage Ubisoft and EA will try to shove down your throat.


About port autoupdate: There's a certain conflict in how we currently handle this. If the server browser has no problems installing "testing" binaries then why should it have problems installing "official release" binaries? Right now, official releases are completely ignored, even though they are essentially not different from testing binaries at all! Game servers can precisely tell us what game version they run, and we can precisely detect if this version is installed on disk and install it if not. For Zandronum, we can do this right now, with the current code we have, just by removing the 'if' check where the server tells us that it's a testing server.

That said, if we disregarded the difference between "testing" and "release", we would need to somehow handle how user configures the path to the game. After all, when we install a testing binary, we still copy all .ini configs from the "release" directory to the newly installed "testing". The game requires that.

Moreover, if user already has the "release" version of the game installed, Doomseeker will not be able to recognize that from an arbitrary directory - it won't know what version it is. Doomseeker will have to be under complete control of this. For this to work we would essentially need to force Doomseeker install another copy of the same version of the same game in the way Doomseeker likes just so Doomseeker can know what version it is.
User avatar (0018753)
Blzut3 (administrator)
2017-11-04 00:10

This is definitely in scope since the tool's job is to assist with connecting to game servers, and having the wrong version is a pain point. In the case of release versions they don't happen frequent enough for it to be a high priority, but every time there's a release there's a mass panic about how difficult it is to switch between versions while servers exist for both the old and new.

While I would agree it's not our job to write a package manager, ultimately user experience trumps idiomaticity. I do feel, however, that it is important that users be able to easily opt out of any auto installing that Doomseeker may be able to do.
User avatar (0020387)
Pol M (developer)
2019-02-14 18:25

I'm gonna take a look at this. I'm starting exams asap, so don't expect commits quite soon
User avatar (0020430)
Pol M (developer)
2019-02-26 16:04

Quote from Zalewa

Moreover, if user already has the "release" version of the game installed, Doomseeker will not be able to recognize that from an arbitrary directory - it won't know what version it is. Doomseeker will have to be under complete control of this. For this to work we would essentially need to force Doomseeker install another copy of the same version of the same game in the way Doomseeker likes just so Doomseeker can know what version it is.

I've been thinking for a while to find a way to not do this, but it seems like there is no alternative. plugins don't have an easy way to know their versions (in most of them there is an internal command, but that's not useful at all, and some of them print it onto stdout, but this is unreliable as mentioned in Zalewa's comment). I've also thought about hashing the binaries and comparing them to those hashes, but this is simply a bad idea for executables.
So yeah, I guess that our best bet is to simply make an internal mode where doomseeker handles executables the way it wants them and a system mode where it simply uses the ones in the system.
User avatar (0020431)
Zalewa (developer)
2019-02-27 10:26
edited on: 2019-02-27 10:27

On our request Torr has added to Zandronum a `--version` command line argument which provides version in a parseable format when run:


3.0-r170901-1140
dd3c3b57023f


While the command line option by itself is undoubtedly useful, there wasn't enough forethought in our original request. Running an executable in order to query for its version is fine if you know exactly which executable you're running. It's good for shell scripts in a standardized file-system such as FHS.

In an user-configurable GUI program there's a risk that the path that's supposed to point to the game executable will point to something unexpected instead. If you don't know what executable you're running, then what was supposed to "silently run and close itself in the background" may suddenly start to wreak havoc in the system like those infinite-popup sites that used to kill Internet Explorer. Most Windows programs will just ignore command line arguments and happily run as if nothing was passed. Or they will try to interpret this argument as a path to a file (try running `notepad --version`).

User avatar (0020432)
Pol M (developer)
2019-02-27 17:24

Quote from Zalewa

Torr has added to Zandronum a `--version`

Nice! It also accepts a path to file :D (It was unfortunately not documented)

Quote from Zalewa

In an user-configurable GUI program there's a risk that the path that's supposed to point to the game executable will point to something unexpected instead. If you don't know what executable you're running, then what was supposed to "silently run and close itself in the background" may suddenly start to wreak havoc in the system like those infinite-popup sites that used to kill Internet Explorer. Most Windows programs will just ignore command line arguments and happily run as if nothing was passed. Or they will try to interpret this argument as a path to a file (try running `notepad --version`).

This is definitely a risk, but I'd say that it's worth taking it. The most probable way where this could be a problem is if someone starts changing things without knowing what they are changing, which the action itself is a risk. Maybe we can limit the execution time to a few seconds.
User avatar (0020433)
Zalewa (developer)
2019-02-27 17:45

The risk could be minimized by imposing some rules on when to run the program to ask for `--version` and how to deal with them:

1. This must happen only when the game is about to be joined, ie. after we know that we meet all other prerequisities (WADs, passwords) for the game to be properly started.
2. This must happen only when explicitly triggered by a conscious user action, such as double-clicking on the server on the server list. It is forbidden to ask for the game version in the background, on mouse hover over the server row or on Doomseeker startup.
3. If it happens that the launched executable doesn't understand the `--version` argument, this needs to be handled in a way that won't prevent the actual execution of this executable without `--version`. That way it will still be possible to run a game version that doesn't support the `--version` argument, for example if someone intentionally wants to use zdoom.exe instead of Zandronum because they're doing something creative.

Points 1 and 2 guard from a case where user accidentally points to the wrong program (like zdoom.exe, or something with slothlike startup like GIMP) and having that program launch several instances at once out of the blue. The situation will not be any different from what it is already.

The problem with point 3 is that solving it in a clean way may not be possible. If we run 'zdoom.exe --version', the game still starts up, showing its UI elements. It doesn't matter if we kill it 2 seconds or even 200 milliseconds later as the user will already see that something strange is happening. This doesn't provide the best user experience and can even corrupt people's configuration files if we snuff the instances out like this.
User avatar (0020434)
Pol M (developer)
2019-03-01 19:19
edited on: 2019-03-04 15:15

Quote from Zalewa

The problem with point 3 is that solving it in a clean way may not be possible. If we run 'zdoom.exe --version', the game still starts up, showing its UI elements. It doesn't matter if we kill it 2 seconds or even 200 milliseconds later as the user will already see that something strange is happening. This doesn't provide the best user experience and can even corrupt people's configuration files if we snuff the instances out like this.

I was thinking more on a sigterm rather than a sigkill, but I agree that there has to be a way to get around the case where a creative person uses zdoom or gimp as their zandronum client ;). The best option, in my opinion, is definitely to add the two modes, this way a user can set it to "system mode" and play doom on all its brushy-peppery glory. This way if that person does not know what they are doing, said person will notice that something is off in the default "internal mode", and in two seconds the sigterm would kindly ask gimp to try harder next time and close. This person will hopefully fix his config, or in case that they wanted explicitly that, they can change modes.

I agree on points 1 to 3.

pr

User avatar (0020437)
Pol M (developer)
2019-03-06 21:48
edited on: 2019-03-06 22:04

So, let's look at if the current implementation could be used in the rest of the plugins:

  • Turok: No

  • SRB2: It would be possible, but this actually may present some important challenges. First of all, SRB2 uses wads that cannot be downloaded by Wadseeker and some of them seem to be the downloaded ones from the installer. I know zandronum also uses its own wads, I'd have to look into it (I really don't use it so I lack any experience with it). An implementation of the auto update would only be interesting for windows (I can mostly overcome this issue). Also, currently it is distributed in an installer, that while it could be run, I do not trust the user to install the program in the correct place. To solve this, maybe we could ask them to host a zipped (anything but a .msi/.exe) version.

  • Odamex: Only makes sense for Windows, this one should not give problems. Zip provided.

  • Chocolate Doom: Since it uses multiple engines it may be slightly more tricky, but they also provide zips. Only interesting for Windows.


So, I think that at least Odamex and Chocolate Doom should be implemented. SRB2 may not be that worth it ftm.

User avatar (0020460)
Pol M (developer)
2019-03-30 16:15

I'm pretty much done here. Now into revision and hopefully in no time we can close this ticket!
User avatar (0020523)
Pol M (developer)
2019-04-21 16:05

I have realized that there are things left to do :/
User avatar (0020658)
Pol M (developer)
2019-05-14 17:29

Okay, I have a small issue with chocolatedoom. It turns out that if you don't give a valid iwad, the program will display a warning. It will of course flash out rather quickly, and if I tell it to connect to the local server (localhost) it seems to not say anything (regardless of whether a local server is running or not). So, I guess that since in most cases people will have at least freedoom downloaded, a warning should be enough? I'd put the warning in the config.
User avatar (0020666)
Zalewa (developer)
2019-05-17 15:26

If you don't have any valid IWAD then the game won't run anyway. If the game won't run, is there a point in trying to determine its version? To obtain ChocoDoom's version I think you could just pass the first IWAD that is found - any IWAD that the user has. If there are no IWADs, don't run the game - the version checker should be disabled.
User avatar (0020667)
Pol M (developer)
2019-05-17 16:35

Good point, I'll do that.
User avatar (0020678)
Pol M (developer)
2019-05-20 13:56
edited on: 2019-05-20 13:59

Okay, now I'm quite sure that it is finished. I'd still need to resolve the merge conflicts, but I'd like to first hear your thoughts to prevent too many merge commits :)

EDIT: Just to make this clear, this is a mainly Windows project, on Linux only Zandronum will change.

User avatar (0020781)
Zalewa (developer)
2019-06-20 10:01
edited on: 2019-06-20 10:02

I have accepted the PR but pushed it onto a separate internal-clients branch. The reason is that this is a large task that changes the main functionality of the program and we shouldn't just put it on the default branch and hope that things will "just work". It was also necessary to merge the PR already as it has become outdated and a conflict mess. Work simply couldn't continue in the current PR.

The commit line was mostly clean so I kept all the intermediate commits. Still, I've rebased the PR onto the default's tip and cleaned up each commit to ensure there are no "crustify" problems (aside from possible mispositioning of &/*) and that each commit compiles. Further work can build on top of that.

I've also turned internal clients off by default - at least for the time being. This can be re-enabled once we're sure there are no problems with running the "system-installed" game.

I've removed Odamex Win64 clients for the time being. Using Win64 clients on a 64-bit Windows is a good idea, however it was not implemented correctly. Windows "bitness" should be a runtime check, not an #ifdef. We don't compile a 64-bit Doomseeker.

After some brief testing these are the problems that I've encountered:

- Chocolate Doom output is not captured correctly on Windows. I have version 3.0.0 installed, I try to join the 3.0.0 server and Doomseeker wants to install 3.0.0. I checked what gets grabbed by the stdout grabber and it turns out that there's nothing - the string is empty.
- Likewise for Odamex - I have 0.7.0, I try to join 0.7.0 server, it wants to install 0.7.0.
- With internal clients enabled there's a significant delay when joining Odamex servers.
- Odamex checker creates odasrv.log in the current working directory (in my case it was next to doomseeker.exe).
- Ignoring missing WADs doesn't work anymore for Zandronum regardless of whether the internal clients are enabled or not.

User avatar (0020785)
Pol M (developer)
2019-06-20 21:22

I'll take a look :)
User avatar (0020883)
Pol M (developer)
2019-07-19 14:38

Okay, there are a few things that are necessary for Odamex to work properly:
- Reduce the amount of time that we allow Odamex to output. This will prevent it from hanging doomseeker.
- run it in a temp dir to not have to deal with odasrv.log
- The server executable that comes with Odamex must be set. This is due to the fact that it's the only reliable way to get some sort of output. I'll add a way to warn the user. I don't know why I didn't already.
- I'll find a way to check the OS bit thingy in a 32-bit build :)

Chocolate Doom is slightly more complicated:
- It likes blowing up doomseeker through dark magic.
- So, I've decided that I'll make chocolate doom use only internal clients when enabled and only system clients when disabled. I'll include a warning. I've tried to solve this through different ways, but at this point I've decided that there's only so much I can do.

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: carpathia Fused boko Unknown Pol M
Opponents: WubTheCaptain

- Issue History
Date Modified Username Field Change
2014-10-13 21:30 MazterQyoun-ae New Issue
2017-11-03 11:16 WubTheCaptain Note Added: 0018738
2017-11-03 11:16 WubTheCaptain Status new => acknowledged
2017-11-03 15:00 Zalewa Note Added: 0018742
2017-11-03 15:05 Zalewa Relationship added related to 0002017
2017-11-04 00:10 Blzut3 Note Added: 0018753
2019-02-14 18:25 Pol M Note Added: 0020387
2019-02-14 22:03 Pol M Assigned To => Pol M
2019-02-14 22:03 Pol M Status acknowledged => assigned
2019-02-15 03:50 WubTheCaptain Priority none => low
2019-02-26 16:04 Pol M Note Added: 0020430
2019-02-27 10:26 Zalewa Note Added: 0020431
2019-02-27 10:26 Zalewa Note Edited: 0020431 View Revisions
2019-02-27 10:27 Zalewa Note Edited: 0020431 View Revisions
2019-02-27 17:24 Pol M Note Added: 0020432
2019-02-27 17:45 Zalewa Note Added: 0020433
2019-03-01 19:19 Pol M Note Added: 0020434
2019-03-01 19:20 Pol M Note Edited: 0020434 View Revisions
2019-03-04 15:15 Pol M Note Edited: 0020434 View Revisions
2019-03-06 21:48 Pol M Note Added: 0020437
2019-03-06 21:50 Pol M Note Edited: 0020437 View Revisions
2019-03-06 22:04 Pol M Note Edited: 0020437 View Revisions
2019-03-30 16:15 Pol M Note Added: 0020460
2019-03-30 16:16 Pol M Status assigned => needs review
2019-04-21 16:05 Pol M Note Added: 0020523
2019-04-21 16:05 Pol M Status needs review => assigned
2019-05-14 17:29 Pol M Note Added: 0020658
2019-05-14 17:29 Pol M Status assigned => feedback
2019-05-17 15:26 Zalewa Note Added: 0020666
2019-05-17 16:35 Pol M Note Added: 0020667
2019-05-17 16:36 Pol M Status feedback => assigned
2019-05-20 13:56 Pol M Note Added: 0020678
2019-05-20 13:56 Pol M Status assigned => needs review
2019-05-20 13:59 Pol M Note Edited: 0020678 View Revisions
2019-06-20 10:01 Zalewa Note Added: 0020781
2019-06-20 10:02 Zalewa Note Edited: 0020781 View Revisions
2019-06-20 21:22 Pol M Note Added: 0020785
2019-07-19 12:47 Pol M Status needs review => assigned
2019-07-19 14:38 Pol M Note Added: 0020883






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker