Jump to content

Help Improve Pack Creation!


Recommended Posts

Posted

Like others, I've been hoping for a while to have some templates that can handle what a pack needs. Like s4n, it seem to me that having the basic information on a mod page is useful so a pack author can potentially use some information that others entered, plus there would be consistency. Even for Fallout mods we could use the same mod templates, but by having the game(s) as one of the fields we could have the tables and lists of mods be separate for different games when that makes sense (we can keep the current Skyrim mod pages in effect as they are now) and have other lists for different games. What I don't know how to best handle is installation instructions and other information about a mod that can be very pack-centric but several packs might want the same instructions. From the discussion above it sounds like templates could potentially be made for this, which would be great.

Posted (edited)

Rant time, ignore this if you wish but I think there is some good info:

 

The common problem for me was that it was difficult because of the following:

To figure out if something actually existed whether it being a table/ template/ coloring I had to bug all of the staff and admins.

Finding a good layout... Mine is still terrible, I'm most proud of the UI portion though

Keeping all the text consistent. Might not sound like and issue but I have a lot of this.

In one part it's press ok; click ok; Click: ok; click ''ok''; click [ok]; and now there is this [ok]

I had open the edit on people's pages to figure out a <br> works or color code.

There can be difficulties in formatting... My toc now has spaces because of the box... I have no idea how to remove it.

The toc gets in the way.

 

Most of these answer exist but are really difficult to find. The search function is the most useless thing. It really is. The mediawiki has good info but I can't seem to find the page that had most of the functions. Double you has good info but I can't remember the page. I remember almost all the staff had something interesting on their user pag but there wasn't a link from the root so I can't navigate there. That's why on my root page I have every link I have made. This was literally for my benefit but is pretty useful.

 

I'm not even done ranting on but typing on a phone sucks.

Edited by hishutup
Posted

I've already been working on something like that: https://wiki.step-project.com/User:DoubleYou/testpack/pack

Look at you getting the hang of wiki coding...Z would be so proud! :lol:

 

That looks good; however, I'd suggest using h1's instead of h2's for the main headers...unless you've done that for a specific reason. Especially, if we build in the ability to add a custom CSS file so users can change the colors and formatting of elements if they desire.

 

The forms will make this easier for users to fill in since all they'll have to do is fill in the text fields on the form, click done and the form spits the code out for them.

Posted (edited)

I think title should be centred imho. And given a different color, bigger size and maybe also different font. 

 

After title, everything aligned to left.

Edited by Nearox
Posted

Rant time, ignore this if you wish but I think there is some good info:The toc gets in the way.

Last night s4n implemented a {{TOC limit|n}} template. You can combine it with {{TOC right (or left)}}-> {{TOC right|limit=3}}. That will stop all headings more than two sections deep from being displayed. It shortens it significantly.

 

I think title should be centred imho. And given a different color, bigger size and maybe also different font. 

 

After title, everything aligned to left.

The problem is again the TOC and that the mod names would end up being the same size as the section names if h1, h2, h3 are used.

Posted

Sorry for any confusion. I'm not referring to any need to have mod tables. The structure can change to whatever is deemed best suited for packs, and if mod tables are not cutting it, then they need to go.

 

Consistency and interconnectedness:

 

Mod data is all managed via Semantics. That means it is all available to anything on the Wiki via semantic properties. You are correct that pack specific instructions/data do not belong on the Mod pages, but the Mod pages provide semantic data such as...

  • Link to a thread on the forum for discussion on the mod
  • Download URL (mod project page)
  • Resource usage
  • DLC requirements
  • Section (Ultimately needs to be non-STEP specific and geared towards the primary category a mod should be associated with)

All of this information keeps consistency by utilizing a single repository of information about a Mod that everyone shares. This eliminates discrepancies by providing that single source of information. If a download URL needs updating, change it once, and everything on the Wiki that references it is automatically updated. That is also how everything is interconnected.

 

Whatever the resulting design of a pack layout ends up being, the above information when implemented within templates reduces the editing burden across all pack pages. All while helping to ensure that basic mod information represented everywhere is accurate.

