[ADDON] EWOCprojects presents FPSFly

Coding Released Scripts and Themes
61

Palejed: You are having it run smooth on your end? Its still very choppy over here. I think it was the 3rd version you released that was smooth for me, and then ever version after that went back to the first versions behavior in terms of performance. Its a very stuttery experience. Mouse look is fine when not moving forward or back.

62

Windows 7 Pro 64bit here, mlook is smooth, movement is choppy.

63

@paleajed,
grabbed the version from git, but it crashes instantly for me, something odd going on with ctypes / X11.

When I commented the X11 stuff out its not crashing but not working right either.

I’ve committed functions to Blender for cursor manipulation.


window.cursor_modal_set('HIDE')
window.cursor_modal_restore()
window.cursor_warp(x, y)

so should be able to remove all platform spesific workarounds now.

64

Ill be implementing these straight away! Whats the revision of these commits?

65

r59905. or newer.

I’ve committed using these functions…

But code is using API a bit odd.

Some review:

  • Don’t store ‘state’ in globals (the operators ‘self’ can store this, eg, the operator its self now stores mouse initial location). Should be the same for ‘leftnav’, ‘rightnav’ … etc.

  • over use of globals in general, not to say you should never use them, but for this operator I woudln’t use any ‘global’ or ‘nonlocal’ statements. AFAICS its just not needed.

  • “for a in context.screen.areas:” you dont have to search areas, just use context.area (if for some reason you DO need to, do once in the ‘invoke’ function and store in self for reuse).

  • SetKey() - you can avoid a lookup table here by naming, Mouselook -> mouselook, Left2 -> left2, then just
    setattr(addonprefs, self.key, event.type)

  • bpy.types.Scene.Toggle, bpy.types.Scene.PreSelOff — not sure why you would ever store data here?
    – if its operator state store in the operator.
    – if its global store as a globals.
    – if its preference store in addon prefs.

… I see the Toggle is used to activate the tool, But this goes against Blender operator design.
Activate the operator to run it, LMB / Enter to execute, having tools add random vars like into the scene for their own use is bad practice too, if you really need this better define a property group “bpy.types.Scene.fps_view” or so and store all your props there.

66

Thanks for the world Z, As for other issue, On my win7 64 it just won’t even start, ctrl+shift+f does nothing and the checkboxes in N-panel do nothing either. Worked ok in like version 3. Before & after that I get nothing. It’s fine in linux.

67
  • Don’t store ‘state’ in globals (the operators ‘self’ can store this, eg, the operator its self now stores mouse initial location). Should be the same for ‘leftnav’, ‘rightnav’ … etc.
  • over use of globals in general, not to say you should never use them, but for this operator I woudln’t use any ‘global’ or ‘nonlocal’ statements. AFAICS its just not needed.

Yes, I was brought up using non-OO procedural languages, making extensive use off globals all the time, thanks for pointing this out to me.
leftnav, rightnav and more are also used in the redraw handler, Ive made a global mainop=self of operator and use mainop.leftnav in redraw. Is that right?

  • “for a in context.screen.areas:” you dont have to search areas, just use context.area (if for some reason you DO need to, do once in the ‘invoke’ function and store in self for reuse).

It was copied over code from another project that works in multiple viewports. Removed now.

  • SetKey() - you can avoid a lookup table here by naming, Mouselook -> mouselook, Left2 -> left2, then just
    setattr(addonprefs, self.key, event.type)

Handy! I did not know this.

  • bpy.types.Scene.Toggle, bpy.types.Scene.PreSelOff — not sure why you would ever store data here?
    – if its operator state store in the operator.
    – if its global store as a globals.
    – if its preference store in addon prefs.
    … I see the Toggle is used to activate the tool, But this goes against Blender operator design.
    Activate the operator to run it, LMB / Enter to execute, having tools add random vars like into the scene for their own use is bad practice too, if you really need this better define a property group “bpy.types.Scene.fps_view” or so and store all your props there.

bpy.types.Scene.PreSelOff is explicitly added for inter-addon communication so it wont interfere with PreSel addon

68

version 0.5.0 need Blender SVN r59905+

Thanks to ideasman42 now with cursor hiding on all platforms / old implementation was unstable.

