Guild Wars 2 Wiki talk:Semantic MediaWiki/Skill facts
From Guild Wars 2 Wiki
Jump to navigationJump to search
The subobject code implementation in skill fact is going to look so bad.--Relyk ~ talk < 19:43, 4 August 2015 (UTC)
- Fact type doesn't make any sense. What's the difference and what does it mean for semantic properties?
- Facts don't have canonical names.
- 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.
- 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)
- Fact type is to set the context of whether we need to handle the effect. Looks like status is used in the API.
- Placeholder, it's more like Has fact identifier. The API uses a type field instead.
- It's probably overkill.
- 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)
- 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)