UDK feature request list for all.

"BlackFang" wrote:
I think the main complaint was 3rd party plugins, which has been solved. I didn't see the command for disabling tracking, which is a good feature. If thats true, then you can just disable the tracking, then implement your own version on top of, if you want to do something different. There are two problems with the use of native code, not being able to change it, which isn't a problem if it can be disabled, but also that native code is harder to dissect through and understand how it is working, which makes it harder to use. The newest OUDK should work for +95% of people. I could probably make it work for me too now, but I've already gotten quite a ways with the standard UDK, so I feel like I might as well continue. The only thing I could request now would be to move the sensor data reading and camera-rift coordinating even more towards UnrealScript.

I see, fair enough. However, OUDK is not only sensor-reading stuff. We fixed a ton of issues with stereo rendering, we spent a lot of time figuring out correct distortion and chromatic aberration, fixed Scaleform rendering in stereo, Bink video rendering in stereo, etc. I am really surprised you are getting bearable stereo image in standard UDK (however, probably, your maps are pretty simple). So, you also can benefit from using OUDK, even if you are going your own way. You see, we do not sell UDKs, we sell Rifts and we appreciate anything that makes Rift more popular/usable. And your efforts are very much appreciated, of course!

Hopefully, from now on we could make UDK releases more regular. I wish we could provide incremental 'patch' updates between 'official' releases, but there are some difficulties with doing this. Will see.

Ok, I propose to compile a new list of feature requests we could work on after we finally release this UDK. Did someone complained about lack of PIE support? ;)

Most likely I will move back to the OUDK at some point, now that I can implement my own controls on it. I'll have to do some testing. Having to implement the shaders, dual rendering, etc. myself has been a great learning experience though.

Guys, it's nice to see this dialogue going on, as it affirms things are being worked on in response to the community and not just the back room machinations of a couple of organizations (old school business practices). I'm sure this kind of conversation may be taking place for those working on the hardware side of things, but that seems to be on a path to being worked out for the benefit of all of us (hello HD Rift). Content on the other hand is the fuel for the engine and without it, boredom with a Rift after 24 hours of use will relegate it to the closet.

I've checked out the VRJam winners content and think Oculus did well in choosing their grand prize winner, it really is the most compelling package. Now we need 150 of those with 75% of new content being able to engage users for more than 20-30 minutes. Of course this was the results of a mere month, with that, it's obvious that some of us are going to need a solid year. And to get a solid year of development in, we need a solid set of tools. After six months we are starting to get that, but....

We are not out of the woods yet. A user on the Indie UDK Developers page on Facebook has recently learned that content made in the February 2013 build of UDK cannot be pushed up to the Desura/Steam browser due to an incompatibility. What happens when we invest 'x' amount of time in our efforts to support the Rift using the September (or?) build of OUDK and find out next July that we need to port our work to a July 2012 build (pre-Oculus Rift) so we are Steam compatible?

If, UE4 is going to be publicly available as UDK4 within the next 180 days, I for one could deal with developing my assets and holding off on logic and materials if I knew I'd have that access and compatibility with the Steam network. Without the knowledge of being certain of compatibility, and knowing that Epic is more concerned (rightfully) with UE4, my path of working with UDK feels very uncertain. Unity therefor still has a certain amount of appeal due to this potential to be distributed while not relying on the cooperation of compatible networks. (Btw, has anyone looked at the numbers of how many of the VRJam projects were created in Unity and how many in UDK?)

I believe that the NDA signatories at Oculus are likely thrilled, as they see and know at least part of the road map that Epic has laid out regarding UE4 and probably wish they could share with us devs, but wishes do not satisfy business realities, not even virtual realities. So I'm left here hanging, a content creator who believes he's on the path to creating compelling content and collateral materials that would benefit the community at large, but who's at a crossroads of having to choose the best versus the most convenient/expedient solution. Damn.

"unity2k" wrote:
Guys, it's nice to see this dialogue going on, as it affirms things are being worked on in response to the community and not just the back room machinations of a couple of organizations (old school business practices). I'm sure this kind of conversation may be taking place for those working on the hardware side of things, but that seems to be on a path to being worked out for the benefit of all of us (hello HD Rift). Content on the other hand is the fuel for the engine and without it, boredom with a Rift after 24 hours of use will relegate it to the closet.

I've checked out the VRJam winners content and think Oculus did well in choosing their grand prize winner, it really is the most compelling package. Now we need 150 of those with 75% of new content being able to engage users for more than 20-30 minutes. Of course this was the results of a mere month, with that, it's obvious that some of us are going to need a solid year. And to get a solid year of development in, we need a solid set of tools. After six months we are starting to get that, but....

We are not out of the woods yet. A user on the Indie UDK Developers page on Facebook has recently learned that content made in the February 2013 build of UDK cannot be pushed up to the Desura/Steam browser due to an incompatibility. What happens when we invest 'x' amount of time in our efforts to support the Rift using the September (or?) build of OUDK and find out next July that we need to port our work to a July 2012 build (pre-Oculus Rift) so we are Steam compatible?

If, UE4 is going to be publicly available as UDK4 within the next 180 days, I for one could deal with developing my assets and holding off on logic and materials if I knew I'd have that access and compatibility with the Steam network. Without the knowledge of being certain of compatibility, and knowing that Epic is more concerned (rightfully) with UE4, my path of working with UDK feels very uncertain. Unity therefor still has a certain amount of appeal due to this potential to be distributed while not relying on the cooperation of compatible networks. (Btw, has anyone looked at the numbers of how many of the VRJam projects were created in Unity and how many in UDK?)

