Minecrift Discussion Thread

[Jademalo]

Out of curiosity, what are your PC specs?

Desktop is pretty mild: Phenom II 9550, overclocked to 3GHz, Radeon HD 7850. Thats running pretty decently.
Laptop is an i7 3740QM @2.7GHz and GeForce 650M, though it is running OSX... so any Windows tests are through Parallels.

Oh sweet, that's pretty nice, mine wont have issues for sure =]

Any ideas on how to dump the log? I'm running out of options

[mabrowning]

Any ideas on how to dump the log? I'm running out of options

I just made some sweeping changes to the build system and tested it on all my dev machines(Windows, Linux, or OSX). Should be working now without spewing errors messages.

Which platform are you building on? If you still have error messages, I'll try to help you log them out.

[mattyeatsmatts]

Any ideas on how to dump the log? I'm running out of options

um could try some laxatives?

[Jademalo]

Any ideas on how to dump the log? I'm running out of options

um could try some laxatives?

Har har har =p

Any ideas on how to dump the log? I'm running out of options

I just made some sweeping changes to the build system and tested it on all my dev machines(Windows, Linux, or OSX). Should be working now without spewing errors messages.

Which platform are you building on? If you still have error messages, I'll try to help you log them out.

Debian x64. I managed to dump my old errors, I'll try with a fresh pull.

http://pastebin.com/x0Acgyxm
http://pastebin.com/tCfw7Ztz

[mabrowning]

Ok, looks like its applying all the patches correctly. But then, when recompiling, javac can't find the JRift classes. Do you have mcp/lib/JRift.jar and mcp/lib/SixenseJava.jar in place?

Oh! I just corrected the install.py to run "git submodule init" before "git submodule update", so they probably don't exist in your working dir. It should work after a fresh pull + install.sh, but if not, try those two commands manually, then add the symlinks if they don't get added (it would be in install.py).

[Jademalo]

Just worked with the fresh pull!
Hooray =]

I'll try and do a little bit of work on the options menu, but don't expect much. I'm pretty much winging it lol, my java knowledge is extremely basic. I suppose it's the best way to learn though.

EDIT: That will need updating on the 1.4.7 branch, same issues building that. Got it working manually though.
EDIT2: Not quite, get this build error. Can't make the classes for some reason

Code: Select all

Creating /home/scotty/Source/Minecraft/minecrift-1.4.7/releases/minecrift_1.0_beta_1.4.7_classes.zip
Traceback (most recent call last):
  File "build.py", line 108, in <module>
    main(os.path.abspath('mcp147'))
  File "build.py", line 83, in main
    with zipfile.ZipFile( out_file,'w') as zipout:
  File "/usr/lib/python2.7/zipfile.py", line 701, in __init__
    self.fp = open(file, modeDict[mode])
IOError: [Errno 2] No such file or directory: '/home/scotty/Source/Minecraft/minecrift-1.4.7/releases/minecrift_1.0_beta_1.4.7_classes.zip'

[StellaArtois]

Right, I had a good couple of hours trying to work out the best way of doing it, but I can't quite figure it out.

I'll show you the rough concept of the main page to show you the general direction of what I was thinking



My biggest issue is trying to work out how to separate the second bank of options.
I definitely think having the orientation/position/controller options on the main page like that would be a good change. I would also move the 3 HUD settings from the menu into Gameplay settings, and eye height/eye protrusion/neck length into optics/rendering.

However, it gets complicated with the hydra being usable as three devices. One of my thoughts was to have three further sub menus for orientation, position and controller configurationd, and dynamically change their location and contents depending on which device is loaded to perform which function. This could also include a 5th box on the main screen called "Gamepad" for when box [4] was set to Gamepad.

The advantages of having it set up like that would allow different configurations of things like head track prediction depending on whether or not you were using the rift for orientation or the Hydra.

The other concept I had was to keep menus related to function, but change the contents depending on the device chosen. The issue with this is that certain options affect both and are spesific to the device, such as Hydra recalibrate. (That obviously affects Orientation, but is under Positional)


