"Play on PC" not working Like UDK.exe ?game=MyGameETC

OLD Thread Title: “Play on PC” not working Like UDK.exe ?game=MyGameETC
Total contents is only 100mb [code and test maps] [if someone wants to download and test for me -just ask for link!]

Issue with “Play-on-PC” different from UDK.exe ?mygame

EDITED POST - Clean up and Issue still remains…

See POST #06

I was hoping some of the remaining UDK members could shed some light on this issue.

I have the same problem i had in 2010, because i never solved it and really want to get this done.
I am (Still) trying to Make a working Save/Load game system *for Health, Location/ Rotation, Items Needed, Items Collected, Weapons etc *


Video explains all:

*** Skips to 5mins to show the issue.*

What works:

  • UltimateSaveSystem [Works in Editor using Play On PC]
  • My SaveGameCode [Works in In Editor and Works from UDK.exe ?game=MyGame.Mygame]

What does not work:

  • UltimateSaveSystem does not work using the shortcut:
    C:\UDK\UDK-2015-01\Binaries\Win64\UDK.exe MainMenuMap.udk?GoalScore=0?TimeLimit=0?game=MazeGame.MazeGameInfo?class=MazeGame.MazeSaveGameStatePawn -DX11 -PC -NoVSync -windowed -INSTALLED -log

I am surprised i have the location/rotation working via code, totally amazed at the kismet solution for saving weapons (using matinee sequences and int’s lol) and at that point i guess that is all i need, However;
Implementation of the UltimateSaveSystem would provide an additional system, making it more robust and helps in many other ways.

Im also perplexed as to why the UltimateSaveSystem does not work outside of the editor

Yellow error msg “unable to bind DLL” shows on compile [UltimateSaveSystem], but if that was the issue, it would not work in editor either - ???-


Hey man, I haven’t downloaded your code and I haven’t picked it apart for myself so I can’t really say for sure. I’m not too familiar with Crusha’s UltimateSaveSystem either. I use Epic’s save game states gem which was pretty complicated to get everything working just right, but in the end saves everything I need. I recently wrestled with that, hopefully for the last time. If you ever want to talk about implementing it, I’d be happy to talk to you about it.

This is a wild shot in the dark, but would running the shortcut as an administrator give your game access to something that it might not have access to otherwise?

What happens if you run it in debugging mode from Visual Studio? What happens if you package the game from UnrealFrontEnd, install it, and run that?

Have you checked the file for yourself, to make sure it’s there when you start your game from the shortcut? If the file is there, maybe see if you can open the file and read a string from it and print it on the screen. That would be a start.

I replyed to your video yesterday.(check if you havent).

What does not work:

This will not work because the dll bind thing with winx64 within the binaries was never finished(there was small info on udn about that if not mistaking???)
And as you can see in the binaries>win64>there is no ¨¨user code¨¨ folder to place the dll bind files,but in the win32 folder you can.So i suspect the final game have to be in win32 mode in order for the save system to work.

I have the yellow error too,unable to bind to dll, but it works in play on pc and on a cooked game so its ok.(and this is vista x64 lol).What is your OS?

As i said,it coud help to check this page Save_game_Tutorial_Menu as he- Shane,me,you and probably someone else in the world are the only ones using Crushas system :confused: Feel free to contact him.He is a very helpful person.

Thanks for your Replies [Nathaniel3W] & [O_and_N]

**Here’s a cleaner video **
[it doesn’t actually include the USS it’s just an overview and thanks vid.]

For Clarity; If anyone else has the same issue:

  • try a binaries>win32bit shortcut
  • or try a full cook

I haven’t actually tried them myself but they sound like sensible solutions and have been confirmed by others [as described above]

Thanks all.

Glad you managed to fix it.Merry christmas :wink:

Ok sorry to bring this back up but im totally confused.

The “UltimateSaveSystem” (USS) does not work with a 64bit shortcut


The USS does work with a Win32 Shortcut


I always run UDK with 64bit, like this;

C:\UDK\UDK-2015-01\Binaries\Win64\UDK.exe MainMenuMap.udk?GoalScore=0?TimeLimit=0?game=MazeGame.MazeGameInfo?class=MazeGame.MazeSaveGameStatePawn -DX11 -NoVSync -nomoviestartup -log

This means that CODE that works with Win32bit, does not work with Win64.

Now this is pretty serious because over the years code produced may have worked with Win32, but i would never have known, likely to have spent huge amounts of time and disgarded many projects when they probably worked…
- A large, crazy f’ing checkpoint system for example - storing every item, weapon, ammo, enemy, activated gate and basically all known activity - D’oh

I read this today:

I have never full cooked or packaged a game in UDK, but would like to have this one project finished…


Q1. What am i supposed to do? - How to continue my project?
Q2. Can someone explain this Win32bit and Win64bit thing?
Q3. am i unable to cook a 64bit version?
Q4. What is killing the code and how to fix the issue?
Q5. what exactly are the differences going to be?