I believe that the NDA signatories at Oculus are likely thrilled, as they see and know at least part of the road map that Epic has laid out regarding UE4 and probably wish they could share with us devs, but wishes do not satisfy business realities, not even virtual realities. So I'm left here hanging, a content creator who believes he's on the path to creating compelling content and collateral materials that would benefit the community at large, but who's at a crossroads of having to choose the best versus the most convenient/expedient solution. Damn.

According to thisthread on EpicGames forums the Desura/Steam issue can be fixed by replacing Unsetup.exe with a version from a 2012 UDK build.
I'm not sure what our chances are of seeing a UDK4 before at least Q3 of 2014, but with the Desura/Steam fix you shouldn't need it. :)

Uhm. Wait. What is the issue with Steam once again? I should say, I hear this for the first time that you need to use obsolete UDK (jul 2012) or even 'genuine UDK' to be qualified for Steam. Are there any proofs for this? We definitely can work this out with Valve / Epic if it is so.

UE4 is on its way, but I have no info about availability of UDK4. I don't think, it will happen in nearest future, but this is just my opinion. All what I can say that Oculus will be integrated into UDK4 from the very beginning. But there is still a lot of work to do to make this happen (from both sides - Epic and ours).

"artyom17" wrote:
Uhm. Wait. What is the issue with Steam once again? I should say, I hear this for the first time that you need to use obsolete UDK (jul 2012) or even 'genuine UDK' to be qualified for Steam. Are there any proofs for this? We definitely can work this out with Valve / Epic if it is so..

From the Indie UDK Developers page on Facebook:

We've found out recently that the game created with 2013 UDK (both Febuary and July) will not be able to launch via Desura/Steam browser (since they require uploading whole unpacked game folder). And mid-2012 UDK can't import packages created by Febuary 2013 UDK. So, this is a serious issue. While the stand alone version of our game still run fine, we can't make it work with Desura/Steam browser. I've upload a title to Desura in 2012, that one did not suffer this problem. Anybody has overcome this problem?

HappyHimitsu pointed to a potential fix on the Epic forum that might be the fix. Waiting to learn if this helps Pawee Pakamekanon, the person who posted this.

I don't want to be an alarmist Artyom17, but I also don't want to invest in a potential dead end or an insurmountable obstacle that could derail a year's worth of work and investment. These previous delays I have seen as stumbles, I am seriously trying to convince myself that going forward we are going to see a new face of progress.

Fair enough and I totally understand your concerns. I elevated the issue with UDK-Steam to our exec level, will see what happens.

I still think that UDK3 has long lifetime ahead. And, anyway, the only real alternative to UDK is Unity, that is it (and Unity has its own quirks). UDK4 will be pretty different than UDK3 (no UnrealScript, no idea what the UI system is going to be, it will be much greedier to resources (CPU and GPU, especially the latter one!)), so, even after UDK4 is released a lot of indie developers will stay with UDK3 for a long time, IMO. For example, I can run UE3 on my MacBook in HD with 40 fps, but UE4 is very slow on it, like 15 fps. Just saying.

I can't find the command to disable tracking in Oculus.uc yet... One concern I have is that there seems to be a lot of extra stuff that doesn't really belong here.

exec function ToggleGun()
{
    bHideGun = !bHideGun;
}

exec function ToggleMomentum()
{
    bDisableMomentum = !bDisableMomentum;
}

function PlayDamageEffect(PlayerController PC)
{
	local PostProcessSettings PP;
	local LocalPlayer LP;

	LP = LocalPlayer(PC.Player);
	if (LP != None)
	{
		PP.bOverride_Scene_Desaturation = true;
		PP.bOverride_Scene_Colorize = true;
		PP.Scene_Desaturation = 0.5;
		PP.Scene_Colorize.x = 1;
		PP.Scene_Colorize.y = 0;
		PP.Scene_Colorize.z = 0;

		LP.OverridePostProcessSettings(PP, 0.5);
	}
}

etc.

There is a lot of code here that seems to be related to the functioning of UTpawns or UDK pawns. This should go in subclasses such as UTOculus, or UDKOculus. This way the levels are clearly separated and you can delete all the UT and UDK level classes.

BlackFang, it is a console command 'motion off' and 'motion on'. I'll make an UnrealScript function for this before RC2 is published. But you still should be able to exec console command via UnrealScript, right? Refer to UE3-Oculus.txt for the list of commands.

"artyom17" wrote:
it will be much greedier to resources (CPU and GPU, especially the latter one!)), so, even after UDK4 is released a lot of indie developers will stay with UDK3 for a long time, IMO. For example, I can run UE3 on my MacBook in HD with 40 fps, but UE4 is very slow on it, like 15 fps. Just saying.

But if development is taking place with an eye on 2015 as the year someone's product is to find its stride and that the hardware being targeted is the equivalent of an Nvidia Titan paired to a Haswell, then UE4 starts to look appealing. Matter of fact, if UDK is going to have such long legs, why has Oculus taken to demoing the HD Rift with UE4 instead of showing off how amazing UDK can look? I mean this rhetorically and do not expect an answer.

I know that Steam data shows the majority of users are running DX9 or DX10, but these are gamers who for the relative recent past have shown they are not willing to spend for fast systems, fortunately gamers are not the entirety of the potential market for VR ;)