• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Question - IDE GM:S 2 Forces You To Update?

C

colinator27

Guest
I don't appreciate how there's pretty much no way to exit out of the message that states you need to update to the latest version. I spent SO long just trying to install the dang thing (install errors + medium slow internet) and only to open it up and see that inescapable message.

Is it possible for this window to be dismissed without updating?
 

Attachments

Nocturne

Friendly Tyrant
Forum Staff
Admin
You should read the manual on this... Some updates WILL be forced updates and some will be optional. Keep in mind that the IDE and the runtimes are now seperate update streams, so there shouldn't be any reason not to update the IDE everytime. Runtimes can be rolled back too from the runtime preferences.
 

Humayun

Member
Same with me I downloaded GameMaker studio 2 - 3 hours ago due to crappy internet it took me 1:30 hours to download when i open it , it says download new version.
 

Gradius

Member
so there shouldn't be any reason not to update the IDE everytime. Runtimes can be rolled back too from the runtime preferences.
If someone's running with a very slow connection (i.e. dialup) they're forced to wait for a 200mb update before they can use the IDE? Not as bad if they can let the update run silently in the background (why oh why does Studio 1's launcher refuse to actually minimise and insist on sitting in the corner of the screen?) but from the looks of it, that isn't an option.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Like it says in the manual, the majority of updates (AFTER the beta), will be able to be dismissed and run at a later time, but there may be some that are obligatory if - for example - there is a bug in the IDE that causes projects to become corrupted, then an update may be forced.
 
C

colinator27

Guest
Like it says in the manual, the majority of updates (AFTER the beta), will be able to be dismissed and run at a later time, but there may be some that are obligatory if - for example - there is a bug in the IDE that causes projects to become corrupted, then an update may be forced.
(insert thumbs up symbol here)
 
This update was a complete uninstall-and-reinstall.
Will all updates be like that, or will smaller updates be able to 'install in place' ?
 

FrostyCat

Redemption Seeker
Like it says in the manual, the majority of updates (AFTER the beta), will be able to be dismissed and run at a later time, but there may be some that are obligatory if - for example - there is a bug in the IDE that causes projects to become corrupted, then an update may be forced.
If forced updates become a thing, I sincerely hope that YoYo would start drawing a finer line between the breaking feature and other unrelated stuff.

The importance of this is clearly demonstrated by the recent libpng problem. While you have addressed the libpng problem with 1.4.1760 and 1.4.1763, you also opened a whole load of others that don't have anything to do with libpng or even Android in particular. For example, unrelated changes in the HTML5 export that completely shut down its effects, physics and particle systems, or the undocumented forced upgrade to iOS 8+ in the iOS export.

One way to make this happen would be red builds that address specific, urgent changes only --- no bug fixes or changes on any other front to avoid unintended side effects. Using the same example, we could have a release named 1.4.1757-libpng that contains only the libpng fix and support for updated Android extensions. It can be implemented as a separate branch in the repository without affecting further work, and it would greatly improve YoYo's responsiveness to such changes.

YoYo has caused a lot of lost business for those of us relying on you and others at YoYo to resolve point-source deal-breakers on time, that needs to change.
 
Last edited:

Hyomoto

Member
During the beta it would be madness to NOT have us update. It seems like a losing battle to have people testing software that may have already patched up any bugs we're experiencing and if you can't reproduce your bug from one version to the next it may not be what you think it is anyways.
 

FrostyCat

Redemption Seeker
During the beta it would be madness to NOT have us update. It seems like a losing battle to have people testing software that may have already patched up any bugs we're experiencing and if you can't reproduce your bug from one version to the next it may not be what you think it is anyways.
Expecting every update to not open new bugs is also madness.

While new bug reports should only be accepted for the latest version, the option should be open for users to reference older versions in case it worked earlier on. This can help pinpoint regressions and potential fixes.
 

Hyomoto

Member
Expecting every update to not open new bugs is also madness.

While new bug reports should only be accepted for the latest version, the option should be open for users to reference older versions in case it worked earlier on. This can help pinpoint regressions and potential fixes.
I normally might side with your argument, but we're discussing a beta that isn't meant to be an in-use product. The only time I would see this as a problem is if we were building projects. Here that should be a non-issue since at most you'd be working on bug replication anyways and as I wrote before, if it can't be duplicated in a new build it may not be an issue worth further investigation. Honestly, it's a fair mindset when testing to expect to find problems, I won't argue that point, but once again we're testing a not-for-use product here and new bugs just means more reports. Not updating because you're worried new bugs will crop up seems anathema to the cause, I'm pretty sure it's the point.

For the record I'm not dismissing your opinion here. I can generally agree with your points, I just don't think they are wholly applicable to the current testing environment.
 

Llama_Code

Member
I normally might side with your argument, but we're discussing a beta that isn't meant to be an in-use product. The only time I would see this as a problem is if we were building projects. Here that should be a non-issue since at most you'd be working on bug replication anyways and as I wrote before, if it can't be duplicated in a new build it may not be an issue worth further investigation. Honestly, it's a fair mindset when testing to expect to find problems, I won't argue that point, but once again we're testing a not-for-use product here and new bugs just means more reports. Not updating because you're worried new bugs will crop up seems anathema to the cause, I'm pretty sure it's the point.

For the record I'm not dismissing your opinion here. I can generally agree with your points, I just don't think they are wholly applicable to the current testing environment.
I think @FrostyCat is speaking more about forced updates on the final product, and in the case I could agree.

We shouldn't me doing anything worthwhile in the beta so that's a non issue. But I know of several instances with 1.x where I chose not to update because I was in the middle of a project only to come to the forums and find that update caused major issues, and that was the stable version.

GameMaker is such a diverse product it's hard to know what unintended consequences can arise by fixing something else.

I don't care about beta updates. But if forced updates (aside from the UI) became a standard practice on the final build I wouldn't be happy. I already battle enough with Window 10.

I get that people are stubborn about updating (hell I just read an article about Samsung disabling Note 7s in countries where its legal to force them to turn them in). Buy forcing an inconvenience on everyone because of the few is just asking for more trouble, updating mid project could cause all kinds of lost time and headaches for someone .
 

FrostyCat

Redemption Seeker
I normally might side with your argument, but we're discussing a beta that isn't meant to be an in-use product. The only time I would see this as a problem is if we were building projects. Here that should be a non-issue since at most you'd be working on bug replication anyways and as I wrote before, if it can't be duplicated in a new build it may not be an issue worth further investigation. Honestly, it's a fair mindset when testing to expect to find problems, I won't argue that point, but once again we're testing a not-for-use product here and new bugs just means more reports. Not updating because you're worried new bugs will crop up seems anathema to the cause, I'm pretty sure it's the point.

For the record I'm not dismissing your opinion here. I can generally agree with your points, I just don't think they are wholly applicable to the current testing environment.
I said "reference older versions", not "use older versions".

The situation I'm describing has to do with regressions between beta versions, not bugs that have been solved by the latest beta. If a feature works in an older release but no longer does in a newer one, the bad commit can be identified via bisection and that could give a hint for how to fix it. This is about finding potential solutions in addition to finding problems, and it requires testers and developers to be able to revisit older releases.

Sometimes the solution is in the repository's history, and this can happen for both production-stage and beta-stage software.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
You guys are not quite understanding the new paradigm... The update for the LibPNG issue was a RUNNER issue and the runner updates on a different feed and is now separate from the IDE. You can also roll back the runner to any previous version from the Runner Prefs. This was done precisely to avoid delays for fixes like the LibPNG one, since it now means that we can push out runner fixes MUCH faster since we don't have to worry about also building and testing the IDE, and it also means that people can choose to stick with a specific runtime or rollback changes without any fuss. So, you can get two updates - one is the IDE and the other is a the runner. IDE updates may be forced, but you can roll back the runner ones at any time.
 

JeffJ

Member
Sigh...

Never, ever force something like this in a developer environment. I know that your intentions are good, and we always like to assume that nothing bad will happen, but please realize that this is just asking for trouble. I can think of several reasons not to do this:

  • Time is of the essence, and I don't have time to deal with a forced update that is irrelevant right now compared to my deadline and slow internet
  • Maybe the update brings changes to the IDE that I don't like or want or that simply breaks my workflow
  • Worst case scenario, the update brings with it breaking changes or serious unnoticed bugs that will negatively affect productivity in any number of ways
I really hope you won't have the audacity to claim that forced IDE updates will be thoroughly tested, because as we all know as developers, there is no such thing as bugfree software. Murphy's law comes to mind (also, and I hate to bring this up - the piracy controversy - that was seriously ugly)

Please realize that when you have users that are actually depending on the stability of this software for a livelihood, control for the user is the most important thing. To take that control away is arrogant and in worst case dangerous. This is a very serious decision that will cause trouble down the line. Do you think your reasons for this decision justifies all the things that are wrong with it?
 

Coded Games

Member
You should read the manual on this... Some updates WILL be forced updates and some will be optional. Keep in mind that the IDE and the runtimes are now seperate update streams, so there shouldn't be any reason not to update the IDE everytime. Runtimes can be rolled back too from the runtime preferences.
I didn't know about this but it's probably the greatest thing I have ever heard. It will be great to actually be able to update GMS without worrying about my entire game breaking.
 

zbox

Member
GMC Elder
You guys are not quite understanding the new paradigm... The update for the LibPNG issue was a RUNNER issue and the runner updates on a different feed and is now separate from the IDE. You can also roll back the runner to any previous version from the Runner Prefs. This was done precisely to avoid delays for fixes like the LibPNG one, since it now means that we can push out runner fixes MUCH faster since we don't have to worry about also building and testing the IDE, and it also means that people can choose to stick with a specific runtime or rollback changes without any fuss. So, you can get two updates - one is the IDE and the other is a the runner. IDE updates may be forced, but you can roll back the runner ones at any time.
cool beans
 

zargy

Member
I absolutely do not, under any circumstances, want any kind of automatic or forced updates for any software (especially development software) I use. I have stayed
away from Windows 10 for this very reason.

If this was going to be a free piece of software that I was just playing around with, I might be a bit more lenient. But it isn't. It's a piece of software that's being
marketed as a professional game development package. You are targeting both indie devs and larger studios. People will be actually spending money on this. I do not
want my IDE that I paid money for to decide when to update itself for me. I would love to believe you 100% when you say that every IDE update will be tested thoroughly,
but considering the experiences I've had with GM updates in the past (who else here still remembers the anti-piracy debacle?), I really can't say I do.

Again, I'm sure you have the best intentions at heart with this. But I don't care. For reasons of my own, including the ones @JeffJ already listed, I may be sitting this GM release out.
 

Mike

nobody important
GMC Elder
There are occasions when updates will have to be forced, and certainly during Beta all updates are forced so we can make sure everyone is testing the right thing and not reporting bugs on old versions..
But... occasionally something will happen that means we require everyone to update, a show stopping bug that corrupts things, a server change that means you can't login and use the thing anymore and so on. The runtimes do have a separate feed so it should mean your games will be unaffected, but there ARE occasions when it will happen.
 

JeffJ

Member
@Mike , the thing that worries me about this, is that we have no clear idea as to where the line is for when YYG defines something as serious enough to warrant a forced update - and what you might consider important enough might not be the case for your users.

Furthermore, I've been using GMS almost daily since it was called GMHTML5 beta, and have never needed a forced update - if something was seriously messed up, I did a manual rollback. It might mean I'd miss out on a feature that was only included in an update that also happened to mess things up, but usually I could work my way around that and make the weighted decision myself. I fail to see why GMS2 would be so different as to warrant this behaviour - in roughly 6 years of heavy and even commercial use of 1.x has this ever been necessary. Why now?

It's the same as we discussed on Skype with regards to data mining (in lack of better words) - less control is always worse, no matter your intentions. Try to see this from a user perspective (and in this case, a user who always happens to take absolute worst case scenario into consideration)

EDIT:
For the record, I completely understand your reasonings for this throughout the beta, no worries there.
Once you go 1.x, though, that's another matter entirely.
 

Mike

nobody important
GMC Elder
It's not something we're particularly planning on doing, and with the runtimes separated out it makes it a lot less of an issue, but we need the mechanism there just in case. But we are aware that if things are working, you won't want to change, and it's not something we'll do lightly.
 

ShaunJS

Just Another Dev
GMC Elder
@JeffJ It's really unlikely to happen, but situations like this Beta are why the functionality exists. It's important that we have that option as I'm sure you can understand. We understand the concerns about updates that can interrupt or disrupt projects, it is for this reason you can bypass updates in Studio 1.X.

The same will be vastly true of GMS2 post release. I can't imagine many situations for the paid release branch where we would force an update, but with the software under development and with this very beta, you can understand why the functionality to force an update exists.

If ever we did need to consider forcing an update we're very aware of the problems that could present.
 

FrostyCat

Redemption Seeker
There have been updates that were actually or virtually forced in GMS 1.x's timeline, examples being 1.0.412 after the registration servers moved, 1.1.690 after the "Jolly Roger" fallout, and arguably 1.3.1307 after the licenses kept reverting (along with the iOS ads problem).

While I'm not commending the events that preceded these releases, what I liked about the rollout of these versions are these:
  • You didn't do them automatically without warning. You announced the importance of them and let users upgrade when convenient.
  • You made it clear that there may be incompatibilities and encouraged users to make backups. I made them but luckily never needed to use them, that probably can't be said for everyone.
  • You didn't assume that you know what we're doing, you let us decide whether to give consent. The announcements are written in a way that at least convinced me to give that consent.
I hope you take the experience with these and keep applying it to GMS 2. And please start announcing things in well in advance instead of post-facto.
 

ShaunJS

Just Another Dev
GMC Elder
There have been updates that were actually or virtually forced in GMS 1.x's timeline, examples being 1.0.412 after the registration servers moved, 1.1.690 after the "Jolly Roger" fallout, and arguably 1.3.1307 after the licenses kept reverting (along with the iOS ads problem).

While I'm not commending the events that preceded these releases, what I liked about the rollout of these versions are these:
  • You didn't do them automatically without warning. You announced the importance of them and let users upgrade when convenient.
  • You made it clear that there may be incompatibilities and encouraged users to make backups. I made them but luckily never needed to use them, that probably can't be said for everyone.
  • You didn't assume that you know what we're doing, you let us decide whether to give consent. The announcements are written in a way that at least convinced me to give that consent.
I hope you take the experience with these and keep applying it to GMS 2. And please start announcing things in well in advance instead of post-facto.
There's no reason why we wouldn't.
 

kupo15

Member
Does anyone know what the update was fixing? I forgot to hit release notes on the dialogue box and just installed it. Release notes from the dropdown menus don't show anything I haven't already seen before. My ide crash I reported is still there haha
 
Top