Safest way to update OpenFL from old installation?


#1

Currently using OpenFL 2.2.5. Would like to update to the newest release, 4.3.1 (?)
I froze updates a long time ago for a major project of mine. This was prior to a major update to OpenFL that included the addition of legacy mode.

Updating and compiling with the legacy flag should be fine- but if not, what steps do I need to take to reverse the process.

I assume I can simply do a “haxelib set openfl 2.2.5” to revert changes, but there’s a complicated stack of dependencies to consider. Any other notable changes to be aware of that could affect my update process?


#2

You mostly would be changing the “openfl” and “lime” haxelib versions. Give the new version a try, and let me know if you experience issues or bumps along the way, thanks :slight_smile:


#3

I was in the same position a few days ago, updating from openfl 3.6.1.
Made a screenshot of haxelib list and android-sdks, to remember the precise setup.

The update of google-play services was a bit tricky.
But after a bit of fiddling around, getting used to the new system, everything is working. At least for my simple game.

Good luck :slight_smile:


#4

Thanks guys, I’ll give this a shot soon and check back in if there’s an issue.


#5

When did openfl change the location of the shared object/save file?

After updating my installation and fixing some issues, I exported for flash and noticed that my game’s save file was non-existent. I was worried something in the update caused this. However, I downgraded my installation with:

haxelib set openfl 2.2.5
haxelib set lime 2.1.0

And sure enough, after export, my original save file was in-tact.

Is there a way to fix this? unfortunately it’s a pretty big issue that will stop me from going forward with openFL updates.

The code I use to access the save file is:
sharedObject = SharedObject.getLocal(savePath);

It’s possible that this might only apply to the flash export, as I’m currently having issues exporting android under the new openFL.


#6

I believe <meta company="" /> will make the shared object directory return the same path


#7

Then again – I’m not sure that we even have control over the behavior of SharedObject on Flash. Is it possible it’s due to running in a different directory?


#8

All I know is that the original flash save file is located at:

C:\Users\USERNAME\AppData\Roaming\GAME_NAME\file.sol

I’m not sure where it’s looking when I run a version exported from the newer openfl


#9

Ah-ha, the new save file is ending up at:

C:\Users\USERNAME\AppData\Roaming\Macromedia\Flash Player#SharedObjects\MMW4F9ED\localhost\HAXE\GAME_NAME\bin\flash\bin\GAME_NAME.SWF\file.sol

adding the meta company tag did not alter where it searched for the file in the newer openfl


#10

I believe (on Windows) that previously it used “C:\Users\USERNAME\AppData\Roaming\GAME_NAME\file.sol” and now uses “C:\Users\USERNAME\AppData\Roaming\COMPANY_NAME\GAME_NAME\file.sol”

The <meta company="" /> would only affect non-Flash builds (to my knowledge)


#11

I don’t think this is possible. As Joshua said, that’s where non-Flash builds get saved, but Flash apps are required to save to the default location (in your case, the MMW4F9ED folder). It’s possible to specify a custom path, but only within that folder.

There could still be a different save file somewhere in MMW4F9ED, so try doing a search.


#12

You’re right- it appears that file I mentioned was probably part of a windows export that I didn’t realize. After searching, I found two copies of my flash save file: (coinciding with the two versions of openFL):

…\MMW4F9ED\localhost\HAXE\GAME_NAME\bin\flash\bin\GAME_NAME.SWF\file.sol
…\MMW4F9ED\localhost\HAXE\GAME_NAME\bin\flash\release\bin\GAME_NAME.SWF\file.sol

It appears that the newer release of openFL adds ‘release’ to the path it uses to save the file.

If this is a flash-only issue I’m ok with it, because I only use flash for testing. But if this affects all platforms I need to find a fix, or else I’ll be losing the connection to the correct save file for all of my players. I’m having trouble with the android export at the moment (…something related to gradle…?) but I’ll get back to you on that later.


#13

Ah! Now that you mention it, that makes a lot of sense.

By default, Flash saves your file in a path mirroring the SWF’s location. And since newer versions of OpenFL add “release” (or “debug”) to the path, that means that will also be added to the save file’s path.

However, this only applies to your personal tests. Once you upload the SWF file to wherever you host it, its path will be determined by that host. And most SWF file hosts are well aware of how saves work, so they take care not to change the URL.

Also, all of this is Flash-only. You have nothing to worry about on other platforms.


#14

Currently stuck on exporting a windows build with the error:

‘cl.exe’ is not recognized as an internal or external command,
operable program or batch file.

Seems possibly connected to this issue:

(should I be creating a new thread for visibility? not sure)

anyway, I tried re-installing via
openfl setup windows

but still the same issue. there are some solutions presented here: http://stackoverflow.com/questions/8800361/cl-is-not-recognized-as-an-internal-or-external-command

but I can’t find any ‘visual studio tools’ and I’m not sure if that solution applies to me anyway


Windows export: 'cl.exe' is not recognized as an internal or external command,
#15

Did you reboot after installing? I’ve noticed Visual Studio doesn’t always work with HXCPP until you do.

If you use a newer Visual Studio install, like Visual Studio Community, make sure you check the boxes for Win32 C++ support, as that is not supported in the default install options (last I checked)


Windows export: 'cl.exe' is not recognized as an internal or external command,
#16

i look for win32 c++ support but there is not a check box with that label


#17

They might have renamed it to “Windows API”, or in general it’s support for Windows desktop C++