15 replies to this topic

[dgelessus]

The master of procrastination has finally finished the Lua implementation of the Item infobox after over a year of hard work *ahem*. While at it I've also made various other changes that seemed reasonable to me, some of which would be relatively noticeable for other editors, so I thought I'd get some feedback first instead of making them global without discussion. Specifically these are the most noticeable changes:

• The order of appearance of practically all rows is different. I tried to order them in a meaningful way, first general information that should appear for all blocks and items (name, source mod, stackability), then block-only info, then the various mod-specific and obscurely named rows. Might try adding some kind of section headers to make that more clear.
• Some of the parameters have shorter names, which are more convenient to type (IMHO). For example "luminance" is now "light". I've also tried to make some names less misleading, e. g. "gravity" instead of "physics", because physics could also be referring to whether the block is solid.
• The stack parameter now accepts a number alone in addition to arbitrary text. Numbers will be reformatted to look like the current style, such as Yes (64) or No (1), which should hopefully help clarify some of the inconsistencies. (should there be a space after the Yes/No? should there even be a number for unstackable items?
• The img and imgwidth parameters are available here now as well, replacing the old image parameter that was little more than centered free text.
• Same for the rows parameter instead of the less flexible extraN and extrainfoN parameters.

And apparently I'm still missing some of the new parameters, so I'll have to add those as well.

[timrem]

Looks good to me.

 

should there even be a number for unstackable items?

No, it should just be "Stackable: No". Yes to a space in "Yes (10)".

[VanDerProtofsky]

Very nice work!

 

I have been curious about this; what is the purpose of the "Name" field? It seems like an unneeded redundancy with the Infobox title. I see this also in the current infoboxes in use and feel it should be removed for the Lua upgrade.

[ostPavel]

Infobox's title uses the page's name. E.g. you have "Quartz Block (Applied Energistics 2)". You can then set "|name=Quartz Block" in the infobox itself because the block is named like that in game.

 

You can see it perfectly in dgelessus's example. Long and complicated page name - and then you can set |name=Test to make things looks prettier.

[dgelessus]

@ost, I believe he's referring to the presence of a separate Name field in the infobox, not the name parameter.

I have been curious about this; what is the purpose of the "Name" field? It seems like an unneeded redundancy with the Infobox title. I see this also in the current infoboxes in use and feel it should be removed for the Lua upgrade.

That would be easy to do for sure, because the Name field is part of the base infobox That was actually sort of discussed back when I started working on the infobox rewrite, at that point I went for keeping the Name field and making it always appear for consistency. I'd be fine with removing it now though.

[ostPavel]

Oh. :<

[RZR0]

It's looking great, nice job! Should take a sizable load off of the parser

[dgelessus]

If you're interested, the exact numbers for the current Lua version are as follows:

CPU time usage 0.104 seconds

Real time usage 0.190 seconds

Preprocessor visited node count 346/1000000

Preprocessor generated node count 1913/1000000

Post-expand include size 6348/2097152 bytes

Template argument size 321/2097152 bytes

Highest expansion depth 8/40

Expensive parser function count 1/100

Lua time usage 0.028/7.000 seconds

Lua memory usage 638 KB/50 MB

 

And for the current MediaWiki version:

CPU time usage 0.184 seconds

Real time usage 0.373 seconds

Preprocessor visited node count 414/1000000

Preprocessor generated node count 2885/1000000

Post-expand include size 4595/2097152 bytes

Template argument size 424/2097152 bytes

Highest expansion depth 8/40

Expensive parser function count 6/100

Lua time usage 0.007/7.000 seconds

Lua memory usage 479 KB/50 MB

[RZR0]

Now if we could do this for the navs, all of our problems would be solved xD

[dgelessus]

It has been done, Template:Item is now running on the Lua base and seems to be doing fine so far. However this box is much more complex and widely used than the two previously ported ones, so I expect there to be some issues that will crop up sooner or later...

[dgelessus]

(Double post - I checked, and edits do not mark the thread as having new messages.)

 

Unfortunately it seems that my original concept of separating bare Lua and MediaWiki-dependent code doesn't work well with the modular infobox approach. Originally I was going to have sub-infoboxes extend only upon the pure Lua part, but that would of course mean that everything added during the MediaWiki stage would be lost and had to be copy-pasted. Same for any default values coming from template (not module) code. Now the only reasonable option (I don't consider tons of copy-paste one) would be to have everything require a working MediaWiki frame from the start. I would have preferred not to do it, partially because it makes testing using the interactive console a pain, but I don't think there's much of a choice here.

Good news is that the transition can be done seamlessly, which means that the templates should never be "down" or cause errors during the process.

[felinoel]

(Double post - I checked, and edits do not mark the thread as having new messages.)

That is why I copy the edited post, make a new post, and delete the original post when I make edits like that so I won't have to double post.

[RZR0]

Can it be that Source Mods is broken? http://ftbwiki.org/Diamond_Chest

[felinoel]

Can it be that Source Mods is broken? http://ftbwiki.org/Diamond_Chest

Fixed it.

 

http://ftbwiki.org/i...08&oldid=131528

[dgelessus]

Huh, I thought I removed additional brackets before parsing the mod name. Looks like I forgot to add that in during the Lua transition.

 

PS:

I tried to add a gsub to Module:ModNames to fix this, but for some reason it isn't replacing the characters I tell it to. I tested the pattern in a Lua shell and there it seems to work as expected.

[felinoel]

Huh, I thought I removed additional brackets before parsing the mod name. Looks like I forgot to add that in during the Lua transition.

 

PS:

I tried to add a gsub to Module:ModNames to fix this, but for some reason it isn't replacing the characters I tell it to. I tested the pattern in a Lua shell and there it seems to work as expected.

I see this issue on many pages.