Passability messed up by encrypting the game

Up until the moment of encrypting the game via the 'Compress Game' menu command, everything was fine.

After encrypting and then extracting and playing, whole areas of maps (at least at the beginning of the game anyway) have had their passability reversed.  I can walk on walls or shop counters, but not a floor, for example.

Does anyone have any idea why this has happened and what the remedy might be?  This query is pretty urgent as the game is supposed to be released this weekend.

Thanks in advance for any advice.

if you used the ingame encrption and not another encryption script, then the encryption cannot mess up the passability.


There are several theoretical errors that can make it seem as if the encryption messed up, but in reality it's something else...


1) do you have any script that changes or manipulates passability? if yes, then check if that script needs an external source for the data.


For example there is a script somewhere that uses a picture to set passability as pixel-based, and if you encrypt and the script cannot load encrypted files...


2) check what happens if you make a new game in both editor and after encryption - sometimes loading saved games can mess with changes done.


Check the game without encryption as well - it might be that the bug is caused by a late change that you didn't test before encrypting. If that's the case then the error will happen in the unencrypted project as well

In answer to your questions

1) I am using Shaz' Passage Modding script http://forums.rpgmakerweb.com/index.php?/topic/18012-map-passage-modding/  I have, as per the script instructions, removed the setup script, but left the runtime script.  It doesn't rely on any external source.

2) I tested with new game both in editor and after encryption.  No save files were loaded, and just to be sure, I deleted old save files from the AppData location.

3) The game has been thoroughly tested by 2 people after all changes were completed, so there should be no late change bug introduced.

So the problem doesn't occur when you remove the passage script?

wrong, it does rely on an external file created by the setup script and stored in your project data.
And most probably that is the problem - the passage-file gets encrypted as well, and somehow when loading the encrypted file and syncronising the passage file to the map file the data gets damaged/inverted.


I think you should leave a bug-report on Shaz's topic and wait until she can check the load/save methods of her script for how they could handle encryption...

Yeah, I did a quick simple test with just Shaz's passage mod, it doesn't work then the passages.rvdata2 file is encrypted. The quick fix is to create a data folder post encryption and move a copy of the unencrypted files into said folder. The ideal solution would be for Shaz or someone that knows what they are doing to modify the script so that it can load the encrypted version of the file.

Yeah, it is probably that the file is not getting read properly after being encrypted. I will look into this. Is this the same project that you just sent me? Any particular maps I should look at?

Moving to Script Support

Do any scripters have experience with this? I save the file in the same way the $game_* files are saved. Maybe I should not save as binary? I have a few other files in my own game that save their own data and need to be encrypted (and may have other scripts that do the same), so I really need to figure out how to allow external files that can be encrypted.

You might want to check the SES external text script - I haven't tested this but it's supposed to be able to work from inside an encrypted game, so a comparison on how the data was saved there might help:
http://forums.rpgmakerweb.com/index.php?/topic/6608-external-text-now-v21-unicode-fix/

I don't know how you are reading your data, but you should always use

load_data(filename)No exceptions.There is no reason you would load files any other way using RM.

This is only function (that you would realistically use) that has access built-in to the encrypted archive.

The only difference is that that script does not write as binary.

It does use load_data.

I looked at the script. Here's the problem:

if File.exists?("Data/Passages.rvdata2")The File module doesn't know how to read from the archive.If you must do this check, you will need to use a rescue.

Oh ... File.exists? will only work if the file is NOT included in the archive?


Thanks Hime - I'll give that a go and see if it fixes the problem :)


What about FileText.exist? - Enelvon's script uses that (to see if there's a text file that needs to be converted to rvdata2).


Now to go check all my OTHER scripts too!

FileTest doesn't work either.


Basically, anything that's considered "standard ruby" doesn't know how to handle the archive.


However, what Enelvon's doing is different: it's done during development time, not during runtime. Encryption only matters when you're releasing your game, and likely when these bugs start to get noticed.

I may need to use the quick fix if there is to be any chance of the game being released this weekend (though that now may be too optimistic)

However, I don't think I quite understand what is being suggested.  This is what I think it means:

Encrypt everything except the data file in the normal way.

Copy the unencrypted data file from the original game into the encrypted folder.

Is that correct?

@ Shaz

This isn't the game you have been looking at with the fog issue.  That one is only half done.

EDIT

As I suspected, I haven't understood Selchar properly, as I cannot see how to copy the data file into the encrypted folder (the 'ice cube' file).  If it is in the same folder as the subsequently extracted game, the game cannot read it - on clicking the 'play' icon I immediately get an error message that it can't read scripts.

I am also uneasy about having all that data unencrypted - I might just as well release the whole game unencrypted.

I've implemented Hime's suggestion and updated the script. Can you redownload the runtime script and try compressing again? Let me know if the settings work this time.


If this works, you will not need to follow Selchar's suggestion. The data should still be encrypted/compressed, just as you did the first time around.

The script has indeed been fixed to properly support ace's encryption, however for future reference, what I was suggesting was as follows.


1: Encrypt/Package your game normally.


2: Extract it.


3: Create a new Data folder


4: Copy the passages file from the original unencrypted project's folder into the newly created data folder.


5: Re-package into a self extracting executable/installer with some program of your choice.


Pretty simple, however your confusion is understandable with the rushed nature of holiday times(and your game's imminent release).


Well, with the script fixed you won't need to do that, so the last thing I'd like to say is good luck with your game's release!

Yes, and that's exactly what we've done in the past with things like images (splash screens in particular) so we can send the game to different portals and they can add their own splash screens. It's not difficult to do - just a few extra steps. But it all adds to the stress when you have several things that must be done "just right" :)


Thanks for checking that Selchar.

@Selchar

Thanks for explaining it to me.  You're right, it is simple - once it's been explained!  As for getting the game out this weekend, that's looking increasingly unlikely because of the need for testing.  And if it doesn't go out now it will have to wait until after the New Year, as I don't think it's sensible to release it too close to Christmas.

@Shaz

A quick test seems to show that everything is fine.  However, I think I need to do a bit more testing to be on the safe side.  If anything crops up, I'll get back to you.

Thanks for sorting it.

According to the first few posts in Enelvon's External Text Topic, that part of the script is supposed to be executed in playtest before encrypting the game - Enelvon specifically states in the forum topics about "External Text" that the script requires to be playtested at least once with the final game before being encrypted, and that part of the script will then convert the original plain text file into the file needed to run in encrypted form.
So you're both right in a way - the file-parts of the code are not able to be executed in encrypted games and most likely the source of the problem. Enelvon worked around that by requiring the script to be executed once before encryption is possible, and creating the different files that are needed for encrypted games in that playtest-run.