Guild Wars 2 Wiki talk:Semantic MediaWiki/Skill facts

The subobject code implementation in skill fact is going to look so bad.--Relyk ~ talk < 19:43, 4 August 2015 (UTC)

1. Fact type doesn't make any sense. What's the difference and what does it mean for semantic properties?
2. Facts don't have canonical names.
3. Target seems like you're reaching too far. The only place it matters is with self-inflicted conditions, we don't need to define it for standard conditions or anything else.
4. Any reason the icon couldn't be covered by the existing Property:Has game icon?

I strongly suggest we look at how Anet defines facts and the traits API beta and maybe do a complete redesign of how we document them. —Dr Ishmael 20:21, 4 August 2015 (UTC)

1. Fact type is to set the context of whether we need to handle the effect. Looks like status is used in the API.
2. Placeholder, it's more like Has fact identifier. The API uses a type field instead.
3. It's probably overkill.
4. The fact icon is only set if it's not an effect. I feel like Has game icon leads to ambiguity on whether you have a game icon for the skill fact or the game icon for the effect/status property to the skill fact. Matching the API means the type removes that ambiguity.

Skill fact redesign already matches up with where the API is at (which was my intent :P). I'd be much more comfortable matching the API semantics. So looking at it:

• The NoData is used instead of the property type used in skill fact. There isn't a type to handle the other generic properties yet. I prefer a more helpful type like property or generic is used and the API simply not include a description field.
• I like stacks more than apply_count.
• Looks like a percent type was decided on any percentage modifiers and time for any flat increase. We'll probably keep skill fact template shorthand.
• The API uses BuffConversion for the gain context in skill fact. I guess we match the target/source approach for that one.
• The skill fact template would remove the switch statement on combos to match the API.
• The API doesn't identify Recharge Reduced, so maybe it's grouped under percent? Not sure that makes sense when it has an explicit Recharge for duration increase.
• API also needs to cover condition removal because the structure uses couple different methods for those facts.
• The linked skill gets identified explicitly to the PrefixedBuff type and use prefix semantic.

--Relyk ~ talk < 21:21, 4 August 2015 (UTC)

Eh, I think you don't quite understand me about aligning with the API. I'll try to find time to write up my thoughts tonight. —Dr Ishmael 21:48, 4 August 2015 (UTC)

Here I've compiled my analysis of the facts currently exposed in the /v2/traits-beta API. I'm not concerned about using different names for the data fields (apply_count -> stacks or hit_count -> strikes). What I'm interested in is seeing if there's anything we can learn from the API in terms of how the facts are actually built. —Dr Ishmael 02:04, 5 August 2015 (UTC)

I understood you just fine. We're already building the skill facts a similar fashion. I don't see a cause for a redesign unless we're coding against the API. The only big difference to me is handling the percentage increases. Maybe I'm not being enthusiastic enough :P--Relyk ~ talk < 07:50, 5 August 2015 (UTC)