God fucking damn it. I submitted my Playbook app 2 and half weeks ago and now I'm getting a mail that I signed it wrong. First of all I have no idea how I signed it wrong because it was an automated tool and I only had to point it to the signature files RIM sent me and secondly when I accidentally didn't sign my LWP for Android properly and tried to upload the APK signed with the standard SDK license it took Google about 1.5 seconds to tell me after I uploaded it. Why is RIM so slow?

God fucking damn it. I submitted my Playbook app 2 and half weeks ago and now I'm getting a mail that I signed it wrong. First of all I have no idea how I signed it wrong because it was an automated tool and I only had to point it to the signature files RIM sent me and secondly when I accidentally didn't sign my LWP for Android properly and tried to upload the APK signed with the standard SDK license it took Google about 1.5 seconds to tell me after I uploaded it. Why is RIM so slow?

Anyway, now I'm working on fixing the signature. :saddowns:

RIM enjoys hand-testing every app and is too stupid to write some automated signature checks

i signed my first BAR incorrectly (Marmalade didn't fully sign it), good thing i realized it was signed incorrectly because bb app world happily accepted it

Thanks, apparently I did everything right but their awesome Eclipse plugin creates two bars, a signed one and an unsigned one. Guess which one is in the project's root folder and therefore the first one I saw.

Edit:

Argh, now it won't accept my new bar because it doesn't have the same package id (the last one didn't have any). So it's actually automatically opening the bar and checking shit, but it's not checking if it's signed properly at all. Why are you doing this to me (us) RIM? WHY??

Coded a fairly rudimentary scaling difficulty system for that missile game, missiles appear more frequently and in larger numbers as the game goes on, along with different types of missiles appearing. Next up, currency and upgrades.http://dl.dropbox.com/u/52726455/Missile Mopup.swf
Notes: The Blue missiles are emps and will prevent ammo regeneration for 5 seconds if they hit your base. The health on the large orange missiles is shown sloppily and was only for debugging. If you save the file and open it with Flash player rather than the browser it will look nicer, as browsers automatically make it full screen stretching the image. Framerates may be an issue as I haven't fully optimized it. Oh and sometimes your health drops below zero without ending the game, working on a fix.

Just got back from writing a computing contest. I got 4/5 of the questions, the last one being the hardest. I think I have a solution to it now though, going to try to make it work at home. The jist of it is that you have between 1 and 4 spots, and the same amount of coins. There are the same amount of coins as there are spots, and each coin has a value between 1 and n, n being the number of spots. You have to find the least amount of time to arrange the coins in ascending order. You can only move a smaller coin on top of a bigger coin, and you can only move the coin on top of the pile. So if you have the original configuration of coins: 3 2 1, then you have to move them to 1 2 3, the least amount of turns being 20. I think I figured it out, though I didn't put this down for my program:

basically you move the only coins that can be moved, dividing the number of options into two (so for the configuration that I put up before(3 2 1), the first move can either be 32 blank 1 or 3 21 blank). You keep doing this and storing the configuration from two turns ago, and if you move something back to that position, you go back to that tree position and exhaust the other possible methods, labeling that one as a dead end. If you run out of possible methods, then the config is unsolvable and if you have multiple methods you compare the time it took to get to them and display whichever one is shorter.

I'm still trying and failing to get some sort of proper vertical control for my FPGA vga output, even though I'm having no problems with horizontal drawing at all, and the code is pretty much identical. I'm trying to add a green gradient from the top down over top of my red one, but all I'm getting is some very faint green lines at the points where the green changes intensity.

I don't know if there's anyone else reading this thread that uses systemverilog, but it probably can't hurt to post the code and see if any of you can point out some obvious error that I'm missing entirely. Help?

Forgive me if I've missed something obvious, but what happens if you want to store that one piece of data of the same type? From what I can tell, you're storing and returning data based purely on its type name.