• 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 Have they finally gotten rid of Sandboxing?

hdarren

Member
I don't have the beta to see for myself but have YoYo finally seen sense on this issue and gotten rid of the horrible sandboxing for Windows?
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
There will always be extensions to get around this.

Sandboxing on Windows is there to remind you that by reading and writing the files from wherever you potentially screw your future self over, since Windows is the only platform to be so permissive about filesystem i/o, and building the game upon that will mean rewriting substantial chunks of it when you'll get to exporting it to non-Windows platforms.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
The funny part is they already had the code written from previous versions, a simple copy and paste. As for Yellow's argument, there's no reason they couldn't have been modularized and a setting added to enable them, with them obviously being disabled by default, in order to get the point across to novices.
It is not a matter of "having the code". It is more code to enforce sandboxing rules on Windows, since WinAPI will only prohibit writing to directories covered by UAC (Program Files, Windows, administrator' directories, ...) by default.

A setting could definitely be added (disabling the checks entirely) and likely wasn't added so far only for how easy it is to workaround this with extensions and how many extensions have accumulated for this over years (even majority of GM6 DLLs still load and work correctly in Studio).
 

Mike

nobody important
GMC Elder
Sandboxing is incredibly important when users suddenly start to export to other platforms, and then suddenly it all breaks. We then get support tickets asking why this is, only to discover after hours of searching through their code they've been trying to save stuff to "c:\MyGame\test.dat" on an android machine. Sandboxing takes care of all the cross platform issues, including when loading from a compressed ZIP on android to saving into the correct areas.

If you don't want it, there are extensions to bypass it, and this also means when you try to export to android, you'll figure it out yourself as a windows DLL won't export.

Just because you may not be a novice, doesn't mean you know all the save points on all platforms or consoles, and even if you think your being smart by saving to a relative path, that just won't work.
 

hdarren

Member
Not hard to make it throw up a compile error if trying to save somewhere it shouldn't. GM should be adding options for devs not removing basic functionality that literally every other game dev engine has. Allowing Windows users to save to the game's folder is incredibly important.
 

Mike

nobody important
GMC Elder
Allowing Windows users to save to the game's folder is incredibly important.
This proves my point.... if you've installed your game using the games installer (as you should), this isn't always possible as they may have installed to program files, and that's read only.
 

Mike

nobody important
GMC Elder
Nobody uses the installer. Everybody uses the zip file. For example Steam games.
Then your game may not work correctly. The installer will install all the Visual Studio runtimes, directx components - basically everything a user needs to run your game. if you don't.... might not work. This is why folk use installers.

Steam has an install system, so this stuff gets installed. Zips don't.
 

XanthorXIII

Member
Then your game may not work correctly. The installer will install all the Visual Studio runtimes, directx components - basically everything a user needs to run your game. if you don't.... might not work. This is why folk use installers.

Steam has an install system, so this stuff gets installed. Zips don't.
Mike,
Would it be easy to add an option to each export type where you can define where data is saved to? For example under Windows define it as the user folder in a gamedata folder, and then for Android/iOS just lock it to Sandbox?
 
Sandboxing is incredibly important when users suddenly start to export to other platforms, and then suddenly it all breaks. We then get support tickets asking why this is, only to discover after hours of searching through their code they've been trying to save stuff to "c:\MyGame\test.dat" on an android machine. Sandboxing takes care of all the cross platform issues, including when loading from a compressed ZIP on android to saving into the correct areas.
@Mike: "Because our users don't know what the hell they're doing" doesn't seem like a good reason to lock away features for those that do. Instead of forced sandboxing, why not just have a toggle with a warning or something? It seems weird to limit GM so that users don't accidentally hurt themselves...I know GM is supposed to be friendly to beginners, but we're all supposed to be programmers, right?
 

FrostyCat

Member
Sandboxing is incredibly important when users suddenly start to export to other platforms, and then suddenly it all breaks. We then get support tickets asking why this is, only to discover after hours of searching through their code they've been trying to save stuff to "c:\MyGame\test.dat" on an android machine. Sandboxing takes care of all the cross platform issues, including when loading from a compressed ZIP on android to saving into the correct areas.

If you don't want it, there are extensions to bypass it, and this also means when you try to export to android, you'll figure it out yourself as a windows DLL won't export.

Just because you may not be a novice, doesn't mean you know all the save points on all platforms or consoles, and even if you think your being smart by saving to a relative path, that just won't work.
The sandbox needs to be gotten rid of or at least made optional/configurable, precisely because you don't know where all the possible load and save points are. You shut out perfectly valid load and save points and add needless extension dev work for GMS users. None of GMS's competitors do this.

Let's take Windows as an example. Here are a number of valid load and save points that the Sandbox won't allow:
  • Saved Games (under home directory)
  • Another directory in %localappdata% or %appdata% not exactly equal to the project's name (e.g. multiple games belonging to the same company or series sharing data with each other)
  • My Pictures (under home directory)
  • Files passed in through the command line for opening
There are use cases for all of these. We've opened tickets on Mantis about all of these. No action for 4 years.

What about Android or iOS?
  • The photo gallery
  • Camera pictures (DCIM)
  • File paths returned by file selector extensions
All of GMS's competitors allow access to these as long as you set the right permissions and go to the right place. GMS alone makes its users jump hoops and write proprietary extensions, just because its creators fear novice ignorance even when non-novices are using it.

If you insist on a sandbox, I suggest adding the following functions:
  • file_sandbox_allow(path): Adds the specified path to the sandbox's whitelist. Will throw an error if it is inaccessible.
  • file_sandbox_deny(path): Removes the specified path from the sandbox's whitelist.
If anyone makes the mistake in your example or anything along that line, the error message along with the name of the export + OS version would make the problem trivial to resolve.

Let people who are novices play within the sandbox. Let people who aren't break out of it as needed.

This is a should-have for 1.x, and a must-have for 2.x.
 

Fanatrick

Member
To think I was heavily negged for posting this few years back o.o

Nowadays though I don't think anything really needs to change. It's not like it's impossible to do currently. Although maybe adding a sandbox_directory constant, encouraging its use in the documentation and working from there could bring us somewhere.
 
Top