Is there anyway to disable this, i'm convinced now after some back and forth that the encryption is causing a serious slowdown of loading vs running in gameguru editor.

As a side issue, it would probably be better to include some kind of zip system so that .dat .pak .whatever files can be used, for example mykesroadsandsigns.dat, zip password encryption is fairly mature, fairly secure (as much as any other method can be when the client has all the tools on the HDD anyway) and used in all manner of places, also allows some measure of happiness for OCD file organisers

Install creator is what I used on that. It is an open source program.

As far as the encryption for standalone builds. It is mostly to protect the artist assets. I don't think there is a way to disable it. It was a requested feature that was implemented back in the Reloaded days.

the install yes, i saw that. I was talking about implementing zip files as data files they can be compressed or not at the users choice, encrypted or not at the users choice, i guess if artists are pulling the string we are all doomed :p

There is a custom licence agreement that tells the game developers to protect the assets from the store, its not up to the artists to make choices what happens to my assets, only their own. Heck, TGC sells an asset packing and encryption system, well it did before all the old site was abandoned and the software put out to pasture.

Also, if i am correct and the encryption/decryption is crippling the standalone game then it needs fixing anyway, it takes at least 4-5 times longer to load than the play button inside of the gameguru editor, something is definitely not quite right with the standalone system. i will try and make a few more different levels and test the theory. If you see my comments in the thread of the guy who posted his swampy forest dino afterworld mod to test, it took near 8 minutes to load that mod. I'll post a full bug report once ive done testing different levels

Also when you exit (esc) a stand alone game back to "Main Menu" its takes forever to get there while one looks at the black screen presented while waiting - not knowing if it's crashed or not. Well I do because after the first time you expect it but your game users wont know whats happening.

Presumably waits are longer the more complex and the more content in your game? My levels only have a fraction of the GG world using a level of content a finished game might contain so the wait could be even longer.

This is a recent thing in the last few versions since V11 or thereabouts perhaps though I don't compile levels to .exe very often.

This is not helped by the horrible windows feature that misrepresents applications as 'not responding' this windows feature ahs fast become the boy who cried wolf feature that wastes valuable time of windows users, sadly still exists in windows 10 :/


i know how that works oddly... over the years ive gotten so used to working with debug builds and libraries that ive gotten used to lowered performance, in this instance debug level is faster than release level, which is a definite indicator of being 'not quite right'

I've always wondered about this, is it actually a fault in windows, or is it bad coding from the applications? Just something I've always wondered, it happens with enough different software for me to believe it's windows because that many developers wouldn't normally code that badly so consistently, but on the other hand it's something you would have expected to be debugged and fixed years ago.

its a feature change in how the OS deals with multi threading and stuff, and yes its definaly windows, first happened i think in windows 7, might have been vista, with the introduction of the 'aero' system, there is a way to stop it happening, but its a deliberate set of code you need to add, so its more of a hack really. Its years since i looked inbto it in detail for another project, i'll see if i can find the relevent MSDN page and link that.

Tho it will probably get deleted as off topic :p

That is flame bait. If you were a store artist and sold your items on the store, would you want people sharing your media willy nilly for free? Probably not. If GG users can turn off encryption themselves, it rather defeats the point of it. Plus I would doubt the encryption is making the difference, GG games just are slow to load in general.

The encryption is needed to stop users releasing a demo, and inadvertently giving away many store items for free. I only wish scripts had the same protection

@ uman


I would imagine this to be a memory thing. All games can have quite a delay from quitting to returning to the desktop. Although, in this case, it seems GG is freeing memory when returning to the start menu, rather than the exit button. I'm sure someone with 16 gig of memory will notice most games exit a lot faster than if you have 4 or even 8 gig of ram. GTA 5 for instance takes quite some time to exit on my system. Of course it is a pretty big demanding game and GG projects aren't really in the same league.

but scripts are quite difficult to allow changes in right now so it would also greatly limit the script if you had to encrypt those, when you can feedback more from the entity properties or something then yes it would be good.
i.e. a day night cycle might be fine at 5mins per cycle for 1 game but maybe someone wants 30mins... if the script is encrypted they can't change that (assuming you needed the 'health' and 'name' for other stuff) unless you worked in an overwrite system in which it read the settings from a separate script maybe - doesnt suit the "easy" system and i'm pretty sure scripts need to be 1 file right now?

of course this isn't true for all scripts and i see no reason why scripts encrypted with LUA protector https://forum.game-guru.com/thread/213124#msg2527264 can't be accepted into the store if they don't allow modification anyway (as long as they warn customers first)

Obviously not encoded when the user uses it, just in a final game.

Edit - I've heard of LUA protector but not tried it. I didn't think it would work like that. Perhaps if you have a object with a specific script to it that works with no editing needed then you could use this, if of course TGC allow it.

Anyone else feel the script files should be encrypted in standalone mode? Originally the scripts were mostly default files and we did not need to protect default content but with the excellent scripts appearing now, and the hard work behind them I suspect this situation has changed.

Yes, I believe they should be encrypted, just to protect the artist scripts in the store.

A lot of artist store scripts are in use now.

If you wrote all your own scripts, created all your own models then feel free to have at it....this is not the case with most Indie or part time developers who purchase a large part of their content, which isn't licensed for anyone to hand out to purchasers of someone Else's product...period. Large studios if wanting to make their game moddable wouldn't use an asset purchased elsewhere, in fact I would love it if they did and see how much they get taken for by the Artist whose license forbade it and found their media 'ripped' and distributed using tools created by the game designer.

A standalone should encrypt ALL media used in this engine since it is unlikely much of the media used will be owned outright by users being Indie developers. If you want the choice and pull your own 'string' then use another 'development tool'....the same licenses apply there as well though to assets you purchase. Since even the assets released by TGC with the engine fall under this then it makes sense to ensure that users do encrypt and not be 'forgetful' or in this case even demanding they have the choice....it is a moot point.

I think standalone should have both encrypted (media and scripts). Just my thoughts.
So you can set inputs to your game thru menu, like player does with sound, level name, screen res, player name, etc.

as example:
If player want change time duration in nigh/day cicle, he has the option to set up in a menu, that user value is stored into a variable, for later use by the engine.

3com