Towards a cross-platform version of Ini++

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Hey Clickers,

    I just released an Please login to see this link. of Ini++ v1.5 that fixes a memory leak. Working on the extension again made me think more about the requests for ports of Ini++ to various other platforms. I have previously mentioned that porting Ini++ to even one new platform would be too much work. Porting it to all the available platforms would be nearly impossible.

    However, this does not mean that there cannot be an flexible Ini-like object that is cross platform. It just means it would have to be more modest in its goals. Ini++ supports a lot of features, and this is reflected in the file size as well as the code complexity. When an object only has to be written once adding features like array or chart object interaction are cool. When it needs to be ported too it is best avoided.

    Therefore I hoped that people could tell me what they find the most useful features of Ini++ to be. What features couldn't they live without? What are their top five features? What features are not used? Has anybody ever used the fairly complicated 'Perform calculations' expression? How about the undo stack? Hashed values? Merging? The 'half baked' repeated group and subgroup features? The dialog box that you can open? Are there any features (apart from cross-platform support) that are missing but required?

    For more information, including a list of features, please look at Please login to see this link. blog post.

    Remember, this post is not a commitment to program this, I am just feeling out how much interest there is and what would be required.

    - Please login to see this link./Please login to see this link.

    As a fan of INI++, Encryption/Compression inside Cross-Platform support is my only 2 cents here.

    Game Launcher Creator V3 - Please login to see this link.
    Bespoke Software Development - Please login to see this link.
    Learn Clickteam Fusion 2.5 - Please login to see this link.

    Danny // Clickteam

    The thing about Ini++ that I used the most was the encryption feature that it has - it would be really good for iOS apps where it's important to protect data to stop people modifying it to gain free in-app credits (or something along those lines), which usually have to be paid for via an in-app purchase.

    I was going to say encryption / compression too. My most recent program stores a fair amount of data to the hard drive each day, so over time this data accumulates to be quite large. The compression option greatly reduces the footprint of the program.

    Please login to see this link.

    The ability to search the number of groups and derivatives there of this are my most wanted features, although I just the subgroup property if the ini++ and I find it extremely useful for various things.

    • Please login to see this link.

    Please login to see this picture.

    Encryption and Decryption, and the Dialog box, I've used- but dialog only as a debugging tool, never as anything necessary. All the other things you've listed, I hate to say I haven't used at all, I'm quite bare bones about it. Although I plan on using hash checksums for verification at some point. Something I could do external to INI++, of course

    Basically I'd say the features which deal with ini files and not really consider anything outside of that. Array loading etc.

    I agree that encryption would be very useful for the reasons which people already gave. The ability to load an ini directly from a URL would be useful potentially.

    Quote

    The ability to load an ini directly from a URL would be useful potentially.


    Networks functions are outside ini territory. This can be accomplished with the GET object together with loading Ini from string.

    Quote

    The thing about Ini++ that I used the most was the encryption feature that it has - it would be really good for iOS apps where it's important to protect data to stop people modifying it to gain free in-app credits (or something along those lines), which usually have to be paid for via an in-app purchase.


    Protection in the client is pointless and easily hackable. The server must store credits, not the client. Do not use encryption for this.

    Here's my full take on the INI++ object. It's mostly about stripping it down to the essentials. It's an ini object and should only deal with that. Having every feature in every extension is a bad approach - an ini object should deal with ini files, an encryption object should deal with encryption, a compression object should deal with compression. As long as ini data can easily be imported/exported as a string, other extensions can deal with their respective areas. If people absolutely need encryption, maybe make an extension on the side that can bridge between an ini string and encrypted file.

    General
    Built in features to save the file in specific directories - remove, getting default paths is outside ini territory
    Setting initial data - can be replaced with a string object with a default paragraph and "load as string)
    Case sensitive/insensitive options (including the ability to change it at runtime) - very useful, but maybe not the ability to change it at runtime
    The ordering of the file is preserved (but comments, etc. are not) - ordering is important, don't forget that ini is meant to be a readable file format
    Half-baked ‘subgroups’ - remove, not ini standard
    Perform calculation - remove
    ‘Current group’ set of features - remove, the ini++ object's global strings can be used to remember a "current group".

    Setting items
    Set String (MD5 hashed), remove, let a hashing extension deal with hashing
    Save object - remove, one trick pony, easily evented
    Load object - remove, one trick pony, easily evented
    Save position - remove, one trick pony, easily evented
    Save global values - remove, one trick pony, easily evented
    Load gloval values - remove, one trick pony, easily evented
    Move item to another group - remove, can be evented with two actions.

    Moving and copying
    Move item between groups - remove, can be evented with two actions.

    Merging
    Remove all features. Loading from a file and string supports keeping old data (which is merging). Merging with other Ini++ objects can be accomplished by loading from string. Merging groups can be accomplished by loading another object's CurrentGroupString$ (is there a GroupString$ for the non-current one by the way?)

    Loading and saving
    Settings - Set encryption - remove, outside INI territory, retrieving all INI data as a string is enough to let another extension designed for encryption deal with it.
    Settings - Set compression - remove, same reason as above.
    Settings - Set auto load/save - remove, don't support auto-loading/saving just because the Ini object does, using it is bad practice
    Settings - Export - Backup to - remove, one trick pony, easily evented
    Settings - Export - Import/Export CSV - remove, outside ini territory, conversion can be evented

    Advanced features
    Set repeated item - remove, easily evented
    Undo - remove, anyone who's making something advanced enough to need undo can event it without too much effort
    Dialog box - remove, outside ini territory, not customizable enough for use in actual software, not cross-platform friendly
    Chart object - remove, outside ini territory
    Array - remove, outside ini territory, conversion can be evented

    Edited 12 times, last by Nifflas (March 26, 2013 at 1:27 PM).

    Quote from Nifflas

    Networks functions are outside ini territory. This can be accomplished with the GET object together with loading Ini from string.

    Outside the territory but do-able. Any extension can be coded to acquire binary/file from a given URL. (Think Active Picture)

    Quote from Nifflas

    Protection in the client is pointless and easily hackable. The server must store credits, not the client. Do not use encryption for this.

    Serverside protection /SQL will always be the best route, however a basic encryption would suffice for those projects that don't need 'uber-profiled' encryption and compression is certainly a must especially for Android/iOS.

    Game Launcher Creator V3 - Please login to see this link.
    Bespoke Software Development - Please login to see this link.
    Learn Clickteam Fusion 2.5 - Please login to see this link.

    Danny // Clickteam

    Votes for encryption and compression come from Danny, Game_Master, Ryan, XStar, Simon, Pixelthief (I think?).

    ProdigyX: Can you clarify what you mean by 'The ability to search the number of groups and derivatives there of this are my most wanted features'. Sorry, just want to be clear.

    Nifflas' views are I think on the whole coming from a sensible position. He is correct that using an encrypted Ini file does not give you security (irrespective of the quality of the encryption). Other threads suggesting hashes are the way to go are similarly incorrect (and is in fact worse than encryption). It does increase the effort somebody would have to go to in order to unlock something that you'd prefer to be unlocked using a microtransaction. Nevertheless, it is not true that communicating with a server makes your product secure. As long as the user can choose what is executed on their device they can break any method you have. At the extreme end they can just attach a debugger to the process and skip any checks, or fake a remote server. Encryption relies upon keys being unknown, but if the device must use the keys then the device must know the key.

    I was previously worried that adding an encryption option would mean people have a false sense of security. On reflection I don't feel this, as any feeling of absolute security you have is an illusion.

    As for objects being big or small. This is a question of philosophy. Certainly in maintaining code it is best to have small things that have narrow, well defined areas. This does not necessary mean that extensions should also be like that also. It is certainly true that actions, conditions and expressions that can be coded in terms of others should be avoided. Nifflas makes a valid list of these. Nevertheless, he also could had added all searching actions and writing a number to an item. Sometimes it is unclear where to draw the line. I had previously written about how I hoped that it would be possible to write the convenience actions (etc.) within MMF itself. It does not appear as though this will be possible any time soon.

    Compression and encryption are less clear. There are strong and compelling reasons for them to be separate. Ini++ used a very weak 'encryption' algorithm (which had the advantage of being light weight) and a general purpose compression algorithm. This would not be suitable for all applications, but you had no choice (directly, at least). Separation allows that choice to be made. Nevertheless, there are two reasons to avoid this approach First of all they require the compression and encryption extensions to be ported too. In reality it will not happen. At least if you are using an extension whose raison d'être is to be cross-platform then you can count on it being so. As soon as you rely on anything else you are potentially in trouble as they would be the first causality.

    Secondly data would have to be passed around as a string. This mean the encrypted and compressed strings cannot have a null character in it. This makes them less efficient and it means the algorithms will have to be slightly non-standard. There is a reason Ini++ does not have a 'encrypt string' expression - If you unencrypted it again you might well have a load of it cut off! For instance, if 'Hello' went to 'R[null character]SFB' then it would decrypt back to 'H'. Compression would be worse as you wouldn't even get an initial segment back. Therefore I think separation of these abilities, whilst desirable, is not actually possible.

    - Please login to see this link./Please login to see this link.

    Quote

    Nevertheless, it is not true that communicating with a server makes your product secure. As long as the user can choose what is executed on their device they can break any method you have.


    Oh, definitely (I hope you didn't think I had any other opinion about that). However, with "credits" for example, if those are purchased with a card and stored directly on server, you wouldn't be able to add credits to your account from the client. Of course, it'd still be possible to just download the add-on content from a pirate site, or if the features are unlockable and part of the game from the beginning - just unlock them through some simple hacking.

    Quote

    There is a reason Ini++ does not have a 'encrypt string' expression - If you unencrypted it again you might well have a load of it cut off! For instance, if 'Hello' went to 'R[null character]SFB' then it would decrypt back to 'H'.


    Oh, in this case I meant a separate extension for "string to encrypted file" and "encrypted file to string", similar to how I pass strings between Ini++ and Binary Array, and use Binary Array's workspace feature and compression. It works beautifully. MMF2 does indeed not have a standardized way to store and send binary data between extensions, I was fully aware that you can not store the encrypted and compressed data as strings in MMF2. Hopefully, MMF3 will have a nice way to handle variables with binary data.

    Edited 5 times, last by Nifflas (March 29, 2013 at 10:01 AM).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login