A1. Switching my shortcuts to Win32bit from now on will ensure that future coding actually works.?
A2. Switching to Win32bit shortcuts will kill performance, lose DX11 features or severely affect them.?
A3. if the code does not work with a Win64Bit shortcut when testing - it will not be able to be distributed as a 64bit version?

Did i miss something or is this normal?

My mini project (Lightweight, but complete DevKit and MiniGame that teaches the DevKit) is almost finished. I have a few small issues with other stuff and do not want to post multiple threads and bump others work (everyone else is in a different league to me) - i hope it’s cool for current members to hop on my project thread (ill make it soon) where i will post these lil issues and progress in one place.

  • I see from others work that they may be able to point me in the right direction.

As i said,the UltimateSaveSystems dll files will work in win x32.As you can see in binaries>win x64> there is no user code folder there in order for the dlls to work.Even if you create a folder and make a copy of the ultimate save system and move the dll files there,i doubt it will work :frowning: You can thank Epic for that…
On the other hand i have downloaded games that made use of the save state scripts and i saw that the save feature workes in x32 and x64.

If we somehow find Crusha(the creator of the UltimateSaveSystems ) and you,me,Shane from the world of dasm page and a few others that he know pitch in together,we coud pay Crusha to find a way to make the UltimateSaveSystems work in win x64.

The hard thing woud be to find Crusha as im not sure if he is on the forums.

-When you do a cook game-you get the x32 and x64 executable(feel free to correct me)
-32 bit will not loose dx11
-win 32bit built means that the final game will use only 4 gb ram so you have to optimize?(feel free to correct me)

using a 32 bit dll in a 64 bit exe just wont do.

Pretty sure all regular code works the same on the Win32 and Win64 exe’s. exceptions would of course be external dll’s.
if you plan to ship with the 64bit exe then just stop using the 32bit exe entirely. working with the platform you’ll ship is essential to find potential issues.
… unless you plan to ship both the 32bit and 64bit exe’s? at this point in time I would really recommend to not do it. just stick to 32bit or 64bit (if you can everything to work on 64bit I see no reason to ship the 32bit one at all)

  1. try to make it all work on 64 bit and stick to it, or stick to 32 bit.
  2. it’s 2 different executable files, which have the same code but compiled for different platforms.
  3. you can cook to a 64bit platform. see my thread about that - though I didn’t cover external dll’s as I don’t use any
  4. the code is being killed by an invalid dll for the target platform. to fix it you need to rebuild the dll in the correct platform (64 bit). so grab the dll’s source code (in Crusha’s page), get the appropriate visual studio. build it for 32 bit first (to ensure you have everything correctly set up), and then try to build it for 64 bit, pray it “just compiles” fine. if it doesn’t then try to fix the code yourself (compiler errors will guide you), or hope you can contact Crusha to help you on that. if all that fails keep posting here and maybe we can all help you figure it out.
  5. if all goes well, none. and in my own experience, none. pretty sure that thread you pointed with the say() function is just a minor broken feature (which I think comes from leftover code, as text to speech isn’t really a supported feature in UDK)

A1. yes
A2. it will have a small impact in performance but it depends on your project. you will not lose any DX11 features.
A3. that is correct

this is normal. Epic never supported the 64bit exe for UDK (though full-license UE3 games work just fine when compiled for 64bit), so we UDK users are on our own if we want to make it for 64bit
no worries, we’re a [tiny] community. we’re here to help :slight_smile:

