Thomasorus
Member
It's working! \o/ (Yes it's nothing at all compared to what is coming I know but YAY anyway). Now I'll continue this tutorial about jumps, and then I'll make a better stage. Thanks guys!
Question, I have been looking at tutorials, specifically for the particle editor and its all nice and good but I cant seem to find the option to add a texture to a particle effect anywhere.
Like, lets say i want a smoke effect to have pictures of my face coming out of it. This is something that should be achieved easily but I cant find an option to attach a texture anywhere. Any help?
new 4.6 beta is out.
new GUI tools look dope. tutorial is how to build a Mass Effect menu.
Are you saying there is a tutorial, or requesting someone to make one? I'm pretty sure the former isn't the case.
I do have one question, is it possible to change the model of something? I made a cube, gave it a script and rigidbody, etc. and I know that I could just create a new model and attach the script and edit the settings but I think it would be faster if I could perhaps replace the cube with an actual model, or a model with another model really fast.
It supports C#, JavaScript and UnityScript I believe. If you know C++ you'll have very little trouble with C# imho. Just watch their scripting tutorials for their example games and you ought to be good to go.I need to learn C# for this to do professional games right? (I know c++ not sharp no training in sharp at all.)
I came from a similar background of knowing pretty much only c++, and after learning c# I vastly prefer it. It's very easy to learn, especially if you already know c++I need to learn C# for this to do professional games right? (I know c++ not sharp no training in sharp at all.)
This is a fairly old tutorial, but still does what it's supposed to do.http://www.41post.com/3816/programming/unity-scaling-the-gui-based-on-the-screen-resolutionNot sure if I should post here or the other thread, but I never get an answer there, so here I go.
I have been having major problems with resizing GUI for different resolutions. My game is built for 1080p, but I need to be able to allow lesser resolutions. I fired it up on a friends shitty work PC which has an older radeon card in it at a lower res, and it breaks the GUI positions, so I reworked it, rather than a specific position, using (Screen.width / 2 - 200, Screen.height/2 - 100) etc.
This is a fairly old tutorial, but still does what it's supposed to do.http://www.41post.com/3816/programming/unity-scaling-the-gui-based-on-the-screen-resolution
Some of the syntax might have changed, but you'll get the idea by looking at the code
^You should check out the new UI system in the 4.6 beta. And maybe the video I posted a couple of replies back.
Simple question I hope: Do I need Pro to be allowed to release a very basic 2D game on the Android google store?
Thanks for clarifying. A friend and I are trying to make an Android game in Java and Eclipse but recently Unity did a 2D tutorial essentially making the exact same basic game in three hours so I really want to switch platform and make it better xDNo. Pro is only needed if you make around 100k a year.
This thread's a bit ded, but I figured I should ask in this one before the Indie Game Development one.
Is there a script or prefab that allows you to 'snap' two objects when a collision is detected? My idea is to make an archery game, but as you can imagine controlling the two objects with your hands (I'm using the Leap Motion) is extremely fiddly, so being able to snap the objects together would be very useful.
Is there a script or prefab that allows you to 'snap' two objects when a collision is detected? My idea is to make an archery game, but as you can imagine controlling the two objects with your hands (I'm using the Leap Motion) is extremely fiddly, so being able to snap the objects together would be very useful.
Hmm, do you mean just so that the two objects then move together? You can just make one object be a child of the other, with the "parent" property on the Transform.
Like HellBlazer said, making one the parent of the other will automatically move the child object whenever the parent object moves; the child object can still be moved freely. Dunno if that's what you are looking for - it might help if you described what objects in the game you need to tie together, and when.
Yeah, and then re-parent the arrow to world again (assign null as parent) when it flies off the bow.The game has to start off with them both separate (since a harder difficulty mode will remove the snapping), but when the arrow reaches the midpoint of the bow object it should snap into place and from thereon it should move in tandem with the bow. I should also clarify that the arrow can't stay fixed to the bow forever, otherwise the game won't work obviously - if the child object can still move freely of the parent object, that would be very useful since I can make sure that when a force is applied to the arrow e.g. pulling it back, it doesn't take the bow with it.
I imagine the programmatic way of doing this is to check whether the colliders of the bow and arrow have hit each other, and if so, make the arrow the child of the bow, right?
Yeah, and then re-parent the arrow to world again (assign null as parent) when it flies off the bow.
I'm not sure that simple parenting solves your problem though. With a crossbow, an unfired bolt is rigidly attached to the bow, so parenting would deal with it perfectly. But you want "Robin Hood" style archery.
I suspect the actual goals you have for the snap are these, but correct me if I'm wrong:
1) one hand still freely controls the bow position
2) the other hand still freely controls the rear end of the arrow
3) the arrow shaft is locked to always go through a specific point near the bow
4) arrow can still freely slide and rotate as long as the contact is retained
5) the bow is automatically rotated to the direction of the arrow
I think that should be pretty simple too (at least basic prototype; you'll probably want to add some constraints and special handling for some corner cases). Just constantly move the arrow with the hand input, using the rear end as a pivot, and rotate the arrow towards the contact point on the bow. Then rotate the bow according to arrow direction. Takes a couple lines of code. If you have trouble with this, I can build you a little demo scene or something.
Hmm, sort of hit a block with my archery game.
I'm using the Grabbable/Grab Hand scripts that come with the Leap Motion SDK to grab a bow and arrow, and I'm trying to make it so that when you have a hold of both the bow and arrow (i.e. they're grabbed), they can collide and therefore snap together.
I can make it so that they collide and snap together when they're not grabbed, but the default implementation tells the rigidbody of the bow and arrow to stop detecting collisions when it is grabbed. Another option I have is to make sure that the rigidbody keeps detecting collisions when it is grabbed, but this makes the object jitter and shake violently since it keeps constantly detecting a collision between the bow/arrow and the RigidHand that is grabbing it.
Anyone know if there's a solution to this yet, or is it just a limitation of the Leap Motion controller?
My main problem isn't getting the bow and arrow to snap together, it's the fact that the Leap Motion Grabbable/GrabHand scripts make the rigidbodies stop detecting collisions when they are grabbed. If I make it so that they do continue detecting collisions, the bow/arrow will constantly detect a collision between itself and the RigidHand, and jitter/shake violently.
Have you progressed with the problem?
If the issue is weirdness with the Leap Motion scripts, I'd try decoupling them from the actual physics. You could have your Grabbable objects as invisible objects on a different physics layer so they don't mess anything up, and your real arrow/bow/whatever objects tracking the Grabbable objects' positions via a script. You should be able to develop and test the logic part without involving the Leap Motion at all if you just manually move the input objects in the editor.
Since the thread's alive again, I'm wondering how many gaffers are using the Unity 5 beta? Any thoughts?
I've not dug too deeply yet, but so far I'm pretty impressed by the new options for plugging in custom rendering pipelines, or moreover, semi-custom ones, with CommandBuffers. I think Unity was already more flexible here than UE4, but this is another layer of polish/accessibility.
More awesome news today as Brendan Iribe, during his Oculus Connect conference keynote, announced that our two companies have extended our partnership in order to ensure that Unity is available for all of our development community. That means whether youre using the free version of Unity or Unity Pro, youll be able to create awesome VR experiences for the Oculus Rift and the Oculus VR Store for free!
Were working with Oculus to create an official add-on supporting the Oculus Rift in Unity that everyone will have access to for free. We know a lot of you have interest in creating new experiences and experimenting with one of the most exciting platforms around so were very happy to make that as easy as possible.
The Oculus add-on will include stereo imaging optimizations, 3D audio support, deeper Unity editor integration, inclusion of the Oculus Rift in the Unity development and debugging workflow, integration of Oculus-specific APIs within Unity, and direct publishing to the Oculus platform.
We do want to make sure everyone can work on Oculus projects while the Unity for Oculus add-on is in development. To that end, were working with Oculus to make the current Oculus plug-in, one that has been available for free for Unity Pro users, also available for those making games with the free version of Unity. This new plugin version will be made available for free download on the Oculus developer site as soon as possible.
Were already seeing some amazing things being made in Unity for the Oculus Rift. Projects like Luckys Tale, Game of Thrones: The Wall, The Gallery: Six Elements, DarkNet, Titans of Space, Blocked In, and our 2014 Unity Awards winner for Best Student Project, The Rift: U.R.I.D.I.S., demonstrate the great creative potential in virtual reality and the Oculus Rift. We cant wait to see what you can do with dedicated tools!
David
Since I don't know how the Grabbable script works, I suggested a solution that doesn't rely on modifying it. If you have the Leap Motion stuff on one physics layer, and your regular physics (which the bow and arrow can still use) on another physics layer, the Grabbable object isn't connected to the arrow in the first place, or controlling the arrow - it's the other way around. The arrow has a script which makes it follow the Grabbable object until you fire the arrow. While firing the arrow you just have to turn off the script and there's no longer any attachment.I have a little, but not as much as I'd like. A suggestion from the Indie Game Development thread was to use OnTriggerEnter rather than OnCollisionEnter, which could be alright for now but would need to be changed later. Having invisible objects do the physics and the arrow/bow textured object follow the invisible objects sounds like a good idea though.
I've been concentrating on what should happen once the arrow is connected to the bow rather than worrying about getting the arrow onto the bow in the first place - when the arrow is connected, pulled back by my left hand and reaches a certain threshold, it should disconnect from the bow and fly forward (Vector3.forward * 100 or something). What actually happens is that the arrow is still being grabbed by my left hand, so although it disconnects from the bow, it doesn't move forward (since it's following my left hand). I either have to figure out how to override the Grabbable script or somehow set the private _grabbed = true; variable in the Grabbable script to false.
Since I don't know how the Grabbable script works, I suggested a solution that doesn't rely on modifying it. If you have the Leap Motion stuff on one physics layer, and your regular physics (which the bow and arrow can still use) on another physics layer, the Grabbable object isn't connected to the arrow in the first place, or controlling the arrow - it's the other way around. The arrow has a script which makes it follow the Grabbable object until you fire the arrow. While firing the arrow you just have to turn off the script and there's no longer any attachment.