Status of support for Marker/Trail Attributes

[coderedart]

This issue tracks the implementation status of the Marker and Trail Attributes.

references to marker/trail attribute definitions. https://blishhud.com/docs/markers/attributes/achievement http://www.gw2taco.com/2016/01/how-to-create-your-own-marker-pack.html

First, we will focus on Markers

• [ ] (xpos: f32, ypos: f32, zpos: f32) - position of the marker in world space. required

• [ ] mapId: u32 - the map id in which the marker exists. required

• [ ] guid: Uuid - used as a unique id for this specific marker. to refer to/store in activation data etc.. required

• [ ] type: string - format "cat1.cat2.cat3" when we want the marker to inherit attributes from cat3 which is a child and inherits from cat2, which is a child of and inherits from cat1. attributes only get inherited if they don't exist already. categories are necessary so that we can only show markers from categories which are enabled in the menu. required.

• [ ] iconFile: path - image used as texture for this marker. only png files supported for now. optional.

• [ ] iconSize: f32 - default size/scale of the icon. atm, doesn't have units like meters or inches. default 1.0. optional

• [ ] alpha: f32 - how opaque you want the object to be by default. between 0.0 (fully transparent) to 1.0 (no transparency. default). optional.

• [ ] fadeNear: i32 - in inches (ingame unit). at this distance from player the marker starts to fade out. negative numbers means it never disappears. default is -1. optional.

• [ ] fadeFar: u32 - in inches (ingame unit). at this distance from player, the marker completely fades out. negative number means marker won't disappear at any distance. default is -1. optional.

• [ ] minSize: u32 - pixels. marker icon, if visible, must be atleast minSize pixels in size. optional.

• [ ] maxSize: u32 - pixels. marker icon, if visible can't be bigger than this. optional.

• [ ] color: string in format "#rrggbbaa". just use a online color picker and they will give you the hex codes of a color. color tint of marker. optional

• [ ] resetLength: u32 - for beheavior 4, this tells how long marker should not appear after F. for behavior 5, it represents how long the map cycle is. optional

• [ ] autoTrigger: bool - tells us if going near marker triggers it. quirk: the triggers need more explanation if its going within a range or pressing F etc..optional

• [ ] hasCountDown: bool - whether we should display countdown timer when we trigger it. optional

• [ ] triggerRange: f32 - distance at which the marker is triggered by the player. need to check if inches or meters. optional

• [ ] achievementId: u32 - id of achivement in gw2 api. needs apikey. hides the marker if achivement already done. optional

• [ ] achievementBit: u32 - bits representing partial completion of achivement in api. optional

• [ ] infoRange: f32 - distance at which info should be displayed. optional

• [ ] mapDisplaySize: u32 - size on minimap/map. optional

• [ ] mapVisibility: bool - marker should appear in main map.optional

• [ ] miniMapVisibility: bool - marker should appear in mini map. optional

behavior - integer. it describes the way the marker will behave when a player presses 'F' over it. The following values are valid for this parameter: [ ] 0. the default value. Marker is always visible. [ ] 1. 'Reappear on map change' - this is not implemented yet, it will be useful for markers that need to reappear if the player changes the map instance. [ ] 2. 'Reappear on daily reset' - these markers disappear if the player presses 'F' over them, and reappear at the daily reset. These were used for the orphan markers during wintersday. [ ] 3. 'Only visible before activation' - these markers disappear forever once the player pressed 'F' over them. Useful for collection style markers like golden lost badges, etc. [ ] 4. 'Reappear after timer' - This behavior makes the marker reappear after a fix amount of time given in 'resetLength'. [ ] 5. 'Reappear on map reset' - not implemented yet. This will make the marker reappear when the map cycles. In this case 'resetLength' will define the map cycle length in seconds, and 'resetOffset' will define when the first map cycle of the day begins after the daily reset, in seconds. [ ] 6. 'Once per instance' - these markers disappear when triggered but reappear if you go into another instance of the map [ ] 7. 'Once daily per character' - these markers disappear when triggered, but reappear with the daily reset, and can be triggered separately for every character

Trail attributes are mostly same.

• [ ] type: string - reference to the category just like marker. required
• [ ] guid: Uuid - a unique id. required
• [ ] trailData: path - file that contains actual trail data which represents the route. without this, trail has no meaning. required
• [ ] texture: path - similar to iconFile ofmarker. optional
• [ ] animSpeed: f32 - i have no idea what this is. optional
• [ ] trailScale: f32- width of the trail. need to find out what units to use for this. optional
• [ ] color: u32? - need to check. but similar to marker's color.
• [ ] fadeNear: i32 - similar to marker.
• [ ] fadeFar: i32 - similar to marker

We can update the status of attributes, and whether we want to explicitly ignore certain attributes or change how they behave (minSize/maxSize).

[AsherGlick]

I think it makes sense to track various tags in a meta issue or a milestone that links to any necessary sub-issues. Once the first draft of the burrito schema decided then it makes sense to also include the chart in some more publicly documented area such as the readme or a wiki. The following points can be moved to the relevant bugs.

I agree with your conclusion on height offset being mostly irrelevant, the only use-case I could imagine off the top of my head would be to adjust the height of an entire path at the same time. If that is a real use-case it can just become a feature inside of the editor panel instead of being an attribute.

minSize and maxSize was something I looked into but did not fully implement. There is already a bit of shader code here that might help with implementation. The catch is that that value is just a flat scale multiplier and not a pixel size so some work would need to be done to convert that using the size of the icon texture.

[coderedart]

minSize and maxSize have been a pain point for blish too it seems. I just changed the renderer from 3d to 2d, just to support this particular attribute in my overlay.

Will you be creating a meta issue/milestone for this? i have no idea how those work.

[AsherGlick]

In burrito all that will probably need to be done is just dividing textureSize(texture_albedo) by the min and max to get a float scale value in the vertex shader. It should be tied into #16 when that is implemented too.

A task list makes the most sense compared to a milestone in this situation. I dont think special permissions are required to create one.

[coderedart]

I already created a task list today at https://github.com/coderedart/jokolay/issues/4 , I will just copy paste some of that stuff

[coderedart]

is that okay? i suck at formatting

[dlamkins]

I agree with your conclusion on height offset being mostly irrelevant, the only use-case I could imagine off the top of my head would be to adjust the height of an entire path at the same time. If that is a real use-case it can just become a feature inside of the editor panel instead of being an attribute.

Another common use case is combining it with the behaviors as a node might be on the ground and you want the trigger radius tight around that object (to avoid triggering the behavior when the player isn't actually at whatever it is) but you don't want the marker rendered on the ground - you want it higher so that it's easier to see. That's not to say there aren't better ways of handling that, but that's been a common use I've observed.