Hey guys this has been driving me crazy for a while now.

On line 225 of latest A5 from Git in evtsrc.c there is this line of code :

   ASSERT(ALLEGRO_EVENT_TYPE_IS_USER(event->any.type));

What it boils down to is that it prevents users from simulating allegro events. In reality this is unnecessary.

In my ManyMouse project I made an adapter from the win32 RawInput API which takes Windows VK_ vkeys and maps them to ALLEGRO_KEY_* allegro keys so I could use RawInput directly without having to have an allegro window active and onscreen because I can use the RawInput API's input without having to have an active or onscreen window.

But this ASSERT prevents me from simulating actual ALLEGRO_EVENT_KEY_DOWN and ALLEGRO_EVENT_KEY_UP events, which is a giant pain.

Can we remove this? I don't think it really serves any useful purpose other than to limit the user's ability to emit allegro events with al_emit_user_event.

Thanks for taking a look. I can submit a patch, but it's a one line change so I figured it didn't really need a patch. Let me know what you guys think.

Thanks,
Edgar

PS. Also, it is preventing me from using a debug build of allegro, which I need to debug my program. :/

Allegro's source is now hosted on github: https://github.com/liballeg/allegro5

Coincidentally, the change you want has been made about a month ago .

Oh okay. So my Git isn't up to date. How do I change the master repository in use? Or should I just clone A5 again?

git remote set-url origin git@github.com:liballeg/allegro5.git

Or even easier, edit .git/config and replace the old URL with this one.

I changed the .git/config file to use "https://github.com/liballeg/allegro5.git" and it is up to date now. Thanks for the advice.

Although this raises the question of having an out of date repository hosted on sf.net. I think that could easily confuse some people. Is there any way to make the SF repo a mirror of GitHub?

Removing the assert is the simple fix "for now". A more comprehensive fix, (e.g. al_emit_keyboard_event()) will probably be added in the future.

Yeah, but then you have to write a al_emit_X_event function for every event type there is. It would be better to just have a single function that is capable of emitting any kind of event. IMHO.