[ADDON] EWOCprojects presents FPSFly

Simple new addition to the treasure chest :

FPSFly

Implements simple viewport navigation FPS style, as requested by some people in some other thread.

Trigger it with CTRL+SHIFT+F

Get here : download.

current version : 0.7.9

Hi, thanks for taking on this project,

I noticed that this addon runs a lot slower when the materials view is open (its somehow causing material refresh?).

had a check on the script and I would guess that adding/removing timers on every key event could be the cause.

I’d suggest to add one timer for the duration of the modal operators execution (even if this doesn’t turn out to be the cause).

version 0.1.1

New version online, it starts the timer when entering nav mode and removes it when user exits.
Cant really see what else could be causing this…

version 0.1.2

Removed trackball rotation effect.

It doesn’t work for me in Blender 2.67 :no:

I activated add-on, press Ctrl Shift F while in Perspective view and nothing. Shift F works, Ctrl Shift F doesn’t.

version 0.1.3

Some small changes.

Try starting it with the tickbox at the bottom of Npanel.

Or start Blender from commandline and look for errors there (which you can post here).

Got it working.

It only works if I save user settings, shut down Blender and restart it. If I just activate add-on and try using it, it doesn’t work.

Working quite well. Really like it. The only thing that when I press WA or WD or AS or SD, camera doesn’t move diagonally.

Another bug is that mouse cursor (the one that is arrow in Windows) is bound to Blender’s main Windows. As soon as it reaches edge of the screen, camera rotation stops. In other words I can only turn while cursor moves between screen sides. There should be no such limit - as long as mouse is moving, view should be turning.

Great job otherwise!

version 0.1.4

OK good to have people testing!

I mended the issue with normal enabling.

Also you can now move diagonally.

