Ah, okay, I was unaware of that, although I should've realized it would at least need those assets to even run -- thanks for the info.
Recent community posts
I'm in the habit with quake-style consoles in general to have the console immediately begin receiving keypresses on activation rather than waiting for the slide/fade-in effect to complete. I think that if the view is already becoming obscured it makes more sense to redirect input at the same time as you can't really see what your input is effecting anymore anyhow.
This is quite heavily due to my unfamiliarity with ruby, but the lack of helpful error messages is killing me. Using an incorrect operator or bogus if check should not result in errors like "stack level too deep" or the even worse nil thrashing error that tells me absolutely nothing about where it is coming from.
I am very much doubtful of the "(yet professional grade)" statement on the tool's page, as it feels a far throw from that. Professional grade does not leave you feeling SOL when a simple syntax error occurs.
Further verification shows that it is fine if I simply symlink to the dragonruby programs in their unarchived directory rather than copying them elsewhere.
This thread, it seems, should be ignored.
Running on Arch Linux and got the above error. Tried to simply link it to my system libudev with `ln -s /usr/lib/libudev.so /usr/lib/libudev.so.1.6.14` but that only resulted in `Couldn't create game context: Failed loading udev_device_get_action: dragonruby: undefined symbol: _udev_device_get_action`.
What version of libudev is the Linux binary linked against?