Reply to Re: Dinklua lack of reference and buttons in 0.93
If you don't have an account, just leave the password field blank.
To RobJ: There isn't one as of yet, just a few paragraphs in the guide, as it's mostly redundant due to pretty much everything having the same name and purpose as in in DinkC, e.g. get_time_real() is dink.get_time_real(). The main differences are documented in the object reference (just updated), and as usual if there's something i've missed or that's confusing, don't hesitate to ask for an example of use.
Most lacking in real documentation are Phoenix's helper libraries (the things loaded with "include") although there are some notes in the comments. If one is starting out, I would not recommend trying to use them, as they're not required for use, and have a fairly steep learning curve if you're not accustomed to them.
To SimonK: None of the button* scripts will work with the controller for the time being, but will work with the keyboard (except for 7). I was going to bind them to the right stick directions, but removed the feature at the last minute for 0.93.
Instead, L1 binding works similarly to what you were suggesting in the other thread. i.e. the player can bind L1 to any keyboard script key from the gamepad settings window, which makes it equivalent to pressing that key. Unfortunately I don't plan on delving into Android/iOS any time soon.
I haven't actually tested anything greater than stereo audio as I got rid of my Logitech surround setup a few years ago due to it often picking up 2GB and 702 because of terrible shielding. In theory, it should mean that sprites that have a positional sound effect playing will have proper panning per number of speakers and player position, which is scripting-language independent. There are no proper surround audio mixing features unfortunately, and all manual SFX panning settings are just stereo for now. I may look at the possibility of expanding it in the future.
The amount of channels the audio backends were initialised with will be near the top of debug.txt if you start with debug mode on, and could be tested by placing a sprite in a lower corner of the screen with some looping audio attached and then listening to the rear speakers. Surround audio files in FLAC (such as these) should also work with playmidi() but are similarly untested.
Most lacking in real documentation are Phoenix's helper libraries (the things loaded with "include") although there are some notes in the comments. If one is starting out, I would not recommend trying to use them, as they're not required for use, and have a fairly steep learning curve if you're not accustomed to them.
To SimonK: None of the button* scripts will work with the controller for the time being, but will work with the keyboard (except for 7). I was going to bind them to the right stick directions, but removed the feature at the last minute for 0.93.
Instead, L1 binding works similarly to what you were suggesting in the other thread. i.e. the player can bind L1 to any keyboard script key from the gamepad settings window, which makes it equivalent to pressing that key. Unfortunately I don't plan on delving into Android/iOS any time soon.
I haven't actually tested anything greater than stereo audio as I got rid of my Logitech surround setup a few years ago due to it often picking up 2GB and 702 because of terrible shielding. In theory, it should mean that sprites that have a positional sound effect playing will have proper panning per number of speakers and player position, which is scripting-language independent. There are no proper surround audio mixing features unfortunately, and all manual SFX panning settings are just stereo for now. I may look at the possibility of expanding it in the future.
The amount of channels the audio backends were initialised with will be near the top of debug.txt if you start with debug mode on, and could be tested by placing a sprite in a lower corner of the screen with some looping audio attached and then listening to the rear speakers. Surround audio files in FLAC (such as these) should also work with playmidi() but are similarly untested.
