Dedicate to public domain if this is going to be common code

[ghost]

Hey B,

Upon testing using stock Godot 2.1.2 it errored out saying Input.get_gravity is missing, so I'm working with the 2.1 branch now to try to see if I can get this working on Android. I'm gonna have to flex those Git muscles. ;)

Don't know if you've taken this into consideration yet, but you posted somewhere that sensor fusion in GDscript is going to be the reality, I'm assuming until Godot 3 is stable or whatever. While Godot's codebase is MIT-licensed, repositories containing individual games do not contain Godot's codebase and therefore can be licensed under whatever the developer wants. If someone were to use the sensor fusion code found here (which is fairly small), they would have one more license restriction. So what I would suggest would be to PD it.

However, if you want to be the one to eventually implement sensor fusion in C/C++ and hold onto this code, I understand. It depends on what you think would be best for as long as Godot 2 is relevant.

Muchas graciosos.

[BastiaanOlij]

Yup, the changes have been accepted into the 2.1 branch but that was after 2.1.2 was released, you'd have to compile from source. That said, since i do not have an Android phone with a gyro I haven't made the needed changes for android yet. I might end up doing so blind and have someone else test it..

[ghost]

I am doing those things as we speak.

Interesting. How does GDscript end up in Godot core? Maybe there is some Australian-American translation I'm missing, or maybe it's the moscato. With the PD thing I was referring to this codebase, not your work on the Godot codebase. Anyhow this is as good a place as any to drop The Speech.

Free software should be free because of idealistic goals, never for personal gain. What I gain is feeling holier-than-thou because my software is public domain while yours is not.

[BastiaanOlij]

Could very well be, i'm not a native english speaker:)

The positioning data is stored in the core making it accessible in GDscript for your game to use, the data is stored in a way that different vr platforms can feed data into it so you don't need to worry about playform differences while making your game. The result is that, limitations of the vr platform aside, you could create a game for say cardboard, and your godot project would also work if you deploy it for openvr, or oculus sdk, or whatever ends up being supported. Each platform should end up being a module by itself so you can pick and choose what VR platform(s) to include.

And how is my work not public domain? All the work for cardboard style vr is fully covered under the license of godot as it is contributed to Godot without limitations. All my code for OpenVr is just as public and free. If you want to use a vive effectively you are stuck on using the proprietary openvr SDK but thats not my fault, write an angry letter to valve if you'd like to see that change but there is no value in that. It's just the interface with their system that is proprietary, thats no different to Godot using proprietary APIs talking to the OS. It doesn't turn Godot, my work or your game into something thats not open source. :)

Cheers,

Bas

On Fri, 17 Mar 2017 at 12:53 am, fluffrabbit notifications@github.com wrote:

I am doing those things as we speak.

Interesting. How does GDscript end up in Godot core? Maybe there is some Australian-American translation I'm missing, or maybe it's the moscato. With the PD thing I was referring to this codebase, not your work on the Godot codebase. Anyhow this is as good a place as any to drop The Speech.

Free software should be free because of idealistic goals, never for personal gain. What I gain is feeling holier-than-thou because my software is public domain while yours is not.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/BastiaanOlij/TestCoreMotion/issues/1#issuecomment-287063105, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2vafCs7Jpoa40Id1MwXPRuY8jRhdrRks5rmT7FgaJpZM4Me5S4 .

-- Kindest regards,

Bastiaan Olij

[ghost]

Having a bit of trouble with the Android build. It uses Gradle, which downloads a file ~ 50 MB. It's not the largest dependency, but for what ever reason the download is the most prone to error. Unfortunately it looks like Gradle can only be built with Gradle and binaries can only be attained via HTTP, which doesn't quite work for people with dystopian network connections. I know the process for adding a sensor for Android as I did it before, but I can't get Android APKs to build so I can't even test to see what's working and what isn't because Godot's build setup sucks and the newest stuff isn't yet in a build, obviously not that the feature I was going to implement was implemented already. Circular dependencies really piss me off, and when you have a game engine as large as Godot problems like this arise quite frequently.

Either I do this when I'm more on my game or you do it when you can get somebody to test on Android, whichever comes first. I think it may be you because I just found out I'll be very busy for the foreseeable future. Nothing is working on my end right now. I am feeling the bloodlust.

On 03/16/2017 04:24 AM, Bastiaan Olij wrote:

Yup, the changes have been accepted into the 2.1 branch but that was after 2.1.2 was released, you'd have to compile from source. That said, since i do not have an Android phone with a gyro I haven't made the needed changes for android yet. I might end up doing so blind and have someone else test it..

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BastiaanOlij/TestCoreMotion/issues/1#issuecomment-287015483, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVAbqHZUPn3hcBm3MGuuQd7--w6K4z8ks5rmQ3MgaJpZM4Me5S4.

[BastiaanOlij]

Join the club, it took 3 hours for me to download just the SDK, now the NDK is downloading... If I can get it going I will attempt to do the changes and builds at this end but I have no Android experience or suitable device so can't promise it will work :)

[ghost]

Dude, you're gonna do this without a device? Join the club is right. I did that years ago when Android 2.3 was new and I HATED it, and I have hated it ever since. By "more on my game" I meant both more sober and less busy with class. I'm in a self-guided program and suddenly everything has hit me at once, good and bad, every single little thing I have to do, everyone I have to work with, all within the next 7 or 8 days. The only free time I have is in the early mornings and evenings for maybe an hour or two per day. I can't go to a coffee shop and play with Gradle or even complain about it to anybody, I just have too much shit to do suddenly, like now that the weather has warmed up the world has awoken from hibernation.

Needless to say, when you have successfully compiled the Android templates and put in the sensor code (easy if you have all the SDK-related tools set up and a DSL connection, which seems to be a bit more than the iOS requirements) make sure to upload an APK of TestCoreMotion somewhere so people can test it. If you're having trouble, just remember that this is Java stuff and Java is a pain in the ass.

Good luck!

On 03/17/2017 02:08 AM, Bastiaan Olij wrote:

Join the club, it took 3 hours for me to download just the SDK, now the NDK is downloading... If I can get it going I will attempt to do the changes and builds at this end but I have no Android experience or suitable device so can't promise it will work :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BastiaanOlij/TestCoreMotion/issues/1#issuecomment-287292086, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVAbqQR1eDMFgJWx0rNNKqnZsZJucAoks5rmj-BgaJpZM4Me5S4.