This is interesting.I did something messy today.Cooked 2 levels and after instaling>in binaries i obviously get only the win32 folder.So i just copy/pasted my win64 folder(from the udk 2013-07 and pasted it in the instaled binaries game folder and launching the game from there and works fine and it displays that is in win64 mode.I supose using a different instaler,this coud be one way to pack your game with x32 and x64?

TKBS,i will try to compille the dll for x64 and if i see that im not successful, i will send a email to Crusha.

By the way Chosker,if we have a ¨¨heavy game¨ that works fine in editor x64.When we cook the game to x32,will it use as much ram as it needs on a x64 os windows or will it be cripled to use only 4 gb ram since it was build on x32?(and probably run low on memory?)

I think you should to be able to get both the 32bit and 64bit exes and folders if you modify the manifest files in a different way (adding both, instead of replacing one with the other like I did)

it depends on the scenario:

  • 64bit exe on 64bit windows: will be able to use more than 4gb of ram
  • 64bit exe on 32bit windows: won’t run at all
  • 32bit exe on 32bit windows: will be limited to 4gb of ram (minus system, so effectively your game can only use little more than 3gb of ram)
  • 32bit exe on 64bit windows: it will run, but I have no idea if it will use more than 4gb of ram

but really if you’re able to cook and ship in 64bit I see no reason to also include 32bit: you’re adding support so that your game can be played by less than 8% of Steam users that still use a 32bit OS. then you have to ask yourself how many of those actually play games in that system (i.e. not a secondary laptop, etc), and how many of those actually have the hardware to run your game

In that case i better make sure that the dll works in x64 as this places me in a similar position to TKBS. :confused:
Going to see if i can recompile this.Crusha did left us the Visual C++ 2008 project folder with the source code for the dll.Going to search for a tutorial on how to recompile.

Sorry for the bump.In a cooked x32 game if i type stat memory under the column % of total, I see (4 gb) My pc is with 12gb.
If i play on pc in the x64 editor and use stat memory i still see (4 gb)???

Is unreal using only 4gb max ram for a game in x32 and x64?
Or is there a better command that can show me how much memory(ram and gpu) im using at the moment?

And i did a small test.
Placed 504 skeletal mesh actors with 7 diferent animations looping(made 7 characters and than copyed them to 504).Each character is 15600 triangles.

Played from here in viewport which is x64 and i see with stat memory that the precomputed light memory is 100.24% of 4gb.So i supose ive surpased the 4gb limit?
Than i played on pc whic is x32 and i see that the precomputed light memory is 0?

During the test i have the task manager open to see what is hapenig with the ram.With the edior and scene opened i was at 4.35gb of use.When i started to play on pc it went up to 4.7gb ram.So this scene is using 35 mb of ram?

Im confused if there is a ram limit for x32 cooked game or not :confused:

Big image:

it seems Unreal will reserve a “minimum usable” of 4gb anyway. but I get the same on the 32bit or 64bit exe. and I dont think it’s reliable
for me if I add up the "mem used amount"s in ‘stat memory’, running on PIE on my testmap, adds up to less than 200mb and even then all stats show the same [4 GB]. while windows reports to be using 1gb for the application

you’ll have to stress it with much more than that. and even then I don’t know if you will have a proper answer (do realize that windows uses a pagefile in the hard drive, to avoid running out of memory)

but do you even have a proper level where you go above 4gb?

No,not realy.I was just a litle paranoid :eek:
But it loud be good to download one of those programs youtubers use to monitor ram,memory,cpu and gpu usage.

Hi everyone how are you? Thank you O_and_N for bringing this issue to my attention. (

The Ultimate Save System
Now, the ultimate save system was not created by me but when I found it a “few years ago” it was flawless! (Thanks Crusha!!!) Since technology has changed over time operating systems have changed and how memory and the way data is stored has changed. But moving along I made this post to make a long story short so here we go. This may or may not help but it is worth a try.
First, to this day I still create games using a Windows XP system with 3.5gb memory (its really 4gb but a 32bit system wont use any more), a quad core 2.8gb processor and a cheap and nasty 2gb video card. The reason to why I do this is so I definitely know that my project will run smoothly and efficiently on modern personal computers. So since I have used the ultimate save system I have never attempted to create a game on a 64bit system.
Second, even though I am using a 32bit system once I have cooked the game or project it runs on a 64 bit and 32 bit system.
Third, whenever I have tested/installed a cooked game it has always been tested/installed on a 64 bit Personal computer without any major complications. I am guessing that even though the ultimate save system is in a win32 folder, it does not matter if your system is x64 or x32 once it is installed.

NOTE Be aware though the ultimatesavesystem.dll file has to be installed separately in your project using a 3rd party installer such as Inno because Frontend does not recognize 3rd party .dll’s and won’t cook it. (Thanks for that Epic games dunno why you would even do that with game editing software?)

Your options

  • **Build a cheap 32bit pc. **Building a cheap Pc with a 32bit system may be the only way to go if you want to use the ultimate save system. After all it is only UDK3 you are using and it does not use a great deal of resources and is “outdated”.(Thanks yet again Epic games.)
  • Install a Windows XP emulator. An emulator may be worth a try to install and I think it lets you select a 32bit system. Install UDK3 and then see if the ultimate save system will run on it. As long as your Pc has plenty of memory this may work. Since I have never tried this there are no guarantees but if it does work please let us know in this forum.
  • **Contact Crusha.**The last option is to contact the actual creator of the ultimate save system. I tried a few years ago but had no reply. If someone could get hold of this person and see if they are willing to build a 64bit version of this software would be good.

Another topic I noticed in this forum is (ram) memory usage. UDK3 does use a lot of memory but also uses a lot of GPU and memory in your video card. Even with UDK3 built games 3gb of memory was more than enough to run a fairly decent project or game. The UE engine 4 is extremely greedy for ram memory compared to the udk3 engine. For a good project with the UE4 engine you need at least 6gb to 8gb+ of ram memory. So I would not be too concerned with them amount of memory UDK3 uses. even with my experience with UDK3 if something is too complex it “crashes” anyway. Hence the reason to why level streaming is a good idea in UDK3 for complex or complicated games.

I wish each and every one of you best of luck, never give up and I hope that your game or project becomes a reality. Most of all, have fun!!

Hi people! I did make a post earlier and I am not sure why it is not here. If it isn’t here in the next 24 hours I will try to resend it. Otherwise if it is here then void this message.