At the moment theres no real solution for the mouse cursor issue, having no power over it from Python (some things cant be done.
As an intermediate solution, you can hold MIDDLEMOUSE and the mouselook will freeze as long as you keep it pressed, so you can move the cursor back to the center.

This isn’t a bug with the AddOn but something that happens as a result of the way Blender tends to work with Scene scale. If you work on a scene (level) that uses a large scale value, when initiated camera movement is excruciatingly slow because of the global distances involved. I’m not sure how this can be solved (obviously changing scale values or working at a smaller scale isn’t an ideal solution), but thought it might be worth mentioning.

Other than that, the only (minor) issues just relate to the Display Properties (“N”) section having a short delay between de/activation and the checkbox status changing.

Great work so far!

Two suggestions:

  1. Lock mouse to center of view while in the mode and hide the cursor - this is what is done in WebGL FPS views as well.
  2. Make space key move up (In fps regular mode it works like jump). So in noclip type mode space usually just moves up in a vertical direction.

Having that, you would want a key to move down :slight_smile:

Logically, yes - in practice, not needed so much. It’s just avid FPS(or MMO) players will instinctively hit space to move vertically up, but are very used to looking down and then just pressing forward to move down. I think it probably has to do with when moving up you generally moving towards a “blank canvas” of the sky, so you don’t need to look where you are going, when moving down, you are trying to position yourself into a certain area of the map.

For example, the fastest way to travel a major city in World of warcraft would be to Mount a flying mount, hit space to fly above the city fast, then survey the city for your goal point, and press forward and aim at the goal.

BTW paleajed already has the UP/Down keys in on Q/E, but in MMO’s those are generally strafe keys. In most FPS’s they are either strafe or lean keys.

Ehh, for once, players don’t make levels, they just play.

When talking about level design, usually no one “plays” in the level editor - they make level and they know the hot keys. So assuming that level designer will be pressing Q/E to “lean” or “strafe” is faulty. That’s why there is WASD - A and D what get you strafing in the view.

How about we don’t confuse the author and use this extensively for level design? And when mass of MMO level designers begin questioning Q/E keys, then and only then maybe author should look into adding an option for that. As for FPS, leaning around the corners has little to do with level editor and level design process. Have you even worked with UDK/Radiant ? They don’t have anything nonsensical like this.

Seriously, why not to NOT make silly suggestion? :slight_smile:

I’m not saying we should have leaning in Blender, I agree - that would be silly. But Strafe keys on Q/E are not far from norm. The advantage to a setup like this would be you could rotate easily with keyboard and not need the mouse. But really, I digress, the space key for moving up would still be nice :slight_smile:

Ok feedback time.

  1. Still choppy. When pressing W, it should be a smooth forward movement (similar to Shift F mode) but less “slick”. For me it to incremental. Maybe its working better for others though. I could be wrong, since my coding experience is limited, but my guess is that you are telling the viewport to listen for keypresses, and that if W is pressed, move forward +1 (example) then stop. What would be ideal is for it to keep adding that value non stop (with a limit) as long as W is pressed so its not jittery. Again I could be completely wrong about this so, take that with a grain of salt, or in this case a variable of salt.

  2. C or X should make it go down where as space bar should make it rise.

  3. Like others have said, map the center of the viewport to the mouse pointer. This is fine because if the mouse is a high precision mouse, they can adjust the sensitivity there.

  1. Control + shift + F, or rather the enabling of the fly mode can probably be better. Perhaps something like control + f + right mouse click enables the FPS fly mode (if possible find a way to visually indicate its in fly mode) and then have the viewport only look around when right mouse is pressed. This would allow for the user to take their finger off the right mouse and move the mouse around but still be able to adjust perspective based on the WASDXSpace controls.

You have strafe keys on A and D, and I haven’t seen any level editor with Q/E strafe keys. Which makes me still think that level designers don’t care for it.

There is no need to use Space to move up. Use Q/E to move up and down.

There absolutely is a need. Think about it for a second. Hand and finger placement. Try strafing left and moving up, very awkward. This is why WASD is for left right forward and back, as its tied to a humans index, middle and ring finger. The up and down movement is generally tied to the thumb or index finger (for down). By doing this it allows the user to navigate through space without having to lose the ability to press another movement key.

The ideal finger placement is this:
W middle finger, S Middlefinger down, A ring finger, D index finger, X or C index finger down, Pinky is on the shift, Thumb Spacebar

By having this placement you can navigate in the most optimal and consistent fashion. Fingers for x-y movement, thumb for z.

They even have physical keyboards made around this particular layout: https://www.google.com/search?q=fps+controls&client=firefox-a&hs=Izf&rls=org.mozilla:en-US:official&source=lnms&tbm=isch&sa=X&ei=vM8oUvT1A8PiiwKXroHQDA&ved=0CAkQ_AUoAQ&biw=1920&bih=955#q=fps+keyboard&rls=org.mozilla:en-US%3Aofficial&tbm=isch&facrc=_&imgdii=_&imgrc=JNIwOHtwJeJLeM%3A%3B38vl9cLMpDVdxM%3Bhttp%253A%252F%252Fwww.ohgizmo.com%252Fwp-content%252Fuploads%252F2007%252F03%252Flamptron_mitten.jpg%3Bhttp%253A%252F%252Fwww.ohgizmo.com%252F2007%252F03%252F28%252Flamptron-mitten-mini-fps-keyboardgamepad%252F%3B500%3B178

I don’t need to think about it as I have been making levels for quite some time :slight_smile: I don’t even use up/down movement.

You guys like to theorize, instead of ask/listen to people who does level design on day to day basis :confused:

You assume I or others havent worked with level design? Please dont tell me you think you are the authority here when it comes to level design and LDDs. You should be thinking about it, because the control scheme exists for a reason and is used by many. Going up and down while being able to strafe left and right forward and back at the same time does have its uses in level design, whether you use it or not. While you personally might not make use of it, it is used and it would be nice for it to conform to general user expectations.