I'm trying to extend the maximum depth of the pointers to use in a scene where objects can be further away. I've set the 'pointing extent' setting under the MixedRealityPointerProfile which seems to have no effect.
Am I missing something?
Thanks
Take the official HandTracking project as an example. To increase the pointer extent in Unity, please check the following steps.
In MRTK component, navigate to [Input] -> [Pointers] -> [pointer extent], setting the global maximum extent value.
Then navigate to [Input] -> [Pointers] -> [pointer options] -> [ShellHandRayPointer] and edit this prefab. In ShellHandRayPointer script, change the value of “Pointer Extent” and “Default Pointer Extent”.
If you cannot alter the prefab in package folder, you need to drag it into your self’s Asset folder then select this prefab in MRTK component.
Basic idea is besides changing the global extent value in MRTK, you also need to customize the Pointer profile to make it work. The above steps will modify the hand tracking pointer in HoloLens, and feel free to modify other pointer profiles if necessary.
To be clear, in the common scenario, interacting long distant objects are not recommended because due to small view angle, distant objects have to be extreme large for interactive. It is also recommended to check the document on Sizing recommendations - Mixed Reality | Microsoft Docs.
Related
I am new to the Godot engine so please forgive me if this is a very simple question.
So I am creating a game (2d platformer) that pretty much has the same level layout as every other level. However, each level has a trick to it. Say:
For level 1:
flick the lever (by pressing f) and a portal opens up.
enter the portal and go to next level (level 2)
For level 2:
flick the lever (by pressing f) 5 times and portal opens up.
enter the portal and go to next level (level 3)
For level 3:
flick the lever (by clicking with mouse cursor unlike level 1 and 2) and portal opens up.
enter the portal
etc etc.
So this is the layout for the game I'm developing. Problem is when I duplicate the level, the scripts (for lever, portal etc) don't seem to be "individual" to each level node. Is there a way to make it such that each level node and its sub-nodes (like the lever for level 2 having a separate script to level 1's lever)?
Thanks, and sorry again if this is a stupid question.
There isn't a trick.
This issue has come up in the discussion on the Godot-Proposals repository. Feel to offer your ideas on how to improve Godot there.
Godot is rather flexible on how you organize your project. This also means that keeping the organization you pick is up to you.
First of all, I must mention that scripts do not need to be their own files. On the "Attach Node Script" dialog (which you can open from "Attach Script" on the context menu on Scene) you can select "build-in" script. And this will store the script in the scene file. As a result, if you copy the scene file, you are also copying the script. Although, having the script in a separate file is often preferible for version control, and for using an external editor.
Beyond that, there are a couple tools that will help you:
On the context menu from the FileSystem, you can select "View Owners…". This will show you where resources (including scripts) are used explicitly (references using load or anything dynamic does not count).
On the Project menu, under tools, select "Orphan Resource Explorer…". This will show you any resources (including scripts) that are not used anywhere (again, it ignores dynamic loading, so it might say something you are actually using isn't).
With those tools you can - for example - make a folder for each level (and a folder for resources to be shared across levels, perhaps organized on folders by type), and check if the script on the folder of a level are referenced from the scenes on that same folder and not the folders of the other levels.
Some people prefer to put all the scripts on a single folder regardless of where they are used, and all the scenes on the same folder, and so on. That is somewhat harder to keep track of, but with the tools mentioned above you can check. Perhaps you could have a naming scheme so you can tell for which level each resource is (or if the resource is intended to be reused in multiple levels)?
Consider also:
Signals. For example, you might have identical levers except for what they do. Instead of coding in the script what they do, add a custom signal and connect it form the editor. Again, those signal connections are stored in the scene file. I would, for example, have the counter for how many times the lever is switched in the code connected to the lever instead of having it on the lever itself. By the way, see signal bus and resource based communication.
Exported variables. If you have similar scripts, identify the differences (e.g. to which level a portal goes), and consider turning them and turn them into exported variables (export var) which can be edited from the Inspector. Those variables are stored in the scene file, so they will remain unique even when you duplicate the scene. This also means that if you find an error on the code, you don't have to fix it on two different scripts. However, be aware that if you generalize things that might seem related but actually aren't, you will run into trouble later, so the general advice is to not do it preemptivly.
These also mean that those scripts would no longer be unique of the scene, and you can move them to a common folder for all such scripts and not worry anymore if they are used in - and only in - the correct scene.
By the way, I would like to point you to:
Scene composition: in Godot scenes can have instances of other scenes inside. So you can make scenes for the individual components (e.g. an scene for the portal) and put them together in the level scene. Then these scripts we are talking about do not really belong to a level, but to a component. And that component could be used in multiple scenes without issue (again, with the help of signals and exported variables).
Scene inheritance. What you are doings sounds like you could have a base scene with the common elements, and then create inherited scenes for each level from it (you find the option in the context menu of an existing scene in the FileSystem). The inherited scenes would have everything the base one has, but can add new nodes or change the properties of existing nodes.
There are diffrent approaches you could try to accomplish this.
The first that comes to mind for me is that you implement something like a current state for the diffrent items. So for example add a export variable to track the level you are in (or have it as an global variable somewhere). Then you check this variable in the _ready function and enter the correct state for the according level.
Your lever script would then only have the common functions like opening the portal and starting the flick animation, but the triggers, which call these functions are handled in the diffrent state scripts.
So your lever would look something like this:
extends Node
export(int) var level = 1
var state_paths = [ "path_to_level_1_state", "path_to_level_2_state" ]
var current_state = null
func _ready() -> void:
current_state = load(state_paths[level-1].new()
current_state.enter(self)
# delegate events to the state objects.
func _unhandled_input(event: InputEvent) -> void:
current_state.handle_input(event)
func _process(delta: float) -> void:
current_state.update(delta)
func _physics_process(delta: float) -> void:
current_state.physics_update(delta)
func open_gate() -> void:
$AnimationPlayer.play("flick")
#notify gate to open code..
There are definitly better and much safer ways to store the diffrent state scripts Like creating subnodes in your lever scene which conatin the scripts like done here for the state maschine but I guess this will do for the example.
(path_to_level_1_state is the full path to a script like "res:/scripts/states/lever/level1.gd")
This script could look like this (you can write a base class for all your states which hold the reference to the Item and implement base functions, but I'm not doing this here atm, because I write all this from my phone):
extends Node
var lever = null
func enter(parent) -> void:
lever = parent
func handle_input(event) -> void:
if event is InputEventKey:
if event.pressed and event.scancode == KEY_F:
lever.open_gate()
func update(delta):
pass #nothing to do here bit maybe in another level?
func physics_update(delta):
pass
Total newbi here. I have played with studio for a few h but can not get over the next hurdle.
I would like to draw wine growing areas on the map.
Managed to draw areas. Tick.
I would like to give these areas a unique name.
Managed to create labels.
But I don't understand how the text is associated with the area.
I then want to search for this label, so that the map zooms in on that area.
Just like when I search for "Coburg, Victoria, Australia".
I have managed to publish my maps including the areas in my WordPress website.
So my access token and my style does the right thing.
Need some hints how to get the labelling and searching happening.
Thank you for any help.
Regards
Romano
and welcome to using Mapbox.
I would like to give these areas a unique name. Managed to create labels. But I don't understand how the text is associated with the area.
Have you tried creating a Symbol layer, and setting the Text field to the appropriate field in your data source?
I then want to search for this label, so that the map zooms in on that area. Just like when I search for "Coburg, Victoria, Australia".
This goes beyond using Studio, and into building web maps with mapbox-gl-js. One starting point would be to use the Finder Impact Tool.
This might involve processing the data twice -- once for your base map, and another time in a spreadsheet to make available to the Finder template. It's possible to just do once, but would involve some modifying the Finder template.
https://labs.mapbox.com/education/impact-tools/finder-with-filters/
I'm new to ArangoDB and currently trying to display the "Game of Thrones" and "debian_dependency_graph" from the Example Datasets.
In the GoT case I'm able to get the full view by using "Fetch full Graph". Yet there doesn't seem to be a way to add "Traits" in a useful way.
Even stranger is the behavior of the debian_dependency_graph which gives a random, but useful result at first, but changes to nodes only with no added edges after displaying everything.
I'm aware we're starting with a random graph in the beginning, but why isn't there a useful way to switch between the possibilities? Also how comes in the Debian-packages the edges are gone after displaying everything?
From looking through the web I see that in previous versions there seemed to be a way for adding filters and doing changes, in my version (3.4.1, rocksdb)
I can't make much sense of "Configure graph settings". Is there something I'm missing out?
For instance services or showing AQL-Queries as graphs. I'm still trying to figure out what's out.
Screenshot of the Debian dependency graph (Full graph):
The "Configure graph settings" option which you mentioned above is a right tool for you to use.
You can force graph to be rendered starting from a specific node if you change Startnode (the value should be equal to _id property value of a particular object within your graph)
The problem with the missing edges looks like a limitation of the graph viewer (you are trying to display too many object at the same time and it will be a complete mess if it would render all the edges)
You can play with Search Depth & Limit settings to limit the amount of nodes being rendered at the same time which will allow you to see edges
I used text node as child od node to implement align support.
It's possible to do text clipping ? I text is bigger and parent node element.
And also I need to implement word wrapping.
I heard about new 2.0 - It seems this release has implemented som of this. Someone know something about date of 2.0. release ?
regarding v2, you may already download current version on the WIP branch on GitHub.
It's still not finished (we add new samples and unexpected features and options, so we we have lost some time), but it's already stable and used on some customers projects. Time-to-time we add new things inside :)
Regarding your request, relationship between a parent node and its children is only related to transformation. That means that only transformations (scale, rotation, translation) applied to a parent will be applied to the child. Nothing regarding the size. So you cannot use it to directly align your nodes.
Anyway, you may easily develop it: you know the size of your text and your parent (using getWidth() and getHeight() methods) and their positions so you can translate the text node to be aligned with another node.
To use the word wrapping, you may use the myTextNode.setWrapMode(CGSGWrapMode.WORD, true) call.
There is also CGSGWrapMode.LETTER (default) and CGSGWrapMode.SENTENCE.
Hope this help.
I am creating a series of window mockup templates based on the excellent Mockups library available on CodePlex.
I'm using their BaseMockup as the base for my control as well, and I followed the same outline of the steps listed here for sub-deriving from existing controls (Create a new empty class, add your default style to /Themes/generic.xaml, etc.)
The control is working great - the only thing is that it doesn't show up in the Assets library. I think this is because it's sub-derived, or because I need some attribute (the equivalent of the ToolboxItemAttribute for WinForms controls? ... which didn't work) to get it hooked up.
When I modify the code to derive directly from Control, it shows up - no custom attribute necessary. Of course that defeats the purpose of what I'm trying to do though...
The only thing I can find are several articles telling me to muck with registry keys, and none of them are clear or suggest a definitive way to do this with Blend 4. That last one advertises as a Blend 4 tips article, but admits at the end that it plagiarizes the content from the other two (for Blend 3).
Is that my only option - register my DLL? Is there a better way to do this?
A while ago I wrote a blogpost about this. I've included a .reg file and a .bat file for setting up the register and some directories. I think that's what you are looking for.
I believe you do need to muck with registry keys. Specifically,
32 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
64 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
Create a new key with the name of your control assembly. Then edit the Default string value under this key and set the value to the directory where the control assemblies are installed. See here for a full example (using the Silverlight paths).
Found it - there is an analogue attribute after all, it's ToolboxBrowsableAttribute.
You have to go through a little more rigmarole to get it set up, but it works great - no registry mucking necessary. It requires creating a designer metadata provider class, attributing your assembly so it's designer-discoverable, and then adding the attributes to your sub-derived controls inside your metadata provider.
Make sure you choose the appropriate version of the page for your version of Visual Studio, because the interface changes a good bit between 2008 and 2010.
This article on CodeProject has some good, real-world examples of setting this up. They're all in the 2008 style though, so bear that in mind if you're using 2010.