Cameyo

mule wrote:

---

Can you upload your package to a file-sharing site and advise the link?  You can PM if you prefer.  WeTransfer is easy to use for uploaders and downloaders.

---

 No problem. It's free software, so no worries there.

 

http://www.mediafire.com/file/e0y8fc5mu4avvm5/Kings_Quest_I_Quest_for_the_Crown_4.1c.cameyo.exe.zip

 

Also, I created a virtual machine with Windows 10 for the sole purpose of making cameyo virtual packages. I assume that should be ok to make them in a virtual environment? However, I experience this error regardless of that.

-- Edited by lukeman3000 on Wednesday 8th of February 2017 05:33:56 PM

-- Edited by lukeman3000 on Wednesday 8th of February 2017 09:11:23 PM

Ah. So, all I need to do is choose a different PDF reader and it should work?

Also, are you saying that it would be a bad idea to build in Win 10 and use on Win 7?

Thanks for the help. Cameyo is pretty cool.

I installed Chrome on a Win10 VM, made it the default PDF reader through Windows' Settings | Choose default apps by file type, and your package opened the manual in Chrome.

If the file is located in the package, it is part of the virtual filesystem, so it shouldn't matter if the package is used from a different location or on a different system.

 

I'm checking with R&D why including a PDF reader with the package no longer behaves as it did with older Operating Systems.

 

 

lukeman3000 wrote:

---

Also, is there a way to create a shortcut or something that would launch a particular module directly, instead of having to double-click the exe and choose the module?

---

Run your package with -CreateShortcuts.  Documentation here.

Any update on the PDF issue?

mule wrote:

---

lukeman3000 wrote:

---

Any update on the PDF issue?

---

 Not yet. What hoops are you jumping through to get it to work?

---

I was just referring to making sure that either Chrome or Edge is closed before attempting to open the pdf. But for now I'm just going to include the pdf separately of the virtual package and not rely on the virtual package to open it up for me.

In case you're curious, I'm creating somewhat of an archive of all of my favorite adventure games (such as King's Quest as you have already seen). There have been fan remakes of a few of these games which require installation and so I'm using Cameyo to make the games portable so that I can carry this collection from one PC to the next as desired. The whole collection is completely portable and can operate without any installation.

Two more questions (thanks again for the help, by the way):

1. Is it possible to replicate the action of dragging and dropping a virtual package onto the cameyo.exe with a command-line parameter? In other words, to open up the package editor of a specific package with a command-line parameter? I searched the documentation but I did not see this mentioned, but it's possible I overlooked it.

The reason being is that I wish to make a batch file to include in each folder that has a Cameyo package. The batch file will use a relative path to reference the cameyo.exe which is stored a couple directories up. So instead of including cameyo.exe in every game folder, I include a batch file with a relative path to a single cameyo.exe.

2. I changed the application ID and friendly name of a virtual package that I had already created. After doing so, I get this error when trying to launch it:

Just for fun I tried running as administrator but I get the same error.

-- Edited by lukeman3000 on Thursday 23rd of February 2017 10:54:22 PM

Here's what I entered for my batch file:

"../../../Cameyo/Cameyo.exe" -exec PkgEdit.exe "./KQ1 AGDI Remake.exe"

Now, this does open up the package editor (so the first part is right), but it doesn't open the specific package that I'm trying to reference. For testing purposes I renamed KQ1 AGDI Remake.exe to test.cameyo.exe just in case the spaces were messing something up, or if I needed the .cameyo in there, but that made no difference.

When using my batch file, this is the screen I get:

-- Edited by lukeman3000 on Monday 27th of February 2017 06:05:23 PM

Ok, got it to work. I didn't know that when the package editor gets extracted, it changes the relative position of the batch file, so you have to back out of that directory 9%AppData\VOS\Cameyo\PROG\%Program Files%\Cameyo\). I just assumed that the batch file continued to operate relative to itself and where it's positioned. Interesting.

I've run into another issue. I decided to change the data storage of one of my packages (another game) to "Under the executable's directory". However, for some reason, when the game launches it doesn't correctly read settings from the configuration file that can be configured via the game's setup module. When using the default data storage option, it works correctly. The same behavior exists with other packages, including the one that I uploaded for you earlier.

Any ideas? This is the path of my game folder: L:\Games\D-Fend Reloaded\VirtualHD\Games\Gemini Rue

It's a secondary hard drive that's used for storage - it's not even my OS drive. So I wouldn't think that it would be a permissions issue, but it's kind of acting that way.

Here's a video in which I demonstrate the issue: www.youtube.com/watch

-- Edited by lukeman3000 on Wednesday 1st of March 2017 03:46:00 PM

mule wrote:

---

Try -Remove parameter before changing Data storage location.  At this point, you should -Remove with both the default Data storage and the Changed Data storage before testing.

For packages that have been run before, it is a good idea to -Remove before changing Data storage; otherwise, the Application ID should be changed also.

---

I tried this; it didn't seem to work.

The only thing that seems to work is changing data storage to "default". Otherwise, it seems like it has problems accepting or reading changes to the configuration file. However, other packages seem to work properly with data storage set to "the executable's folder". Seems to be specific to this package. Here's the package on my google drive:

https://drive.google.com/open?id=0B7ntR7VRcUecQjl2ODZXNlNLYWc

For now I'm just going to switch back to default unless you can point me in the right direction to fix this issue

Hi mule -

Any ideas on my most recent issue? I tried your suggestion but it seems to make no difference. However, I have noticed that copying/pasting the package to my desktop allows it to function properly, as opposed to being on my secondary hdd. Tried changing the isolation mode to "full access" but it does not help.

Will try these things. Thanks. However, I like disk mode for being able to save changes. And if I install to L, what happens when I transfer the package to another user's HDD that doesn't have that same drive letter?

Something else I've ran across is the seeming redundancy of having the package along with its extracted contents existing at the same time. For example, I have a game that is about 5GB, but when it's extracted to the hard drive, it takes up nearly 10GB total.

I like that it extracts because I want to be able to save changes. But, is there a way to virtualize the extracted contents without keeping the original package contents around? I'm not sure if I'm explaining this correctly but hopefully you know what I mean.

In other words, if I'm not going to be constantly uninstalling and re-installing the package, is there any way to install the package and then delete the original contents of the package so that I don't have duplicate data, while still being able to use the package as normal?

-- Edited by lukeman3000 on Wednesday 26th of April 2017 02:33:06 PM