Jump to content

Help Improve Pack Creation!


Recommended Posts

Thanks for your consideration :) Now that I have thought some more on it, maybe it helps if I try to illustrate what I have in mind in more practical terms with regards to the linkage between the ToC and the wiki interface for authors.

 

At the wiki interface (i.e. the edit with form screen) remove tabs 2, 3 and 4. Remove mod tables.

 

Below is a list of suggestions with new tabs to be created at the wiki interface for authors.

 

(Each tab corresponts to the number of the list below)

 

  • Pack Attributes
    • Remove required packs, compatible packs, required DLCs
    • Author(s): Names put in here should ideally result in a link to the user's profile at the forums.
    • Title: The title put in here should be aligned to the centre of the actual pack page, below the information box (which has author name, forum thread link etc.)
    • Description: The text put in here should not end up in the dark box at the top of the pack's actual page. Instead it should be centered under the information box. Also rename this field to brief summary and provide a note that it is best to do keep it short (like 3-5 lines or something).
  • Introduction
    • The section should, when filled in by the author, automatically result in the creation of ToC chapter 1.
    • The text and title of this section, just as any of the next sections, should be aligned at the left.
    • A default text block suffices (basically same as you have now in the tab 'pre-installation texts').
  • Required Tools
    • The section should, when filled in by the author, automatically result in the creation of ToC chapter 2.
    • Since the tools available are kind of set in stone, you could make a list of tools and make them selectable. Basically just like you can now select "Compatible packs" at the Attributes tab.
  • Pre-Installation Setup
    • The section should, when filled in by the author, automatically result in the creation of ToC chapter 3.
    • A default text block suffices
  • Mod Installation
    • The section should, when filled in by the author, automatically result in the creation of ToC chapter 4.
    • Each mod should have fields for name, description, author and version. These fields should be put out in proper format to the actual pack page.
    • Filling in the name field should automatically results in the creation of ToC chapter 4.1 or 4.1.x etc.
    • Each mod should have a blank text box, which the author can use to specify special instructions.
    • There should be a field for filling in the mod's nexus link.
    • At the actual pack page, clicking the mod's name at the page should result in opening a new window to the nexus mod page.
  • BOSS/LOOT Rules
    • The section should, when filled in by the author, automatically result in the creation of ToC chapter 5.
    • A table format would be ideal here.
    • Don't make it complex. Author can fill in table contents himself and also link to mods itself.
    • Imo it is really best to have all these rules in one place instead of each individual mod.
  • Compatibility
    • The section should, when filled in by the author, automatically result in the creation of ToC chapter 6
    • A default text block should suffice.
  • Conflict Resolution
    • The section should, when filled in by the author, automatically result in the creation of ToC chapter 7.
    • A default text block should suffice.
  • Merged ESPs (or name it Other Post-Installation instructions or something like that).
    • The section should, when filled in by the author, automatically result in the creation of ToC chapter 8.
    • A default text block should suffice.
  • Final Steps
    • This section should, when filled in by the author, automatically result in the creation of ToC chapter 9.
    • A default text block should suffice.
  • Changelog.
    • This section should, when filled in by the author, automatically result in the creation of ToC chapter 10.
    • A default text block should suffice.
  • Credits
    • This section should, when filled in by the author, automatically result in the creation of ToC chapter 10.
    • A default text block should suffice.

Hope this provides some more concrete ideas. I guess incorporating the ones I have about the mod section would be most work, but also most important :P

 

Oh yeah, did I mention to get rid of the mod tables? Get rid of them.  :;):

Edited by Nearox
Link to comment

I will take a look at all of this ... This page contains all of our consolidated ideas about the guides, mods and Packs from a SMW viewpoint and should be the hub for all proposals. In the meantime, see this page and consider all of the elements and ramifications. mod pages are necessary in order to maintain the Semantic attributes that drive the STEP Guide and also any forthcoming Pack motif that we settle on.

 

@ Nearox and Smile

Thanks for the great suggestions. S4n and I can consider all of this stuff and mock something up once we are finished with the RL stuff consuming our time lately. I cannot provide any ETA, but it would be most helpful if we could get others informed about the mechanics of Semantic Mediawiki and tentatively set up some regular times to meet and discuss in real time via Mumble.

Link to comment

Interesting! Personally I do agree with Nearox that mod tables get crammed up really fast if you want to add some information. What I sometimes wished for was a table for some advanced info/instructions in case a user want's to know more about what's going on or how to do a custom install (e.g. Requiem with killcam).

 