I stand by this post 100%. Remember, we have been thinking about this stuff for nearly three years, so all would do well to study the Data Dictionary of our Semantic Mediawiki implementation of Mods and Packs in particular.

 

Please discuss or add input on the above-linked DD Talk page

 

All Pack-Mod-centric information needs to be consolidated on the page I linked in order to be implemented (so that we all know what is going on and why). A forum is just too convoluted for consolidating ideas. Let's get all of the good ideas onto that Talk page and revise the Packs tab in particular as necessary. Even if you just want to add links to posts over here on the forums ... THAT IS FINE. Just please help us to consolidate on the wiki (I am way too immersed in RL to take that on myself ATM).

 

At some point, I will tidy up the wiki page and consolidate everything neatly.

 

In short:

  • Mod Template (i.e., mod pages) should contain all common, static mod-specific info about a given mod. These pages are absolutely necessary to driving the wiki for just about any implementation that is desireable. No getting around creating mod pages, so bite the bullet and get them created as necessary. They will NEVER go away :no:
  • Pack Template should contain all common, static pack-specific info about a given pack. Like mods, pack pages will never go away, but we can drastically change them to suit the needs of Pack users
  • Guide Templates bring Mod/pack info together, and we could have more than one type of template even to produce whatever guide style is wanted.
  • Versioning or tracking of other changing information associated with specific Mods/Packs/Guides (conflict res, instructions, version #s, patches, etc.) will need to be handled as Semantic sub-objects or some other method that is scaleable and practically maintainable.

Anyone interested in helping out needs to learn about Semantic Mediawiki. A prerequisite is a decent understanding of wiki markup in general as well as template creation and maintenance.

 

Lastly, anyone interested in helping with development of the SMW infrastructure as actual devs or just those willing to propose viable ideas and contribute in an organized way (this is you Nearox and Smile, et al.), please PM admin to get access to the DD forum thread and Pack implementation forum thread and get ready to read a lot of historic info.

Posted

Look at you getting the hang of wiki coding...Z would be so proud! :lol:

 

That looks good; however, I'd suggest using h1's instead of h2's for the main headers...unless you've done that for a specific reason. Especially, if we build in the ability to add a custom CSS file so users can change the colors and formatting of elements if they desire.

 

The forms will make this easier for users to fill in since all they'll have to do is fill in the text fields on the form, click done and the form spits the code out for them.

I use h2 because it is the correct format, despite whether or not you want it a different size. h1 is page name level. See the following links:

https://www.mediawiki.org/wiki/Help:Formatting

https://www.mediawiki.org/wiki/Help_talk:Formatting#Level_1

https://meta.wikimedia.org/wiki/Help:Section#Creation_and_numbering_of_sections

 

Size can be changed via styles, and I'll see about making that an option. Colors can easily be implemented in similar fashion.

I'd use h5 and I'd put the title in a format where it is the link, bigger is not better. [ ]

 

Also, align left, it just keeps everything orderly.

I think I'll make those as options.

Posted

Is there a way for the toc syntax to allow limiting the length of lines included in the TOC, or is it already there? I have some long mod names, which leads to some very wide TOCs. I'd like to be able to truncate the line after n characters or inches/cm when used in a TOC.

Posted

That is for limiting the subsection depth, but Kelmych wants a character limit, so like 25 characters for some of the header names. TOC limit was what I asked for two days ago and s4n stuck it in for me. It is helpful for length, but then width can sometimes be a problem. Just look at Neo's conflict resolution page.

Posted

There is no mechanism for adding a character limit. About the best that can be done that I can think of would be to force the TOC block to be at most X characters in width, in which case long headings will wrap within the block.

Posted

This is possible with CSS. Give the ToC a defined width and add in a nowrap and hide the overflow:

div {    white-space: nowrap;    width: 400px;    overflow: hidden;}

In this example the box is 400px wide. The "white-space: nowrap" says to not wrap any text to the next line. The "overflow: hidden" says to hide any text that is over the 400px width.

 

 

 

Instead of this:

 

Text text text text text text text text

text text text text text text text text

text text text

 

 

You get this:

Text text texttext text texttext text te

 

It just simply cuts off.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.