Default grid parameters and link targets

[Chocohead]

Every entry has the option "Default grid parameters", but it's always empty. What does it does/does it do anything?

It would be useful if links could be predefined using it, as it could avoid the need for using redirects due to it automatically disambiguating the links into Item Name (Mod).

[retep998]

I can't figure out what it does. The only method that returns anything derived from that is getParamString which is never invoked anywhere.

Besides, I personally think we should migrate to a world where all articles are disambiguated with (Mod) by default and we just have redirects or disambiguations from the names without (Mod).

[Chocohead]

Still, it could be used for other things, like allowing tooltips to be changed for items that have escaped characters for names (Like Test Name could have |title=Test: Name).

[retep998]

I'd prefer that to be done via FTB-Gamepedia/Tilesheets#8 instead

[Chocohead]

It could simplify things like ingotCopper automatically linking to the Copper page rather than each mod's version, which would be a redirect to it anyway. Although I think you can force this with the link parameter of the {{O}} call too.

[elifoster]

Can we just completely deprecate/remove everything related to grid parameters in this extension?

[Chocohead]

I think if it actually worked it could be useful to have, having all ore dictionary calls for a particular thing liking to the same place would be easier if it worked.

[elifoster]

That is a good point.

[retep998]

If I'm doing {{O|ingotCopper}} for example, do I want that to link to the Copper page or the Ingots page? Or maybe a dedicated Copper Ingot page that then links to those two other pages?

[Chocohead]

Logically you'd link to Copper, and then have a link to Ingots in Copper, as it's unlikely that people would rather see what an ingot is that copper if they've clicked on a copper ingot.

[retep998]

Personally I'd prefer there being a dedicated column for the link target rather than using grid parameters. Also if we're going to redirect all fooCopper to Copper then we'd probably need an API so that I could have a bot do all the modifications.

[elifoster]

I agree with the new column.

[elifoster]

@retep998 Should we do the link column thingy? It shouldn't be too difficult. And it'd be supported by the API so you could write a bot to do the modifications.

[elifoster]

Are we going anywhere with this?

[elifoster]

@retep998 getParamString is invoked in TilesheetHooks.OreDictOutput. That would explain why you cannot find the invocation in OreDict. I just tested it and it works. That said, it would probably be easier and more versatile for us to leave the grid parameters stuff how it is, and actually just start using it.

Also, it's important to note that these are not on a per tag basis. For example, if the Forestry copper ingot had link=Butt as the grid params, {{O|ingotCopper}} would have normal entries for all but Forestry's, which would link to the Butt page.

Grid parameters are input to the entry manager and dict importer exactly as you would put them in a {{Gc}} call, key=value|key1=value1.

I think it would be best for us to hold off on this, though, until after we decide if we are going to disambiguate everything (I think we should, for the record).

See also (in this order):

• https://github.com/FTB-Gamepedia/Tilesheets/blob/d60fd5eb1dca59f2f669192ce90609437fd663e7/Tilesheets.hooks.php#L163-L182

• OreDict/OreDict.body.php

  Lines 620 to 622 in 323bb14

  	public function getParamString() {
  	return OreDictHooks::BuildParamString($this->mItemParams);
  	}

• https://github.com/FTB-Gamepedia/OreDict/blob/master/OreDict.hooks.php#L231-L239
• https://github.com/FTB-Gamepedia/OreDict/blob/master/OreDict.hooks.php#L217-L222
• https://github.com/FTB-Gamepedia/OreDict/blob/master/OreDict.hooks.php#L195-L209