This would be so much easier if I knew what I was doing in the actual code =[


Also I meant to ask - Does the Hydra offset affect the orientation tracker with regards to roll?
If it does, it's not available to configure unless you enable positional.

Jade, I've been starting to think about this a little more over the weekend. I don't believe we need a separate bank of buttons just to select the current head track, head orientation, controller devices. That is handled in each sub-menu. However a summary of the selected plugin used for each on the button may be the way to go. This is the current direction I'm thinking of heading in (obviously subject to change / feedback / input!):

MainGUI_mockup1.png

[Jademalo]

Jade, I've been starting to think about this a little more over the weekend. I don't believe we need a separate bank of buttons just to select the current head track, head orientation, controller devices. That is handled in each sub-menu. However a summary of the selected plugin used for each on the button may be the way to go. This is the current direction I'm thinking of heading in (obviously subject to change / feedback / input!):

MainGUI_mockup1.png

First, tell me what program that is, it looks convenient
(I wish there was a program that let me quickly mock up GUIs with menus and buttons lol, I'd have something perfect in a couple of hours)

I've been having a good think about this too after noticing the GUI getting more cluttered and confusing with each day.
One of the biggest issues I've run into is options that affect certain things not appearing unless something else is activated and/or being hidden in a submenu that is semi unrelated. An example of this is Hydra offset, it affects orientation tracking but is inaccessible unless positional is enabled.
That's the main reason why I think options should be banked together by device as much as possible rather than function.

The issue really is that there is no one perfect solution because of this. One possible idea is to work out which options are shared and separate them off, but yeah.

[StellaArtois]

First, tell me what program that is, it looks convenient
(I wish there was a program that let me quickly mock up GUIs with menus and buttons lol, I'd have something perfect in a couple of hours)

Balsamiq mockups

One of the biggest issues I've run into is options that affect certain things not appearing unless something else is activated and/or being hidden in a submenu that is semi unrelated. An example of this is Hydra offset, it affects orientation tracking but is inaccessible unless positional is enabled.
That's the main reason why I think options should be banked together by device as much as possible rather than function.

Agreed that some options are only shown on sub-menus, and not others. IMHO I believe the answer is to ensure these are duplicated where it makes sense to do so.

[Jademalo]

Balsamiq mockups

Thanks, using this now. Did what I did in an hour in about 30 seconds lol, I should have looked sooner...

Agreed that some options are only shown on sub-menus, and not others. IMHO I believe the answer is to ensure these are duplicated where it makes sense to do so.

I think I may have a solution to this...
In contrast to you, I think it would be better to duplicate as little as possible. I have an idea with regards to the Hydra spesific options, I'll throw it together and see what it's like. This would work using function submenus rather than device, which I did prefer but didn't think worked as well until I had this idea.

I still like having the device choices on the main VR page, but that's just me. (It also works better with this Hydra idea)

[StellaArtois]

ps just notice you closed the Support positional tracking with a Hydra mounted on the back of your head enhancement on github

Should be in (EDIT: next build). However the trick is in getting the offset measurements right. I've got some default offsets in that should be generally right, but you'll need to experiment and adjust for your own head. For now a Hydra on the left or right side of the HMD gives the best pos track simply because it's easier to get the offset measurements correct.

[StellaArtois]

Balsamiq mockups

Thanks, using this now. Did what I did in an hour in about 30 seconds lol, I should have looked sooner...

Agreed that some options are only shown on sub-menus, and not others. IMHO I believe the answer is to ensure these are duplicated where it makes sense to do so.

I think I may have a solution to this...
In contrast to you, I think it would be better to duplicate as little as possible. I have an idea with regards to the Hydra spesific options, I'll throw it together and see what it's like. This would work using function submenus rather than device, which I did prefer but didn't think worked as well until I had this idea.

I still like having the device choices on the main VR page, but that's just me. (It also works better with this Hydra idea)

Mockup all the menus; I'll do the same, then lets compare / contrast, and pick the best bits from each scheme.

[Jademalo]

Mockup all the menus; I'll do the same, then lets compare / contrast, and pick the best bits from each scheme.

Good plan. Gah this program is quick =p

[StellaArtois]

I turned my 9 year old loose into minecrift to see how well he'd handle VR sickness.
2 hours later of jumping off cliffs, mining straight down, flying around, no sickness whatsoever.

I'm very impressed with what you guys have achieved on this mod. The integration is spectacular and given the low resolution of the rift right now, minecrift is going to be the killer app that will keep our DK in use even after the consumer model is released.

As I've said before, comments like this keep us going. Glad you're enjoying it!

[StellaArtois]

Mockup all the menus; I'll do the same, then lets compare / contrast, and pick the best bits from each scheme.

Good plan. Gah this program is quick =p

It's certainly easier than doing it by hand I'll agree!

[Jademalo]

Mockup all the menus; I'll do the same, then lets compare / contrast, and pick the best bits from each scheme.

Good plan. Gah this program is quick =p

It's certainly easier than doing it by hand I'll agree!

Nearly done, pretty damn happy with what I've come up with. Surprisingly, very few things need to be dynamic.

[Jademalo]

And done!

I'm really happy with how mine turned out actually.
Looking at it without knowing how the plugin system you have works is probably helpful too, as groupings are all logical from a users perspective.

Tell me when you're done and I'll add you on skype or something and talk you through it.

[StellaArtois]

And done!

I'm really happy with how mine turned out actually.
Looking at it without knowing how the plugin system you have works is probably helpful too, as groupings are all logical from a users perspective.

Tell me when you're done and I'll add you on skype or something and talk you through it.

Jade, cool! Post them up. I'm at work then have family stuff so won't be able to knock mine up for at least another six hours!

[mabrowning]

EDIT2: Not quite, get this build error. Can't make the classes for some reason

Derp. I need to create the "releases" directory. I'll push up some changes to the 1.4.7/ install.py script

[baggyg]

Sorry if I have missed the announce. Does the mod work with the latest version of Minecraft (1.6) or should I keep it on the old one for now (1.5.2)?

[StellaArtois]

Sorry if I have missed the announce. Does the mod work with the latest version of Minecraft (1.6) or should I keep it on the old one for now (1.5.2)?

No, not at the moment - keep it on 1.5.2 for now. We're dependent on Forge and Optifine being updated with 1.6 support.

[Jademalo]

Jade, cool! Post them up. I'm at work then have family stuff so won't be able to knock mine up for at least another six hours!

Alright, I keep forgetting people do things during the day lol.


As a preface, every "Reset to Defaults" should reset that entire page and all subpages. This means each sub menu gets reset correctly, and the one on the Master page resets everything.



With a squeeze, this should fit.
Anyway, as before, the main concept is to arrange everything based on the device it's related to. However, I looked at abstracting as much as possible from this. Anything that wasn't spesific I took out and placed in a big pile on a page. I then attempted to rearrange everything based on logical categories.



First, tracking.
I originally had this split into Positional and Orientation, but I realised just how few options were actually common between different trackers. The top three are for Orientation, and the bottom one is for Positional.



Avatar - This needs a better name.
Essentially, these are all the configurations that affect your player character in the world. The top bank of options are all of the current variables that can be changed to configure the game to your physical body. I personally think these should be kept visible regardless of the modules loaded, as these are all values that are configured based on your head. Render headwear can go either here or Optics/rendering, it doesn't really matter. I figure here is nicest since it affects your character.
The HUD options fit in here nicely, since they are technically part of how your character is configured in my head, but they too could go in Optics/rendering if it was prefferred.



Optics / Rendering.
These are all of the options that change the visual properties of the world being rendered. They're pretty much the same as present.



Controller.
This is the only page that has an actual functionality chance rather than just a changearound. The two current Vertical camera options can very easily be combined into one, and in turn that will make a LOT more sense. I've explained the three options in the image, since they're all mutually exclusive it makes sense to combine.
With rebind buttons and Joystick sensitivity, these should only be shown if a Hydra or a Gamepad is selected for the controls. I wouldn't remove Vertical Camera or Keyhole width when theyre enabled, as this allows for more configurations. (My preference would be to have an option like default TF2, with an acceleration based Keyhole and strafing on the stick.) Any new controller options or profiles like TF2 fit nicely into here, and theres no need to put anything related to them anywhere else. The rebind buttons page I have not yet done, mainly because it doesn't matter how that is laid out.



Rift Calibration.
I made this separate since I imagine there will be more functionality added to the rift's API that would make sense to be put into here. One extra change and request is a centre button like the current one for the Hydra, as well as the left/right/up calibration. As with Hydra calibration, these two options should be hidden if the Rift is not being used as the Orientation tracker.



Hydra Calibration.
This page is pretty much a perfect copy of the current Positional Tracking page. The top bank of options imo should remain enabled at all times, since that is a hard "Where is the Hydra" set of options. At present, it seems that these affect the functionality of all three different options, be it which controller to use for what, rotation offsets, or positional offsets. Due to this, I figure it's worth always having them available.
The bottom two are the current two options in Positional Tracking. Centre the view for orientation, and reset origin for position. I figure these could be enabled/disabled dynamically, but it doesn't really matter.



And there you have it. 7 pages, as much abstraction as possible, and what I believe to be a sensible and intuitive set of options.
The only thing I don't like is the name of Avatar, there could be a more descriptive name for it (Body options? Physical Configuration? I don't know)
I tried to have Hydra and Rift calibration as a single page, but I wasn't completely happy, and figured it would be better to future proof incase extra things get added to the rift's API, and if any options arise when the consumer version gets it's positional tracker.
One other option that could go in the Rift calibration option is a Resolution thing maybe.


So yeah. Took me about half an hour or so, and I'm pretty pleased with it. I can't imagine it being too hard from a development perspective, but as a user it seems to make sense.

Hope you two like it =]

[mabrowning]

I'm mulling over your suggestions, but I definitely want to implement keyhole on the hydra. After actually playing the game for awhile yesterday, I never needed to mine blocks I wasn't looking horizontally at: that motion would have been better for turning. And turning with the joystick was awkward after years of conditioning using the joystick to strafe (although usually left hand), so I'll definitely make the default do that.

[Jademalo]

I'm mulling over your suggestions, but I definitely want to implement keyhole on the hydra. After actually playing the game for awhile yesterday, I never needed to mine blocks I wasn't looking horizontally at: that motion would have been better for turning. And turning with the joystick was awkward after years of conditioning using the joystick to strafe (although usually left hand), so I'll definitely make the default do that.

Sweet, I was going to suggest it to you at some point but it came out naturally when I was explaining that =p

[mabrowning]

Alright, hydra keyhole aiming and other goodies is in 1.5.2 build#37 and 1.4.7 build#6

• - Keyhole width depends on head pitch (so you aren't constrained to hemisphere of allowable aiming) - not fully working on mouse.
  - Hydra controls are now:
  • - Pointing "aiming" controller left and right beyond the keyhole will rotate the character. "joystick" sensitivity actually affects this only.
    - Joystick used for strafing
  - Hydra "aiming" can be used as mouse in menus. Joystick no longer used for this.
  - Allowing keyhole to move with head (more options!)

Controlling with hydra doesn't feel completely right to me.. I'd be very interested in some feedback on this regard. Perhaps all it'll take is using it for a few more minutes to get adjusted. Or actually using it in VR(August is so far away...). The hydra was never really good on a 2D screen ^_^

[StellaArtois]

Ok, had a little more time to mull your ideas over Jade.

As a preface, every "Reset to Defaults" should reset that entire page and all subpages. This means each sub menu gets reset correctly, and the one on the Master page resets everything.

Agreed.

With a squeeze, this should fit.
Anyway, as before, the main concept is to arrange everything based on the device it's related to. However, I looked at abstracting as much as possible from this. Anything that wasn't spesific I took out and placed in a big pile on a page. I then attempted to rearrange everything based on logical categories.

I'm still not quite buying into the separate buttons required to show / select the controller types. That's a lot of wasted space right there, and the GUI is only so big. This is pretty much the same idea as using the current orientation, position and controller buttons, except that clicking them won't simply cycle through the types. Instead the sub menu will appear, and then you can change the method type.

I can see your point about having a single button for Tracking, as it is relatively confusing to talk about separate 'Head Orientation' and 'Head Position'. However in my view 'Tracking' is still not all that obvious to a lay-person. I'm tempted to stick with separate buttons for Head Orientation and Head Position currently, with a summary of the type on the button itself as discussed above. I do like the layout of the 3 types buttons however; we'll go with that if space permits.

The more I mull it over, the more I'm leaning towards your idea of separate calibration options for the Rift and Hydra as well. Still need to think that through a little more and work out what additional Rift / Hydra calibrations we want to include in the future.

First, tracking.
I originally had this split into Positional and Orientation, but I realised just how few options were actually common between different trackers. The top three are for Orientation, and the bottom one is for Positional.

Not sure how you would determine between positional and orientation here. Also, Head track prediction / head track prediction time is only relevant for the Rift at the moment; I need to move those out.

You have a lot of the current positional track stuff moved to being under calibration; however I'd argue that that is not calibration as such, purely configuration; and hence should stay in the current dialog.

Avatar - This needs a better name.
Essentially, these are all the configurations that affect your player character in the world. The top bank of options are all of the current variables that can be changed to configure the game to your physical body. I personally think these should be kept visible regardless of the modules loaded, as these are all values that are configured based on your head. Render headwear can go either here or Optics/rendering, it doesn't really matter. I figure here is nicest since it affects your character.
The HUD options fit in here nicely, since they are technically part of how your character is configured in my head, but they too could go in Optics/rendering if it was prefferred.

Happy with all of these settings being in here as you suggest (DOUBLE EDIT: Ah, see you've moved IPD to here. Now I think I like this!) These options may end up being split between Avatar (or Player) Settings and HUD / Overlay settings, as I'd like to introduce a few more HUD options (enable disable crosshair when HUD overlay is off etc.)

Optics / Rendering.
These are all of the options that change the visual properties of the world being rendered. They're pretty much the same as present.

Agree 100% with this.

Controller.
This is the only page that has an actual functionality chance rather than just a changearound. The two current Vertical camera options can very easily be combined into one, and in turn that will make a LOT more sense. I've explained the three options in the image, since they're all mutually exclusive it makes sense to combine.
With rebind buttons and Joystick sensitivity, these should only be shown if a Hydra or a Gamepad is selected for the controls. I wouldn't remove Vertical Camera or Keyhole width when theyre enabled, as this allows for more configurations. (My preference would be to have an option like default TF2, with an acceleration based Keyhole and strafing on the stick.) Any new controller options or profiles like TF2 fit nicely into here, and theres no need to put anything related to them anywhere else. The rebind buttons page I have not yet done, mainly because it doesn't matter how that is laid out.

I'll let mabrowning comment on this screen, it's his baby and he's the controller guru!

Rift Calibration.
I made this separate since I imagine there will be more functionality added to the rift's API that would make sense to be put into here. One extra change and request is a centre button like the current one for the Hydra, as well as the left/right/up calibration. As with Hydra calibration, these two options should be hidden if the Rift is not being used as the Orientation tracker.

I think there needs to be a quick and easy 'Recalibrate All' option on the main VR menu. But I am siding with you on the potential need for separate calibration options screens for the Rift and Hydra calibration. Again, still not sure to be honest.

Hydra Calibration.
This page is pretty much a perfect copy of the current Positional Tracking page. The top bank of options imo should remain enabled at all times, since that is a hard "Where is the Hydra" set of options. At present, it seems that these affect the functionality of all three different options, be it which controller to use for what, rotation offsets, or positional offsets. Due to this, I figure it's worth always having them available.
The bottom two are the current two options in Positional Tracking. Centre the view for orientation, and reset origin for position. I figure these could be enabled/disabled dynamically, but it doesn't really matter.

The pos track settings should only be affecting pos track. So most of these options belong in the pos track area. That said, I get your point about the 'Where is the hydra' set of options - of that, the 'which controller (left or right) is used for what' setting is probably the only one that should affect the others. Hmmm. Maybe that needs to be represented on the button summary on the main VR options screen...

Hope you two like it =]

Well, I don't agree with everything you've come up with, but most of it makes good sense to me. I think there are definitely some ideas we should rip immediately. It's certainly helped me think about a few things I've missed before. Much appreciated Jade, thank you. Keep it coming!

To be honest, I think the thing I've personally been missing with the crazy dev over the last few months is that I just haven't actually SAT DOWN with Minecraft/Minecrift and just played it. I need to do that to get some perspective on how all this should fit together really.

[Jademalo]

Well, I don't agree with everything you've come up with, but most of it makes good sense to me. I think there are definitely some ideas we should rip immediately. It's certainly helped me think about a few things I've missed before. Much appreciated Jade, thank you. Keep it coming!

To be honest, I think the thing I've personally been missing with the crazy dev over the last few months is that I just haven't actually SAT DOWN with Minecraft/Minecrift and just played it. I need to do that to get some perspective on how all this should fit together really.

I think maybe changing the word from Calibration to Configuration might clear things up a bit with Hydra and Rift options. Also, with regards to the options I currently have in tracking that only affect the rift, it's getting to the point where there are literally two(?) options between positional and orientation that aren't device spesific, and they're both essentially just sensitivity.
That's the main reason I combined the pages, even though I do agree is it a bit ambiguous. If it was possible to have a white text subheading to split the page it would be ideal imo.
Even though you said I moved a lot of the current positional tracking out of the tracking page, every single bit of it was Hydra spesific - Which controller, which side, offset and filtering.

One other potential idea if real estate is an issue is to plonk the bank of 3 devices, rift config and Hydra config into their own submenu called "Devices" or something similar. This would also mean id you added things like FreeTrack it would have a good place to put the new button for options spesific to that.

Also, does Hydra position not affect roll? I assumed you would have to compensate for its position. My mistake, but I still like splitting device spesific things like that into device menus.

Thanks for actually looking through it though, hopefully it's helpful to you in some way =]

EDIT: Also I'm pleased you like Avatar settings, that was my favorite page lol. It all made sense to me to be together.
EDIT2: Actually, I'm gonna change a few things around and post a zip of the changes on here. It saves space, and is probably more scalable in the future...

Ok, here is my second attempt =p
https://dl.dropboxusercontent.com/u/523 ... %20GUI.zip

[mabrowning]

I'll let mabrowning comment on this screen, it's his baby and he's the controller guru!

Controller options look good. Good call on the tri-state vertical camera button, I don't think I would have thought of that. I've already made a few of the suggested changes, but mostly because now its an obvious configuration choice for the new features. This one is hard to get wrong.

That said... I have been debating on where "Rebind Buttons" should go. I'd almost think I should extend the current "Controls" button on the main menu to allow rebinding of joystick and hydra options, that way they can be configured even if you don't have VR Rendering / Oculus Rift enabled. Currently, if someone only has a hydra(soon controller), we force them to play in at least stereoscopic 3D. I'd like for this to be usable even if you don't have the Rift (personal bias here, I suppose).

[Jademalo]

I'll let mabrowning comment on this screen, it's his baby and he's the controller guru!

Controller options look good. Good call on the tri-state vertical camera button, I don't think I would have thought of that. I've already made a few of the suggested changes, but mostly because now its an obvious configuration choice for the new features. This one is hard to get wrong.

That said... I have been debating on where "Rebind Buttons" should go. I'd almost think I should extend the current "Controls" button on the main menu to allow rebinding of joystick and hydra options, that way they can be configured even if you don't have VR Rendering / Oculus Rift enabled. Currently, if someone only has a hydra(soon controller), we force them to play in at least stereoscopic 3D. I'd like for this to be usable even if you don't have the Rift (personal bias here, I suppose).

I agree with you, the rebind button was one that I wasn't happy with its place.
Does it go there, does it go in Hydra options, does it extend the normal controller options, there were loads of places to put it.
One idea I had was an option to disable stereo rendering (or maybe have more stereo rendering modes with a toggle in devices?) and keep Controller/Hydra inside the VR options.

Glad the tri-state button is good!
I was dead chuffed with myself when I noticed it could work like that lol. As I said, it was the only actual functionality change I made.

Glad you like them =]

[mabrowning]

Heyo!

http://www.youtube.com/watch?v=jQ3vQ85tR0Q

[BoomZilla]

Is there a way to load tekkit into Magic Launcher or get the rift working with Technic Launcher tekkit

[Jademalo]

Heyo!

http://www.youtube.com/watch?v=jQ3vQ85tR0Q

I may have one of those on order

[mabrowning]

Is there a way to load tekkit into Magic Launcher or get the rift working with Technic Launcher tekkit

Probably. I've never done it, but theoretically the same instructions for FTB should apply: apply Forge, then Optifine, then MInecrift. Add the mods from the tekkit directory and away you go.

There might be a way to use the minecrift_classes.zip directly with the tekkit launcher. If thy have some kind of "jar mod" or "core mod" selection, try adding it to that. JRift.jar and Sixense.jar can just be in the mods/ directory.

Let us know if it works, possible with more precise instructions so others can follow in your footsteps!

[thenomad]

Hey, guys! Awesome mod.

One quick question - any tips on getting past the Oculus "left, right, up" calibration? I'm on the latest build (works best for me of all of them), using an Oculus devkit, and I just can't get the system to accept my left, right, up movements.

It's very frustrating because I'm so damn close to being able to play...

Any tips much appreciated!

[Jademalo]

Hey, guys! Awesome mod.

One quick question - any tips on getting past the Oculus "left, right, up" calibration? I'm on the latest build (works best for me of all of them), using an Oculus devkit, and I just can't get the system to accept my left, right, up movements.

It's very frustrating because I'm so damn close to being able to play...

Any tips much appreciated!

I can't speak from experience, but apparently you need to go directly up - don't turn your head back to face forward and then go up.

[ElectroPulse]

Hello,

My Rift is arriving tomorrow , so tonight I have been lining up the things to try out...

When trying to get this working, I ran into the following issue:
When I start it, the "Mojang" splash screen appears for a half second, then the screen goes black.

First off: Does this mod require the Rift to be plugged into the computer in order to launch it? If so, then this would be the issue.

If not, any idea what might be the problem?

Here's what I've done:
Installed MSVC++ 2010 (ran the 64-bit installer)
To simplify things, I renamed my .minecraft folder, and started anew.
I downloaded the most recent MagicLauncher (I really like that launcher... I love the modularity)
Under Setup, I set the version to 1.5.2, and added the 4 mods that are required, and in the correct order (one thing to note: I didn't see OptiFine 1.5.2 D3, so went with D5. Can anyone confirm that it works with D5?)
Changed install location under the "Advanced" tab (I am planning on using Dropbox to sync Minecraft between my computers using this method). I don't believe that this should change anything, but if it does, let me know
Changed memory allocation to 1024MB

Specs:
Windows 7 Ultimate 64-bit
Intel i7-2630QM
GT555m GPU (was running 310.70 drivers, just about to update it to 320.49. EDIT: Nope, didn't fix it)
8gb ddr3 RAM
Native resolution: 1920x1080
Have both Java 32-bit and 64-bit installed
(If there is any other relevant info you need, let me know)


Anyway, my guess is that I just need the Rift plugged in... But figured I'd ask in case there was anything else I could do to get potential bugs ironed out before I actually have my Rift on-head
Thanks!

[mabrowning]

Nope, doesn't require Rift.

What does the magic launcher "Test" screen show as a log? Could you pastebin it?

[ElectroPulse]

Nope, doesn't require Rift.

What does the magic launcher "Test" screen show as a log? Could you pastebin it?

Aha! Got it sorted...

I hadn't noticed the "View Log" button. I opened that, and it threw a "java.io.FileNotFoundException" stating that C:\Users\[username]\AppData\Roaming\.minecraft\bin\natives\JRiftLibrary64.dll couldn't be found.

I browsed to .minecraft, and was surprised to find that there was no folder entitled "bin." It appears as though they've done away with the bin folder in the new launcher (I mentioned I had renamed my .minecraft folder and started anew... That's where I went wrong, for this at least)... I re-ran the old launcher I had, which generated the bin folder, and now it works

[mabrowning]

Great! I've got plans to set up an installer.jar like forge/FML does for the new launcher (actually *exactly* like forge, as they are open source! ). Hopefully that will resolve these installation complications.

[mrklaw]

Not been on for a while,but progress looks amazing.

Are there any plans to use the hydra motion for strafing? Buttons/stick for strafing isn't good for me in the rift, so assigning it to a physical motion might help trick my brain into thinking that motion is normal