I've been unlucky in searching for a solution on the furums which I am not able to find. I need to figure out how to make it possible for a classic First person character to be controlled by GUI butons (arrows) instead of the cassual WASD style
If you mean the arrow keys on the keyboard, it works by default with the Unity FPS controller in the 'Character Controller' package.
If you are not already using this package, you can import it by selecting Assets -> Import package -> Character Controller.
If you mean GUI buttons as in on screen controls, I would strong recommend that you don't. Because to click on any of these buttons, you have to move the mouse to that position, and then you can't control which direction the FPS controller is moving.
Related
I have a two modals that I'm designing to go over my project in Unity, one for a quick tutorial and one for more information about the project, I also have an animation playing in the background.
I'd like the animation to pause whenever the modals are active and over the top of the animation, if you can't see the animation, why have it playing? Exactly.
My code so far doesn't work and I'm unsure why.
using UnityEngine;
using System.Collections;
public class ModalPauseController : MonoBehaviour
{
public GameObject tutorialModal;
public ScrubberAnimationController nac;
public void TutorialModalIsOpen()
{
if (tutorialModal.activeInHierarchy == true)
{
Debug.Log("The tutorial panel is active!!");
nac.UserClickedPauseButton();
}
}
}
nac.UserClickedPauseButton refers to another script where it pauses the animation.
So far whenever I toggle the active state of the modals, whether it be via the inspector, or in game, I no feedback in my debug.
It's quite tricky writing code like that, because if you think about it
the code itself will be not active !!!
As a rule say you have a panel "X" which is a popup or something like that - something which comes and goes.
The rule is you must have the "controller" for that thing
on some other item, not on itself!
Here's an example:
The "megabomb" is a popup sign which goes on and off. There it is on
and there it is off. There's a script which controls the megabomb on-offness.
Notice there is a "wrapper" for the megabomb item. In UI the "wrapper" is very simply an empty panel. It is invisible. Note that the wrapper always stays on.
The script goes on the wrapper - that's it.
Note that very commonly the "megabomb" item itself has a "wrapper" - a gray transparent background. So, when the popup appears, the game behind goes all gray and you have the popup over that. Don't forget in that case the gray background would be labelled "megabomb" in this example and the actual popup green (or whatever) panel would be below that. (Indeed the popup panel itself will very likely have many parts -- images, buttons, borders, etc etc.) Do not try to use the "gray background" as the "wrapper which holds the script. You need a completely separate wrapper "outside of everything" which does nothing other than hold the script.
{BTW this is yet another thing which screws up experienced-developer-who-are-new-to-Unity. Normally you'd have "some other class" run the popup, but there is "no other class" in Unity - everything is a singleton if you will, since it is an ECS system, not normal OO. You have to literally have another game object (the one labelled 'wrapper' in the example) which controls the game object in question (the one labelled 'megabombs' in the example). AND it has to be always active.}
Note - if you prefer the "controller script" can actually be anywhere else (it does not have to be on an game object "holding" the item in question). However certainly at first I encourage you to use the system of putting it as a "wrapper" as shown, it has many advantages. (Not to mention ultimately it might be a Prefab, etc etc.) Definitely do that when starting out.
It's just "one of those things they don't mention" about Unity: very often many many things in your scene will need a "wrapper" object. (The same is true for other reasons such as positioning, relative rotations, etc, too.)
BTW as I mention in a comment. If you are making a popup, it must be done with Unity.UI (ie, click "add canvas" - always remember to set to 'scale with screen size' , then click "add panel", then click "add text").
When I double-click on an animator controller to launch it, the animator tab appears, but when I run the editor, I don't get the usual flow, operations, etc... I only get a static view of the states and transition arrows between them. My parameters do not show the changes they go through either.
I have multiple animations and can switch between them when certain game conditions occur, but nothing really shows when I do so, to see the flow of control, what happens, what goes wrong, the switching, the progress bar, etc...
I have the latest Unity 5.2.0f3 so I wondered if it is just me or others are having a similar problem...
What we need to do is this: Once we hit the play in the editor mode (and have the animator window docked on one side, of course) we just go and click the object in the hierarchy for which we want to analyse the animation flow. And the animator window will start showing the states and the progress bar.
Also, after upgrading to Unity 5.2, it is worth checking the values that were previously set for transition states, for example if vSpeed is greater than 0.1 then start walking. All my set values were messed up; i.e. changed.
I'm using MFC (yes must be MFC and no I can't interop with .Net) to create a CFrameWnd.
My goal is to create a CFrameWnd containing a CFormView which is based on a Dialog Template that resembles something like:
I have got the frame and view to display, and I have an Edit control on there. Now what I want is to have a CToolbar aligned to the top of the Edit Text control but not docked to the top frame.
Ideally I would like to have a child frame/view that I can dynamically add in place of the Statement Group. That way I could just dock the toolbar as normal.
The thing that I find odd is that I could easily achieve this if I had a splitter in there by using the CreateView function. I really don't want to have a splitter and feel there ought to be another way.
In summary, these are the question I need help with:
Q1 - How can I have a CFrameWnd within a CView (like what CSplitter::CreateView does)?
Q2 - How can I position a toolbar within a CView without docking or floating it within another frame (I'm more than willing to resize, position it manually if only I knew how)?
Now I really appreciate how easy things are in .Net.
I wouldn't recommend sticking a CFrameWnd within a CView. You'll be fighting MFC all the way, basically living in a world of ASSERTs as the internal functionality such as message routing assumes that Frames don't live in views.
Instead just use a CWnd instead of the CFrameWnd and in the 'Create' method manually create the toolbar and the edit ctrl and size and position them yourself (create a AdjustLayout method that uses CMFCToolbar::CalcFixedLayout to adjust the position of your other components).
A great example of this is in the Visual Studio sample app PropertiesViewBar.cpp:
http://msdn.microsoft.com/en-us/library/bb983983(v=vs.90).aspx
Note: You might need to override OnCmdMsg to extend the message routing to the internal controls.
In spite of there being a Human Interface Guidelines document (HIG), a lot of high quality Mac desktop applications use custom controls. My question is what is the best approach to start subclassing controls for Cocoa development? It surprises me how little (good) information there is on this topic. What path is the best to follow so you don't end up with a nice but half broken control?
Here's a checklist:
Make sure your control works correctly at double resolution. Use Quartz Debug to test this. You'll want to test both drawing sanity (in all states—normal, selected, pressed, disabled, and any others) and operation sanity (that hit testing matches where things appear on the screen/other destination device).
For extra credit, make sure your control works correctly at 1.5 (or some other, similarly non-integral) resolution.
Test how the standard control works when clicked. You'll probably do this anyway. Do as the standard control does.
Test how the standard control works when half-clicked (mouse down inside, mouse up outside).
Test how the standard control works when dark-side-of-the-clicked (mouse down outside, mouse up inside).
Test how the standard control works when dragged within.
Test above four with the other mouse buttons (right and middle).
Test what the standard control does when you scroll with a scroll wheel. Also test shift + scroll and, on a mouse that has them (e.g., most Logitech mice), scroll left/right buttons.
Test what the standard control does when you two-finger scroll in each axis and in both axes.
Test what the standard control does when you pinch and when you unpinch.
Test what the standard control does when you swipe with three and four fingers in each axis.
Test how the standard control works with “Full Keyboard Access” turned on. Can you tab into it? Can you press it with the space bar? Can you enter it with the return key? Can you tab out of it?
Test how the standard control responds to Accessibility queries. Use Accessibility Inspector. See the Accessibility Programming Guidelines for Cocoa for information on responding to accessibility queries and messages in your control.
Test your app—including, but not limited to, your custom controls—in VoiceOver. Blindfold yourself and try to use the app with VoiceOver alone.
If applicable, test printing your view. You can print to Preview if you don't want to kill a tree for your development process.
Test printing in other paper sizes. If you're in the US, test A4; otherwise, test US Letter. Test still other paper sizes (such as Legal and A3) if you're feeling thorough.
If you're implementing a scroller (poor you), test that your scroller responds correctly to the “Jump to the (next page|spot that's clicked)” preference in the Appearance pane in System Preferences. “Correctly” means it should do what the user selected.
Make sure it correctly implements all four scroll-arrow-position settings: One at each end (Mac style), both at the lower/left end (NeXT style), both at the upper/right end, and both at each end (power user style). As always, you need to both draw correctly and hit-test/react correctly. (Suggested by #radiofreelunch/by David Dunham)
Also, if you're implementing a scroller, make sure it responds to the “Smooth scrolling” preference correctly.
Test that it responds to different scrolling speed preferences correctly.
If you're implementing a text entry field of some sort, or any view that responds to some sort of special hot key (like Enter to send a message in an inputline), test right-to-left (Hebrew/Arabic) text input and alternate input methods. The Character Viewer is a good start.
Also, test that you don't break ctrl-q. For example, ctrl-q, tab should always enter a tab character. The same typically goes for option + (key), such as option-return in an inputline.
Test that it responds to different key-repeat preferences correctly.
If you implement any custom keyboard shortcuts (⌘ + zero or more other modifiers + one or more character keys) by means other than Cocoa's standard menu shortcut handling, test your custom shortcut behavior under Dvorak. There is no faster way to sour our perceptions of your app than to respond to ⌘' by quitting.
Show your app to users who've never used it nor seen any mockups before. Disqualify programmers. If they don't recognize your control as a (whatever it's supposed to be), redesign it. If you ever say “the scroller is over here” or “you need to click that”, you instantly fail.
Test that your control responds (or doesn't respond, if responding would be dangerous) when your app is in the background. (Suggested by #chucker.)
Test that your control responds, but does not bring the app forward, when your app is in the background and the user clicks on it with the ⌘ key down. (Suggested by #chucker.)
Test resizing your view. Among other things, this will ensure that you set the autoresize mask correctly. You're also looking for drawing bugs—distorted elements, gaps, etc. (Part of this suggested by #Bagelturf.)
If your control is, in fact, a control, send it sizeToFit and make sure that it does the right thing. (Suggested by #Bagelturf.)
If you work with mouse coordinates, don't assume that they will be whole numbers. Ensure that you handle fractional numbers, zeroes (positive and negative), and negative numbers correctly. (Part of this suggested by #Bagelturf.)
You might also consider splitting your control into a control and a cell. In the latter case, also perform all of these tests on your cell embedded in an NSMatrix and in an NSTableColumn.
If your control has a menu, test what happens when the control is at one or more edges of the screen. The menu should move over to not fall outside screen space.
If your control has a menu, test that the user can enter it with the down arrow key when using “Full Keyboard Access”. If it is also a text field (like a combo box), test that this only happens when the user presses the down arrow at the end of the text; otherwise, normal text field behavior should rule: Pressing down on a line that is not the last line should move the cursor down a line, and pressing down on the last line should move to the end of the line.
If your control has a menu, test that it stays open when clicked and does not immediately close when held open. There is a function you can use to do this correctly, and it is available in 64-bit.
If your control has a menu, test that it is navigable (all four arrow keys + Home, End, Page Up, Page Down), usable (spacebar/return press action), and cancellable (esc) with the keyboard.
Hard to add anything to Peter's list, but if you're doing a scroll bar, be sure it handles all the deviant placements of the scroll arrows (like DoubleBoth).
I'm developing an interactive MFC application which displays a 3D object using my own algorithm, essentially using MFC as a framework, but using lots of pDC->Polygon(), pDC->Rectangle(), pDC->DrawText(), etc. calls.
The UI has numerous clickable areas which all work well. However, the onscreen controls for rotating, spinning, etc. the 3D image motivate users to double click, triple click, and beyond.
I'm 99% positive that CWnd::OnLButtonDown() is not called until Windows (or whatever) has decided the operation is not a double click, or when double clicked, but only once. That is a series of clicks results in a notification every second click. The user experience is stuttered rotation. The temporary workaround is to have users move the mouse slightly between clicks—It solves the problem, but is rather unfriendly.
The application does no double click event hooking. Maybe there's a way to go further to disable potential double click processing? Or maybe there is a lower-level way to capture the mouse button down?
I think you have it backwards - the first click gets through as a WM_LBUTTONDOWN, the second one gets turned into a double-click.
To prevent a window from generating WM_LBUTTONDBLCLK messages, remove the CS_DBLCLKS style from the window.
This is all explained in the WM_LBUTTONDBLCLK documentation.
Edit: I misspoke, CS_DBLCLKS is a class style, not a window style. I don't think you can remove it, you have to create a new window class that doesn't include it. It's provided by MFC - see this page http://msdn.microsoft.com/en-us/library/a77269ff(VS.80).aspx.
Just to add an answer, this method worked for me:
WORD dwStyle = GetClassLongPtr(handle, GCL_STYLE);
dwStyle &= ~CS_DBLCLKS;
SetClassLongPtr(handle, GCL_STYLE, dwStyle);
You can use these functions to edit a WNDCLASSEX style structure for an specific window removing the double click event and correcting the single click behavior.
GetClassLongPtr
SetClassLongPtr