game-editor.com

Hi to you all,

I have one important question on the RPN registration module proposed here on the forum (first of all, congratulations to community for this work and especially to Makslane for his deep involvement in GE, which is one of the best dev. tool I used so far):

My problem is: I would like to implement in my game ("3D Star racer", available on Clickgamer for the 1st of May ) this RPN registration module and use the "GetOwner()" function to compare the name entered during the registration sequence with the real owner info. Unfortunately, to be used in a commercial purpose, such a registration method should work with special letters such as "é", "à", "ê", "ü" (etc), in order to allow French, Spanish, German (etc) people to register the game. The issue is that GE and the RPN module do not recognize these letters.

So, my questions are:

1. Is there any RPN formula unaffected by special letters, that is to say which considers "é" or "è" as simple "e"?

2. Alternatively, is there a method to make GE accepting special letters (for the moment, the GetOwner() function replace them by a blank... But GE does not considered them as real blank string (" ").

Have you any idea?

Best regards,
Regis

I tried my RPN String out on the handango web site, and as you say it
does make a difference with the returned registration code if you replace
the letter say ‘e’ with ‘è’.

I had not thought about this and would also be interested on any ideas to
the solution.

The only thing I can come up with at the moment is to warn the user that
special letters such as "é", "à", "ê", "ü" will have to be changed on the
owner device, but this could cause problems with the owners other registered programs.

In my game when registering, the screen displays the user name to let the
owner know what their owner name is on their device for registering. The
special characters are shown blank. What I done was to try and replace
these with spaces then tried to register the game with the special
characters replaced with a space, but had no success.

Has anyone experienced feedback from buyers that they are unable to register due to this problem?

All suggestions welcome.
Thanks

I would suggest a backdoor feature that would allow an override of the Owner Name.

To make sure that the Owner Name and its registration code isn't a leaked one on the 'net, I'd have a feature where the special characters in the Owner Name string be replaced with standard characters.

And, hopefully if this situation doesn't happen often, you'd be emailing the individual with the correct registration code based on the owner's name using standard characters.

The other option, easier for you, would be that the special characters be replaced with a simple character that you'd remember, and knowing in advance what the owner's name would be with the simple characters replacing the special characters, you could give them the registration code based on that name. All the while, the screen would still show the untouched Owner Name of the device.

For example, if the user's name was Raphaël Sálgado, your program would show that name on screen, but be looking for a registration code for RaphaXl SXlgado. You'll know the reg code before the guy even has time to shoot off a personal email to you requesting assistance, since you'd receive the PocketGear/Handango order via email and see his name in advance.

Make sense? You can even make the replacement a little more complex by rotating the replacement characters, such as Rapha1l S2lgado.

Oh, and congratulations on your game. I'm the one at Pocket PC Thoughts who posted this news of your "press release." Good luck!

Dear Beyondthetech,
First of all, many thanks for your encouragements: I do appreciate them these days, because I am not sure gamers will enjoy this project which relies on a very peculiar technic (pre-calculated 3D) and took me a lot of work and personal sacrifices.
Concerning the RPN issue, I have already though about such a similar solution (replacing special chars with standard ones), but this does not solve the case under which the customer is given a key THROUGH the commercial website: let's say HANDANGO or CLICKGAMER; for instance, if the customer has an owner name "André Musé" on his device, the commercial website will give him a unique corresponding code (let's say '12345'). Then, the GE RPN module will not be able to reproduce such matching, because, based on a string like "AndrX MusX", the GE RPN module will expect another code (let's say '56789', which differs from the one given by HANDANGO: '12345'). What I am looking for is a sufficiently safe way of registering so that I should no have to answer customers' e-mails concerning the registering issues. But, perhaps, I missed something...

Best regards

Regis

PS: felicitations too for your new job at PPCthought

Based on experience with PocketGear and Handango, you're not going to get any assistance from either portal regarding this issue. I am having a similar experience with Bubble Buster Advanced (over 10,500 downloads to date!), where a small portion of my customers are international.

I asked both companies if either one would be willing to implement a separate input text field to which their registration code would be based from. My intention was not to use the GetOwner, but the GetHardwareID function, since the Owner Name could easily be thwarted (i.e. Pocket Multi Owner Hack). Based off a device's unique serial number that Game Editor generates, the buyer would input that value and the registration code would be generated just for that device. PocketGear's answer was basically, "we'll see" and Handango's was pretty much, "Nope."

The only company I found that is able to do this is eSellerate. With only a 10-15% cut instead of 40-60% that PocketGear and Handango will demand from your sales prices, it's a very tempting offer, though the downside is that you'll have to design your own website or product page for it. eSellerate's people are extremely helpful, though, which is a nice bonus. A way around this is buy offering a very limited, free version download of your game on PocketGear and Handango, then entice customers to go to your site and the eSellerate portal to pick it up.

I don't know about ClickGamer, as they never returned my emails when I wanted to sell my game through them. They might offer a similar approach to a separate input field, or you might be able to ask them if its possible.

Otherwise, I don't think there's any other way of automating the process with customers whose device's Owner Name does not happen to conform to standard characters.

I wrote a game in C (& C++) and sold it on PalmGear which I think is essentially the same as PocketGear. They let me write my own RegCode generator in Java to process registrations and upload it to their server then run some basic tests to ensure the code it generated was the same as the code my game generated.
I'd never programmed Java before, but it wasn't too hard to do.

Code: Select all

// Hotsync UserID calculation

   public String codeFunction(String userID)
        throws FunctionException
        {
        String result = null;

  // attempt the code generation
  try {
        // initialise other vars
        int Counter, HotsyncLength, TempVar, HotsyncSum=0;
        int Multiplier=4;
        int Adder=46;
        String UnlockString;

        // Get the length of the HotsyncID
        HotsyncLength = userID.length();
        // Calculate Hotsync Sum
        for (Counter=0; Counter < HotsyncLength; Counter++) {
                if (HotsyncLength > 10 && Counter == 5) {
                        Counter=HotsyncLength-5;
                }
                if ( (byte)userID.charAt(Counter) > 127 ) {
                        TempVar=(byte)userID.charAt(Counter)-127;
                }
                else {
                        TempVar=(byte)userID.charAt(Counter);
                }
                HotsyncSum += TempVar;
        }
        // Now multiply by the Multiplier
        HotsyncSum *= Multiplier;
        // Now add the Adder
        HotsyncSum += Adder;
        // Make sure it fits
        if (HotsyncSum > 65535) {
                HotsyncSum-=65536;
        }
        if (HotsyncSum < 0) {
                HotsyncSum+=65536;
        }
        // Make sure it's the right length
        result=String.valueOf(HotsyncSum);
        while (result.length() < 5) {
                result="0"+result;
        }
   }
 // an error occurred.. terminate
 catch (Exception e) {
    throw
      new FunctionException(e.toString());
  }
  return result;
}


Hi,
What do you think about this solution:
All special letters (è, à, é...) have a corresponding ANSI code superior to 200. And, RPN formulas "i== 0 111+..." do use such ANSI codification. Moreover, these formulas accept special operators (in particular: "<" = "inferior to"). So we could imagine another RPN formula associating an arbitrary value (let's say 87 - which is the ANSI code for letter "W") each time a character has an ANSI codification superior to 200: in other words, each time a letter has an ANSI code superior to 200 (let's say 210, for instance), the RPN formula would take the MIN value between 210 and 87: here, it would be 87. So, the RPN based keys would be unaffected by special letters: for instance "José Musé" would lead to the same key than "JosW MusW".
I am convinced that such a solution could work and it would not implie any change in the HANDANGO habits.
But I don't know yet how to write the RPN formula that would allow this: I've got to learn more about RPN algorithms:

CAN ANYONE HELP?

Best regards

If you can create and test a substitution table for each of the special characters to standard characters, it could be fairly implemented on our end and not Handango's.

By the way, if you don't know the URL, Handango has a Registration Code Tester page here:

http://www.handango.com/RegCode.jsp?siteId=1

Dear all, and especially BeyondTheTech,
using the handango URL you put there, I entered the following RPN formula (see below)

i 0 == 111 * key + 125 c >= c * 192 c == 65 * 193 c == 65 * 194 c == 65 * 195 c == 65 * 196 c == 65 * 197 c == 65 * + + + + + + +

This formula considers letters "Â" "À" "Á" "Â" (etc) similar to simple "A": in other words, the generated key is not affected by special letters anymore (you may notice that the following formula I give here only works with A and does not translate, for instance, other special chrs such as "Ë" (or "é") into "E"(or "e"). But, it works!