Steam not logging Godot usage time correctly. #18233
Comments
|
For anyone who wants to investigate, it seems to work fine on Linux, Steam manages to follow the process forking when opening a project from the project manager. But Windows doesn't seem to handle it (at least Windows 10 - there are reports of it working fine on Windows 7), and some OSX users seem to experience the issue too. |
|
yeah I'd really love if this was fixed somehow ... here's a link to a comment on steam summing it up: |
|
I am currently launching second project editor just to log the time, which does not feel very right and also I sometimes forget to do so. I really hope this is going to be fixed some time soon. |
|
It does not work fine on Windows 7. It only tracks time at the project management window. When opening a project it does not track, and Steam does not show as in "Godot Engine". Would like to see this fixed. Time tracking is a big part of why I used Steam for the distribution. |
|
Couldn't a simple fix be that Steam logs time in the console that is constantly open when engine is running? |
|
Yeah, that should be done as @wingedadventurer said. |
|
I experience this issue on Linux when starting Godot with a This causes the editor to instantly close 5 seconds after I open a project. |
|
I have made a duplicate of this issue, probably because I have searched for the keywords "Steam" and "hour", not "time". Sorry, for that. What I will probably do myself to solve this problem is to make a small wrapper that starts Godot, replace the Godot Steam binary with this wrapper, which waits until there is no Godot binary running for 10 seconds, then exits. Also, I thought this bug was fixed already. I remember it working correctly before 3.1, but that's just probably my brain being messed up. |
|
Still not counting in v3.1 stable on Windows 10. |
|
I have created the wrapper for my personal needs, but in case someone else needs it too, I have uploaded it here: |
|
I would really love to see this fixed. Coming up on a year now with no action. Thanks for the work around, @UnleavenedEagle ! |
|
Given that people finding this on steam will only see people with 3-4 hours at max (even though those people may have spend thousands of hours in the engine), this may actual affect potential users. When I first read through the reviews I was confused why exactly nobody on steam used Godot for more than a few hours. |
|
That's a good point, @tumGER. I have managed to actually log time with @UnleavenedEagle's fix, so hopefully that will encourage the devs to make this change. |
|
It seems to work for me on Ubuntu 19.10. I have 113 hours clocked. However, I agree that it would be nice to get this fixed across the board, since it could have an influence on new users reading reviews (as your play time is shown when you write a review). Also, I notice that there are several games on Steam that use launchers (like GTA5, Tomb Raider, etc.) so there must be a way they are doing it, since those games do track time correctly. |
|
Found a workaround for Windows: |
|
To add to this, now that 3.2 has launched, you now have an option to hide the console window in the editor settings (console still starts but gets hidden a couple seconds after Godot launches). Not sure whether this breaks some of the workarounds that make Steam track the console window instead of the project manager window. But yeah, this is getting ridiculous now. A big portion of the overall engine downloads probably comes from Steam because of how nice and convenient it is. This HAS to be fixed, it's trailing along almost two years now. I've probably spent hundreds of hours working in this given that I seemingly spent 14 hours in the project manager alone, which usually stays open for about a second. Tracking time is a big part of the Steam experience which is marred because of something seemingly easy to fix. |
|
@Rriik We're still looking for someone to propose a workaround we can integrate without any downsides or quirks 🙂 If it can't be submitted via a pull request, please write a comment describing all the required steps here and Akien will take a look. |
|
@Rriik My method is still working. I'm not sure about @viteo's method, but I've tried it out before, and there was a little flaw with it, that is it didn't exit the wrapper console after Godot has been closed, you had to close it manually and if you didn't close it, it would keep running even after Godot exited. @Calinou When you start Godot via Steam, it launches Godot with the arguments You can solve this by letting the first process only exit when the second process exits, and only exiting the project list window and not the process after selecting a project. |
|
@UnleavenedEagle This would require a significant rework to keep the project manager process running after a project was opened. Also, remember that you can go back to the project manager while a project is open by using Project > Quit to Project List. In this case, what would happen to the running project manager process with the hidden window? In theory, it could be shown again, but we need some way to signal this to the hidden window from the editor. |
|
@Calinou As I understand it, the typical method of signaling a separate application is to use networking. For example, the recommended approach when someone wants to create an MDI application with Godot is to network multiple applications together. To be honest, that sounds like an awful lot of work to squash one teeny-tiny bug - there should be multiple benefits to such a massive undertaking. Using a wrapper executable (such as UnleavenedEagle's C# script) as the parent of all the applications seems to be a functional workaround (both in Windows and in Linux; unsure about MacOS - and yes, this is also an issue on Linux-based Steam); perhaps wrapping the Godot executable in a small "launcher" executable could be a viable solution? I'm unsure as to what functionality (error messages, etc.) might be lost if the engine itself were not the top-level application, but I see no difference in application behavior except that Steam is able to properly track my time "in game" when the wrapper is in use. As for the severity of this (arguably trivial) issue, having such an obvious problem with Steam integration in an application designed for creating games (which might then be published on Steam) says potentially unpretty (and arguably untrue) things about that application and its competency at achieving the stated goal. I love Godot, and I'm not trying to offend anyone when I say this is likely not doing wonderful things for Godot's image in the Steam community. I'm not confident enough to contribute myself, but an eager and knowledgeable contributor might see this as low-hanging fruit. I'll keep my fingers crossed that these "teething issues" with Steam integration are fixed quickly :-) |
Worked easily and perfectly @UnleavenedEagle, thank you :) |
|
The problem's still here. I don't know much about how it works, but can't it be set to the CMD console where Godot is also runnin instead of the project manager? |
Yeah, it stopped working randomly. I found another workaround: After launching your project you'll notice that's when Steam stops reading that Godot is open, so if you launch Godot again and keep it on the launch screen, it'll keep logging your time. |
|
This issue seemed to have been fixed in Godot 4.0 and was working great. But in Godot 4.1 it's broken again. Same issue: works with the project manager. Stops tracking as soon as I open a project. |
|
i did a clean install of Windows, Steam, and Godot (4.1.3) and hours are tracked properly now. does that mean it is fixed? |
|
Not logging on |
|
The initial reports of this issue on Steam were made in 2016. Why is this still a problem in 2024? |
We don't know a way to resolve the issue that has no downsides for non-Steam users and doesn't involve a Windows-only wrapper executable. I don't think a wrapper executable is a great solution to the problem as it involves a lot of added maintenance (such as managing its codebase that is completely separate from Godot). The only reasonable alternative I see is merging the project manager and editor processes together, which is desired for some platforms (web editor, Android, future iOS port) but is a ton of work and would also come with some downsides. |
1: Why would a wrapper executable be a Windows-only solution? What "codebase" do you envision for an app that simply babysits the process chain and exits when the last child does? 2: Why is a Steam-specific solution unacceptable? Steam users already get a "streamlined experience", with no option for a console window and no option for a language other than GDScript. 3: Leaving as it is makes it look like the project is either unwilling or unable to fix it. Are we malicious, or incompetent? |
|
There is no reason to attack the maintainers, it instantly voids the valid arguments made beforehand. Yes, this issue does create some problems as we discussed 5 years ago but in the grand scheme of things it's still a tiny issue. |
I'm not attacking anyone, I'm pointing out the optics of the situation. It looks like the devs don't care, and it looks like the software doesn't work. At best, there's a perception of "jank" and an impression of apathy, because of a supposedly minor issue that has existed for the better part of a decade. If more than 2,000 contributors can't figure out how to tell Steam the editor is still running after a project to edit is selected, eight years after a dev responded and said they'd look into it... why should (potential) users think there aren't deeper "insurmountable issues" that make this entire product unsuitable for creating games... especially if they want to publish those games on Steam? Is this really a problem that can't be fixed? |
|
You were given clear reasons why this isn't trivial to fix and why it has negative consequences for everyone else, think about why you need to ignore every point raised in order to make your argument And for what? Tracking use time for the editor in steam? Why is that so extremely important you think we are actively ignoring this hugely important issue because we haven't solved it yet? You're welcome to fix it yourself if it's so easy 🙂 (also just go ahead and test the linked PR which might solve this instead of complaining 🙃) |
No, I was given hand-wavy excuses as to why no one can possibly find a workable solution (this is sarcasm, in case it didn't come through)... but UnleavenedEagle's wrapper seemed to work quite well for many users, for many years. Unfortunately, that github account no longer exists, so users are back to "run the editor twice" as a workaround. Yes, really.
What do you have against people wanting to track their usage time via a system that exists specifically for doing exactly that? Why shouldn't Godot properly integrate with Steam? According to steamdb, somewhere between 200,000 and 1.2 million people own the Steam version of the software... but only a few hundred appear to actually be using it. Steam is only aware of the software's existence for a few seconds per session. Half the Steam reviews have less than 30 minutes of use time. Many of the people talking in the forums about their various issues have less than an hour "in-game" listed on their profiles. It looks like no one uses the software, which convinces others they shouldn't use it, either; the phrase "not ready for prime time" comes to mind. All of that aside, this is supposedly a piece of software you can use to make games. Steam is the game distribution platform; nothing else even comes close in terms of userbase size, availability of content, or ease of use... Is Godot not capable of making games that run properly through Steam? If the Engine itself doesn't work right, why should anyone believe the games created by that engine will?
The tests for that PR seem to pass with flying colors; also, I don't (and shouldn't) have the access rights required to merge it. Just as importantly (to me, anyway): why are you attacking me over this? |
|
No one is attacking you, get over yourself... I meant to test it out, run it and see if it works, that's how things are tested, no one said you should merge it so stop being ridiculous I just updated the milestone because we released 4.2, and it very clearly wasn't in it, it's not my responsibility |
|
As a casual follower of this thread, I still cannot understand why this has lingered on, unfixed, for so long, other than the project maintainers just don't understand why (or even if) this is important. The idea that is is too difficult or too time consuming is hard for me to credit. |
|
Maybe this is a matter of perspective; maybe the issue is that the people in charge perceive this as a feature request, while the users see it as broken. You're right, though... it's not a huge issue. People already think Godot can't handle 3D; what's the big deal if they think Godot can't even handle being on Steam? |
|
To be clear, I consider this as something broken, in need of fixing. It was one of the first things I noticed when I was checking into Godot in 2018(!) and came and found this bug. It's a broken window. After it lingers long enough, it starts to suggest a pattern, rightly or wrongly. |
|
Regarding the linked PR, it has a very practical consequence too: #79126 (comment) It would mean we'd either have to create dedicated Steam builds and double the build time for desktop platforms, or make all official builds have support for interacting with the proprietary Steam DLL (which is legal and doesn't force us to distribute the DLL outside Steam, but may concern some users1). The shim code added in the PR that interacts with the Steam DLL is open source, but the Steam DLL isn't. Footnotes
|
Isn't that an automated process? Isn't the version of the software distributed on Steam already its own build? If not, why isn't it? |
It's an automated process, but it's a lengthy one as Godot takes a long time to build, even on high-end CPUs. The builds are also relatively large in terms of file size. Considering there are other topics that may require us to multiply our build matrix, having to double the number of desktop builds just for Steam doesn't feel like it's worth it. C# builds would also need to be built separately to have Steam integration as well, further complicating the eventual integration of C# support in the Steam version.
Regarding the console wrapper, I'm not sure why it's missing. It could probably be added but you'd have to choose it explicitly using Browse local files (perhaps it could be exposed via a Steam launch option). |
|
A little extra work to properly support what is arguably the largest software distribution network on the planet, the target of a huge proportion of the Godot userbase's efforts, the raison d'être for why many are using Godot in the first place... "doesn't feel like it's worth it"?
In the official downloads from the website, the "console" implementation is a separate executable; one which is not provided via the Steam install process. As far as I am aware, there is no Steam launch option that will launch an executable which was not downloaded. If the console is already a built-on wrapper, then what's the show-stopper on simply wrapping the whole enchilada in something to babysit the process chain? UnleavenedEagle's wrapper solution was "quick and dirty", but appeared to work quite well, with (as far as I could tell) zero side effects other than adding a few MB to overall memory usage. It feels like a reasonable assumption that the extra memory required could be reduced to a few KB, if it wasn't necessary to (re)include all the boilerplate and support libraries just to have a "parent" process watching all the children. |
Let's keep the goalposts in one place, yeah? This is a separate issue, one which is completely irrelevant to the issue at hand; there is not now and has never been C# support in the Steam version of Godot. Please don't point at this as a reason why the Steam version can't behave in a fashion that lets Steam see the engine is "running". |
|
Top Rated All Time guide on Steam is litterally "how to make babysit-process" for Godot.
I would agree that Steam stats might influence the popularity of the engine. But I'm also assuming that a large portion of the audience doesn't use it through Steam at all. |
|
Just throwing my 2 cents here, but honestly, having Godot show up in the top charts of steam would bolster a lot of confidence to the engine. I still see a lot of people thinking of Godot as a neat side project when it's actually a very feature complete engine. It might seem stupid that people get hung up on these little things (like counting time) rather than the big new features that could be made, but, just like games, it's the little things that really make a thing stand out. I also can't quite understand what's so difficult about simply distributing to steam the already built binaries that are distributed on the website. Downloading from the website comes with a |
I understand the point that people using it through Steam want to know their use time. I love having my 4000+ hours in Aseprite, it gives great bragging rights. But thinking that it will have an impact on the Steam platform is absurd. There are millions of players pumping hours into games, the couple of hundred (at best) Godot developers that use it through Steam is a very small part. |
The Steam binaries are the exact same binaries as the binaries distributed on the official website. We don't maintain separate Steam builds as having to compile separate binaries would take a lot of time. The console wrapper isn't used by Steam though as this requires a separate window to always be open while the editor is running. On top of polluting alt-tab cycling, closing the console will close the editor without any warning, which can lead to data loss. Blender had similar issues when it had an always-visible console back in its early days. |
|
There's an open PR already I still have to assess #79126, but so far I've prioritized more important engine functionality than an external tool sokng time tracking. I'll lock this because it's getting too heated, it will be solved eventually when I can prioritize it. |
and others
Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.
Godot version:
3.0.2 (steam)
OS/device including version:
Windows 10
Issue description:
Steam can't log correctly the time spent on Godot. It stops logging the time after you start a project, i guess because it spawns a new process. This also happened in godot 2.
I would like to see this fixed, since i like to know how much time i spend on things.
I found the same issue discussed on steam forums, I even read that this was going to get fixed in godot 3.0 but ofc it's not.
Related discussions:
The text was updated successfully, but these errors were encountered: