Are you a level designer, SaintHaven?
Such control scheme exists for gamers who play games, not in the level editors.
Show me where UDK and Unity and Source have Q/E set for strafing ? You are mistaken design tools with games for general population.
Radiant typically uses the following for basic ‘free look’; control;
Left arrow = strafe left
Right arrow = strafe right
Up arrow = forward
Down arrow = backwards
A = look up
Z = look down
D = move up (jump)
Z = move down (crouch)
All the above are augmented if the mouse is used at the same time to ‘head look’ around whilst keys are pressed. Not sure if UnrealEd/Unity use the same functionality or keymapping but we need to keep the discussion about the former rather than the latter (which key does what might be remapped to the users liking). I tend to agree with motorsep though that thinking about movement from a level design or designer point of view may not be served so well compared to ‘player’ movement/control; the two don’t necessarily correlate.
I am an environment artist/ level designer first and foremost.
Show me where UDK and Unity and Source have Q/E set for strafing ? You are mistaken design tools with games for general population.
Where did I say strafe was Q and E? I clearly said A and D quite a few times. Q and E are almost never used unless it has to to with rotation or leaning, which are not necessary.
Perhaps there is more miscommunication.
My point is that x or c should make the camera go down, space bar go up.
Cool Addon, but where is the rocket launcher? 
Will controls be customizable (like any FPS does)? Not only keyboard, but even having mouse buttons custom? Also, it might be cool to have a key for walk/run speed adjust, as well as overall speed could be adjusted with mouse wheel. Anyway, Just some ideas… cool stuff.
Btw, You probably noticed, but this messes with PreSel highlighting, (maybe a solution is to disable presel during this mode since you can’t really edit during fpsfly)?
edit: oops, seems this is only for bge!?! Nevermind…
I really don’t think you need to be a level designer to have a valid opinion on how you would like things to work. If that’s the case, we should have a prerequisite to post up your mobygamesprofile before posting opinions on design tools. I think there are more game industry folk reading this thread than you realize 
Here I disagree - the control scheme was built for moving in 3d space - and it does so rather efficiently. It’s now pretty much standardized across FPS games and works well. Added bonus is people can instantly pick up the tool and know how to navigate.
I’m not and I don’t think anybody here is arguing strongly for Q/E strafing…moot point for me anyway. But one thing I do want to point out is that UDK/Unity/Source are not the “end all, be all” for level design. The industry is still young and all of the tools have lots of room for improvement. Additionally, the tools were made by coders, not artists - sometimes they don’t know the best way to build things, so they “just build it”. Blender suffers from the same thing - hence the new artist maintainers on the team.
@paleajad - you can probably just avoid the whole controversy altogether by adding in keybinding options! 
LiquidApe, as far as I remember the topic where it all began was tools for game developers. Not for general purposes for moving in 3D space. No one cares for this feature except game developers, and maybe, just maybe, architectural designers.
Even stock Radiant and derivatives don’t have WASD, they use arrows with WASD layout. Rage Tool Kit has actual WASD as I recall. No idea if UDK/Hammer/Unity/CoD Radiant have straight WASD or some other set of keys with WASD layout.
Sure, there are key binding in almost every level editor. Adding such option would be a nice thing to have. My point is that if one doesn’t work with level design, never used Shift F and never cared for such navigation, why brainstorm features that no one will ever use? (and put developer through the misery of working on something that no one will ever use)
Personally, any keys that work for Up/Down movement, except Space, will be fine by me. PgUp/PgDown anyone ? (Q/E fit the bill just nicer)
Just curious, if you claim you dont use up and down… why do you care or have a stance on where up and down is placed? Why so opposed to using the space bar? I mean if you dont use it, dont need it, why try to dictate what can and cannot be used? I just dont get it.
fyi, Space bar is almost universal for jumping or moving up in game engines when in that mode.
I oppose to space bar because space bar brings up Search menu in Blender. And since Blender is not a level editor, the core interface should be messed with. Space bar, just like right click selection is part of Blender’s core interface where people who use Blender expect Search menu to pop-up on space bar press. And since many more people use Blender for something else than level design, I don’t think it’s wise to alter certain things.
But you are in First Person fly mode, if you need to access a search function with the space bar then disable FPfly mode. Kind of obvious. Core keys are already used in this mode, so I dont know why you think the space bar will be any different. IN fact its not like you would interact with the spacebar menu when WASD deals with controls…are you going to type something in that doesnt have the letters WASD? I’m still not getting your logic.
It seems to me that your opposition is just based on feelings rather than functionality, and because you stated your believe you wont back away from that, its fine to do so but we have to make sure no excuses are being invented to oppose it. There would need to be a solid argument with rational behind it.
In this case, in FPflymode the spacebar menu wouldnt and shouldnt work, nor should the right mouse for the 3d cursor. Its not a modeling mode. Additionally you have to consider that different people will have different hotkeys. Some wont even be using the space bar for the same function and many remove the 3d cursor from the mouse buttons altogether. So the whole idea that those are sacred buttons, even in another movement mode shouldnt count because its not universally shared. What can be universally shared however is the controls offered by such an addon. The most common control scheme, the most familiar, the one that fits the shape of the human hand, the one with keyboards designed around such placement, is the scheme I recommended. It is only logical.
:no: I see you have way to much free time on your hands.
Less than a minute out of my time to respond to a forum comment is supposed to imply what? I really dont understand what the point of your post is supposed to do? Is it meant as an insult? A means of not replying on topic? A personal jab? lol Lets grow up a bit. There is no need for that. I made a compelling argument, with specifics. Thats all I can ask for in return or maybe a concession, not a personal attack of some sort.
The Space bar is placed where it is in an FPS specifically to serve the limited control requires of FPS control within a game environment, i.e. quick access to repeat, and often, reflex actions. Level editors and their control don’t have this requirement so ‘jump/up’ is often mapped to other more contextually appropriate keys.
Additionally, because many functions are persistently active in a level editor, this often means multiple operations are available irrespective as to the mode your in - most editors allow the user to select/deselect objects and/or allow access to various menu options at the same time. So yes, strictly within the context of level editing and augmenting Blender in that context, “Fly mode” IS (should/could be?) an editing mode.
To put simply, ‘fly’ or ‘FPS’ mode is an approximation that allows the designer to see the level from the playercamera POV whilst allowing them to manoeuvre in way that wouldn’t be possible to the player for bug tracking/design/construction editing. This contextual difference isn’t one of semantics.
This is absolutely the “contextual difference of semantics”. It has nothing to do with being in a GAME ENVIRONMENT or not. First off what is this addon supposed to be? A navigation mode for perspective which game artist would and could use when designing a level? OR is it the primary control scheme for level building? Is blender now a level editor? If so then why not argue a specialized FOR such? I dont believe that was EVER the point of the control scheme, if so I missed the memo. Thus contextual semantics.
The most important features in level building are snapping and generating the static meshes that will be used as some form of blocking volume (whether its to run on or prevent access to). First Person flying controls does nothing to really help this. In fact, its why applications like Maya, max, modo and Blender are BETTER at blocking out levels than a dedicated engine like UDK. It is precisely why companies like Naughty Dog built their engine on top of Maya, because it is far better to create levels with the traditional 3d asset creation navigation approach.
Where FPflying comes into play is with scale and assessment of the said level (and its mirroring a bit of your last paragraph, because it should be obvious at this point. Hope you didnt assume another usage was implied). It should not be used for modeling. I dont think any other professional environment artist would say it should be either. When previewing your level, you think about things such as pacing, scope, distance between interest points. It is to help the artist and designer VISUALIZE. Nothing more.
The space bar isnt primarily used for repeated actions (though it could be, just like nearly all the buttons on the left hand side of the keyboard), it has much more to do with HAND PLACEMENT. Hold you hand out flat and put it in front of you. Tell me, how high up does your thumb go? And the middle finger? Notice the shape and placement of your fingers. Now relate that placement to how the hand rests on the keyboard. It has EVERYTHING to do with accessibility.
Sure its not the end of the world if up is set to E or if strafe left is set to Q… but thats less than ideal, its less efficient. I am promoting efficiency and functionality here. Part of that functionality comes with familiarity. Familiarity is the key ingredient for intuitiveness. Its a crazy concept but I believe the end users actually likes things that are intuitive.
This is why I think its crazy there is so much opposition to the concept of up being tied to a space bar and panning the view tied to the right mouse button. I think many of us want the same thing, but there seems to be some issue with either semantics or perspective. Such a movement scheme should be able to be to toggled on and of on the “fly” (pun intended), between previewing and asset creation.
Oh, and why aren’t Valve, idSoftware, Epic, EA, etc. build their engines on top of Maya/MAX ? Did you even hear about stuff like CSG for blocking out levels? It’s not all about static meshes, you know…
There is nothing that beats blocking out level in specialized level editor, and decorating it with static meshes. It’s by far better for iterating and rapid development. That’s why I suppose UDK and Unity are leading dev kits and what’s why level designers were blocking out levels in specialized editors, and not in Maya for example.
I think you are mixing up environmental artist and level designer positions. Both need FPS cam controls, but only level designer is the one who tests game play mechanics in-game on blocked out levels (which he blocks out, not environmental artist) using … gamepad. Yes, that’s what most people use nowadays. Or if he is PC person, kb + mouse.
That being said, you don’t need exactly the same key binding in Blender as you might have in your game. Even with space bar bound to vertical movement, it will not help you to VISUALIZE jumping on the future level. It will bring you up vertically as if you were on a lift.
No… just no. That comment is so incorrect as to be downright ignorant and I’m not even going to explain to you why (luckily motorsep went some way to clarify above). GoodGod it’s no wonder I stopped visiting this place.
Ok kiddo, you keep thinking that. Its not ignorant nor do I doubt you have the experience to back it up, but assuming you do I think you need to realize the roles played in larger pipelines. Yeah you probably shouldnt visit this place because you know, people who come here are “ignorant” and all that right? Kind of funny because on Polycount you have agreed with my comments before, yet here with another user name you probably never considered that there are professionals here as well, that the user base isnt homogenous to one forum or the other.
I’ll be sure to let the guys over at Sony Santa Monica (god of war) know that they shouldnt be using 3DS max to design their levels, and that they might as well be part of team ignorant. See what you are not realizing is that the 3d asset creation packages are better at blocking out geometry, and when you have a studio that writes its own tools, it can create plugins designed to aid with that process. This doesnt mean you polish the level with all its assets, lights, and scripted events in the 3d application, but it does mean you get the foundation of the level down before its exported into the game engine. Some level designers are not artists by trade, they write their level design docs, get them approved and start blocking out the levels with whatever tools they have on hand. Working within the engine is easier when they dont have to learn a 3d asset creation package, and they can script in the editor itself.
Other studios in which they pair the environment artist up with the LDs or have them wearing the same hats, generally will often use the 3d suits to create the levels first. Why? More control and better workflow.
At Naughty Dog, they can work directly in Maya and jump right into the game play. This is great because they have access to both the expansive tools within the 3d application. This includes instancing objects, far better snapping and animating on the fly. Meshes can have basic rigs placed on them and moved differently even though its the same static mesh being called on. The point here is that working within a 3d asset creation tools IS better, but it all depends on the pipeline. One still has to go into the game engine and finish up the rest.
So its ok, call me ignorant, call a lot of LDs and Environment artists ignorant, if it makes you feel superior, I dont mind, just glad I can help someone with such needs out from time to time.
Either way, we all seem to agree that FPfly mode is mostly for preview and assessment. Maybe we should keep it all within that scope and within that context rather than try to go around saying how everyone else is wrong without providing a clear and concise argument as to why. Suppose we just ask for the option to change hotkeys, what a strange concept right?
How many levels have you made personally, SainHaven? Where is your shining portfolio? Why isn’t it in your signature? You keep pointing fingers and saying “they”. Show us what you got, what levels have you designed for something out there in the real-world.
You don’t know what the hell you are talking about. We are talking about rapid prototyping, for indies. You are keep talking about 200-people studios who spend years on making a game, using custom game engines.
You have no idea, sorry…
Yeah no I’m not getting into a d**k size comparison contest here, nor do I want to start detracting from this thread. I’m not the type to link my portfolio or my work to some forum account, you may be though. Its generally not a good idea to do so either, because its easy for it to come back and bite you in the arse. Thats the nature of the internet.
As for me not knowing what I’m talking about. You are entitled to your opinion… at the end of the day I lose nothing from you not believing me. There is nothing to gain even if you do.
Now feel free to humor me…where did you say this was about rapid prototyping for indies? Lol just said that now and expect everyone to be on some magical unannounced page of yours? Thats the first time I heard about it being about prototyping. But lets assume it was… then why are you wanting it in BLENDER if its for prototyping. For prototypes you are better off working in a dedicated game engine… flying around isnt going to help you in that. But wait, for indies? So only indies would use special level builders and not 3d packages? Thats funny because I have never heard of such a rule. Indies have access to a large assortment of tools, whether its Blender or Unity. I think you are making a very weak argument here, one that im not even sure makes sense much less doesnt contradict what you have said before.
I never once talked about about massive 200 people studios. In fact I dont even think Sony Santa Monica has half that. I am however talking about workflow and expectations. The purpose of blocking out levels in something like maya, blender or 3ds max is control. They are specifically geared towards creating and manipulating geometry. Level editors in game engines do not. No they specialize in the scripting and lighting set up of a scene, the game play. Modern game engines can import mesh data and convert it into a blocking volume…all you need is scale.
But thats fine, dont take my word for it. You just keep doing what you think you have to do and hope it works out for the best. Both tools are needed at the end of the day, but for what purpose is up to you. Personally I think you are just confused at this point but thats just my opinion.
Add: Why not just make a strong case why you think why editing geometry should a strong part of the FPflymode and why spacebar and right mouse buttons are bad for such control schemes? You still havent done that. All you did was oppose it. This way we can discuss the merrits or lack there of regarding that particular feature. If you make a solid case, believe it or not, I will agree with you.
<Double Post>