Template talk:Risky bar dpl

What is the purpose of this and how is it superior to {{skill bar 2}}? --JonTheMon 14:09, 8 October 2009 (UTC)

It's automated. People just have to set the skill names. Which, btw, is what they end up doing with Skill bar 2 anyhow. Backsword 14:14, 8 October 2009 (UTC)

So how is it better than skill bar 2? --JonTheMon 14:25, 8 October 2009 (UTC)

It's automated. People just have to set the skill names. Which, btw, is what they end up doing with Skill bar 2 anyhow. Backsword 14:26, 8 October 2009 (UTC)

So why does it automatically re-order the skills? Often times people will put skills in a certain order for a purpose. --JonTheMon 14:55, 8 October 2009 (UTC)

So this is putting skill bars in alphabetical order? When would you ever want that? What in game thing does this mimic? When do you ever see skill bars other than ones you have built yourself which are in whatever order you put them in? I'm highly confused. Misery 15:05, 8 October 2009 (UTC)

One could add an Ordermethod, but there are limited options. It's how DPL works. Backsword 15:18, 8 October 2009 (UTC)

I don't know why I asked the in game question thing... I swear I saw you say something about that. What's this going to be used for? It kind of looks like an exercise in coding more than anything else. Misery 15:24, 8 October 2009 (UTC)

It's for people who wants to use the look, but don't want to fiddle around with parameters. Which seems to be the general case. Backsword 15:28, 8 October 2009 (UTC)

Ah. I understand what this does now and it's actually pretty epic, it's just a bit buggy at the moment. For example, leaving skills undefined kills it (no default to blank skills) and repeating skills also borks the whole thing. That may not seem like a problem until you want two or more optional slots or blank slots. It also still seems to be doing alphabetical ordering after your last edit, but that could just be cache. Misery 15:46, 8 October 2009 (UTC)

Yeah, I'm aware. That's why I put that info into the description. I did extensive tests to get it to take duplicates. That's the reason you need to set 7 skills too, can't take duplicate Blanks. The distinct=false paramter should make it accept duplicates, however this does not seem to work. I think it may only work with linksto and linksfrom, but that's undocumented. And no, I think ordermethod =none won't help, but one can try other settings. Backsword 15:52, 8 October 2009 (UTC)

It took a little work, but I've combined a bit of your code with the original skill bar 2 to make User:JonTheMon/Sandbox/Template/Skill bar 2.1 --JonTheMon 15:57, 8 October 2009 (UTC)

Hrm, I am getting some anomalous behaviour with your version Jon when I put in multiple blanks. Default blank isn't working right either. Misery 16:02, 8 October 2009 (UTC)

That's probably because Blank is not a skill and is missing the infobox. Add a fail case - or just check for Blank - to fix this, Jon. poke | talk 16:03, 8 October 2009 (UTC)

Yeah yeah. I'm fixing it. Try it now? --JonTheMon 16:06, 8 October 2009 (UTC)

Seems to work to me. Move that code over to here maybe? Misery 16:08, 8 October 2009 (UTC)

(Reset indent) Eh, I don't like the name of this template as it is. I'd like to make it at {{skill bar 2 auto}} or something like that. --JonTheMon 16:09, 8 October 2009 (UTC)

I don't really care because no one will ever find it anyway ^^

It's pretty nice though. Misery 16:12, 8 October 2009 (UTC)

If you want to set it for each cell, you'd be better of having a seperate DPL call for each cell. That's less overhead and lacks the vulnerability of not being selfcontained. Still too much load for my tast. Is better to try to make the correct way work. Backsword 16:30, 8 October 2009 (UTC)

The rational I used was that database queries are less speedy than simple processing. So, use 1 dpl call, and then just use the data to fill out the template, which is just processing (faster than disk access) --JonTheMon 16:35, 8 October 2009 (UTC)

You'd only have a single Title= call in the alternative, so disk access would be the same. Faster even, since there is no pattern matching and thus no need to load data for that. Backsword 16:38, 8 October 2009 (UTC)

(Reset indent) Transaction overhead will make 8 calls slower. --JonTheMon 16:41, 8 October 2009 (UTC)

Not really. I presume it makes seperate SQL calls anyway. Backsword 16:45, 8 October 2009 (UTC)

All parser function calls are executed individually, so 8 DPL calls means 8 SQL calls. Caching the results with the VariablesExtension is actually a nice way to solve the problem as that extension is implementent natively and is probably faster than everything else. And calling the actual {{Skill bar 2}} template is much nicer than mixing up the DPL code with the very complicated structure for the display. poke | talk 17:17, 8 October 2009 (UTC)

I'd expect there to be more than one call, depending. Not sure what everything else you're comparing variables to. I'm not sure how nice is defined, but doing it that way creates a lot of redundancy, and makes having an overview harder. Also, it creates an unneccessary dependancy. Backsword 17:37, 8 October 2009 (UTC)

But it works (unless your version) and allows to use multiple bars on one page without running into problems because of too many DPL calls. And no, I would say your version would be a lot more problematic to overview. One DPL call is easier to understand than 8 calls that 1. look all the same but have still some very minor differences, and 2. as I said the whole displaying code is moved out of this template which makes it a lot easier to understand. poke | talk 19:04, 8 October 2009 (UTC)