Another brainstormed idea: I do not know how many packs actually do overwrite STEP mods or require uninstallation of some mods (I'm hoping for a parallax pack ::): ). For the Requiem pack having icons indicating the conflict would be nice. Maybe clickable with a quick info on what is meant by e.g. texture conflict or esp conflict and what consequences can be expected. For texture conflicts MO icons could be used so people recognize it.

Link to comment

Just one thing I noticed on https://wiki.step-project.com/Pack:Proposal - I tried to fix it myself but I don't have the permissions - the link below towards the bottom:

You can see a list of example Packs created by users here: https://wiki.step-pro.../Category:Packs

 

is pointing to the exact URL it's showing (i.e. collapsed, with the ...) instead of https://wiki.step-project.com/Category:Packs

Edited by Lauren
Link to comment

Maybe the guide could have a section with a final LOAD ORDER post.

 

It would be great for BOSS users to check their LO.

 

I started playing with STEP&LOOT but it sometimes with the ungroup esps it was difficult to check the proper order or to make custom conflicts resolutions.

For now I still find BOSS&BUM/bossGUI easier to go along as used in SRLE

Link to comment

Great suggestions so far.

 

Main thing I will comment on right now...

 

Z touched on this, but Mod pages are necessary. They are what binds the semantics of everything, for both STEP and packs. This is the core of enforcing consistency and interconnectedness of data. Pack structure definitely needs some love in this department.

Link to comment

Great suggestions so far.Main thing I will comment on right now...Z touched on this, but Mod pages are necessary. They are what binds the semantics of everything, for both STEP and packs. This is the core of enforcing consistency and interconnectedness of data. Pack structure definitely needs some love in this department.

I agree that they should retain everything they currently have but there should be some additions the form. With packs we move from a vanilla type site to a almost anything site. We need mod pages move in that direction, but keep their ability to service the guide.
Link to comment

I don't know... In my experience it is very tedious and, from a pack author's point of way, unnecessary to add a seperate wiki entry for every mod added to the pack. Moreover mod tables also really limit your options with regards to layout. 

 

S4N I understand the need for consistency, but that is easily achieved by making packs in SRLE format... Unless you are speaking of a different kind of consistency. I don't think it benefits the packs if they are limited to mod tables for sake of having a similar look to STEP Core. We tried pretty hard with REGS, it was in mod table format for a month or so, but it just became unworkable after a while. After switching to SRLE formatting everything became a lot easier, and the feedback of REGS users at the time was exclusively positive about that change. 

 

As for intercoonectedness of data, what are you referring to? Even if 2 packs use the same mod, or if a pack uses the same mod as STEP but in different ways, having them all refer to the same mod wiki entry, while technically being interconnected, what is the benefit of that? Instructions are made on the pack page anyways, and I don't think it would be a good idea to have every pack author write the instructions on the mod wiki page as that would clutter them up real fast. 

Edited by Nearox
Link to comment

If you explain it like that, then yes that is what I meant with my previous posts. If the author can fill in a kind of 'mod table form' which, when viewed at the pack page by the user, ends up looking a bit like SRLE, that would be great! Obviosuly doesn't have to look exactly like SRLE, but I personally find the vertical order of information to be very useful.

 

Best thing even would be if the form to fill in the table for the author has fields for not the basics but also more advanced instructions. That way every pack could look more consistent. There should, imho, be form fields + tickable boxes (so that author can enable/disable a field at discretion) per mod for: 

 

Description: 

Author: 

Version:

Files to download: (e.g. main + update + miscalleneous, to be filled in manually by author)

TES5Edit cleaning required: (if possible, make it so that automatically a link is generate to one of the cleaning guides at the wiki)

Bash tagging required:

DDSopt required:

Mod merging required:

Special install instructions: (e.g. do not install etc.)

 

Optionally a field for BOSS/LOOT rules but they could also be provided in a handy overview at the end of a pack. 

 

Again, just some ideas, happy to contribute and happy to see you guys are taking pack author's opinion into account!

Link to comment

If you explain it like that, then yes that is what I meant with my previous posts. If the author can fill in a kind of 'mod table form' which, when viewed at the pack page by the user, ends up looking a bit like SRLE, that would be great! Obviosuly doesn't have to look exactly like SRLE, but I personally find the vertical order of information to be very useful.

 

Best thing even would be if the form to fill in the table for the author has fields for not the basics but also more advanced instructions. That way every pack could look more consistent. There should, imho, be form fields + tickable boxes (so that author can enable/disable a field at discretion) per mod for: 

 

Description: 

Author: 

Version:

Other Game Equivalent: (This is mostly for me and Kelmych)

Requirements: (SKSE, SkyUI...)

Files to download: (e.g. main + update + miscalleneous, to be filled in manually by author)

TES5Edit cleaning required: (if possible, make it so that automatically a link is generate to one of the cleaning guides at the wiki)

Bash tagging required:

DDSopt required:

Mod merging required:

Special install instructions: (e.g. do not install etc.)

Note:

Description:

Optionally a field for BOSS/LOOT rules but they could also be provided in a handy overview at the end of a pack. 

 

Again, just some ideas, happy to contribute and happy to see you guys are taking pack author's opinion into account!

Cleaning, tagging, and mod merging can just go under one big installation section. I've used that top down version for a while and find it easy to work with, but it might be best a template.

{{Template|Mod Name*field 1*field 2*field 3....closing stuff}}

I would then have to switch everything to a template, but it would make less work for others in the future.

Link to comment
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.