You will need a r59905+ Blender build; the builds will be available in a few hours.

Otherwise keep on to your 0.4.2 !

69

version 0.6.2

internal reworkings

70

r u f’n out of your mind , how do u do all this coding . don’t you ever take a break . one after another . now that’s dedication . great work dude , good luck with this one , if it get’s the attension preselect got your in for a shit load of head banging . nice stuff , the blender comunity is absolutly the best, i usually say happy blending but in your case i’ll say happy coding . … by the way i’m still on r59044 and i’ll wait till the next release for this one . MABYE , HAHA

71

Working right this moment on a prototype of a level. Add-on is super helpful, good job!! However, can you please by default disable a need in pressing RMB to look around? Annoying as hell. Ctrl Shift F to look around and yet still need to press and hold RMB. Really annoying :no:
SaintHaven can tick it on if he wants :yes: but it should be disabled by default IMO

Btw, any reason making this add-on incompatible with official 2.67 ?

72

@paleajed, I dont think this is so much todo with OOP, we avoid this kind of global use in C too for similar operators, note that https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/editors/space_view3d/view3d_fly.c doesn’t use globals and is in a non oop language.

There are still some odd things going on, but probably best to focus on user experience first.

One thing though, bpy.types.Scene.PreSelOff doesn’t really belong in the scene.

I’d suggest to check if the addon is enabled and import it, then set a variable on the addon module. There is really no value in saving this runtime data in the blend file.

73

HI Paleajed,
Really nice addition, it was proposet on the committer mailing list. Is it going to be implemented in trunk then ?
ANyway, having the oprion to go a “human head level” would be great".
2 possibilities :

  • Let user click somewhere with snap to face enabled, then move the view to that point + 1,8m on z and add a constraint to keep that distance with the surface.
  • Choose a “ground” mesh, which will be the “walkable mesh”. (also add a constraint to the view +1,8m on z above the surface.
    We don’t need collision detection, but allowing to walk in the scene would be really nice.
74

You do realize the same can be said for you. “Motorsep can tick it off if he wants but it should be enabled by default IMO”.

Are your feelings/opinion worth more than mine or someone elses?

I think there is a logical reason, not an emotional one or one based on sentimental preference, to activate the mouse by default. It isnt Ctrl shift F to look around… its Ctrl shift F to enable a navigation mode. Thats a pretty big difference. You have to think of it as a mode activation.

As such by activating the mode, you have two options, mouse look and movement, both should be activated by the user. Since your hand is already on the mouse, it shouldnt be too much effort. Having the user act to get an operation or result plays a pretty big role in user interaction via behavioral sciences. Either way, it wouldnt bother me much to activate it manually by default or have it automatically turned off. I think any choice shouldnt be made though on personal annoyances or feelings but rather logic and functionality.

Additionally, the point is to make it by default, friendly with wacom tablets. Mouse look does not work with a wacom pen. It spazzes out the entire viewport. The reason being the pen is looking for where its located on the screen, not whether or not its moving in a x or y direction. Imagine if you have that mouselook turned on automatically by default… a wacom user’s screen will flip out, but if its off and they would have to press a key to tell it to mouse look…then they can effectively operate the addon by default. I hope that alone would be a good enough reason to not give way to your minor annoyance. After all, its just doing one, one time step. That shouldnt be hard to do right? If you believe your opinion is logical, make a solid argument for it. I’m generally the type to agree with the most logical approach, within reason.

I think its current implementation is pretty good as is, it just needs polish at this point.

75

line 88, in modal
setattr(addonprefs, self.key, event.type)
NameError: global name ‘addonprefs’ is not defined

76

With the latest build I am getting a crash on the latest blender release when activating the mode.

77

version 0.6.3

Indeed, Addon Preferences key bindings were broken, works again now.

78

You sure your build is recent enough? They only came available recently:
http://builder.blender.org/download/

Get the r59920 one!

79

Theres a toggle to revert back to old behaviour on the Addon Preferences and you can save your settings with the “Save User Settings” button. You only have to do that once.

80

Thats the one I tried, found here: http://graphicall.org/444

At the time it wasnt available on builder.blender.org. Ill give that one a shot.