Jump to content

Recommended Posts

Development Document

The intent of the Index is to be one-part manual links and one-part auto-listed content. Anything listed above "All content" under any heading is manually listed to categorize the content under the heading by subject matter (this was asked for and desired by the NMS team). The auto-listed content is anything under "All content" is all the content that applies to the specific heading. So we're organizing the content two ways:

  • by heading (all content)
  • by subject under each heading (manually listed)

To accomplish this in the current format, a category was created to house all other categories specific to the use of the Index: NoMansSky Index
The subcats under it are specifically used for the Index and nothing else. I've been thinking of setting them all to hidden since they're strictly for internal use. Each of the subcats are named with the scheme: NMS-Index-Heading

  • NMS || indicate the cat is for NMS
  • Index || indicate the cat is solely used for the Index page
  • Heading || matches the heading on the Index page; each heading has its own Cat (currently 37 and will likely expand)

For example, if I created a new page about the player, I would add "NMS-Index-Player" to the page to have it auto-listed under "All content" for the Player heading. If I didn't want the content to show up under both a manually listed link and under "All content" then I simply don't include the subcat on the page. Since that page would be manually listed, it won't matter that it's not categized for the Index. They realize this method requires some manual work, but it's far better than what they had.

The goal is to simply have users add relevant sucats to their pages. Any manual work can be completed later since the page will at least be listed under the proper heading. I have instructions for them in their Wiki Reference about adding Cats and in their Category Reference to explain the Cats, themselves. That is how the Index is currently fashioned.
 

Overlapping Cats

There is potential for overlap in Cats between NoMansSky GameFile, NoMansSky Index, and NoMansSky Reference top-level Cats.

  • NoMansSky  GameFile || top-level that holds subcats for specifically identifying a page relating to a game file.
  • NoMansSky  Index || already covered above...
  • NoMansSky Reference || used as "general" Cats for content that doesn't fit anywhere else; say a Index heading didn't exist and it was a Tutorial so it could be put in NMS-Reference-General. Ideally this completely overlaps with NoMansSky Index and we can get rid of it.

Within each of these Cats the names of the subcats have a potent to be the same: "Global", for example.

Share this post


Link to post
Share on other sites

OK, so after examining the OP and some of the markup:

  • The potential overlapping cats like "Textures" should probably fall under a new Property called something like "NMS_Components" ... you name it ... some term that apples to all of those headings irrespective or whether or not they are Indexes, GameFiles, or References. So Property:NMS_Components will have page content analogous to Property:Game, where it is of type=Text and has strictly "allowed values". This allows us to circumvent the reused cats problem by calling the property value on the relevant pages. These pages could also have multiple cats corresponding to each parent cat, but we still would have the issue of 'shared' cats with different parents and a sort of cat loop or redundancy. Property resolves this nicely.
  • On these same pages, you can have Category:Index (or one of the other two). No need for "Textures" to be a subcat of Index, GameFile, or Reference cats. It is a property associated with a page and that page's cat.
  • Use a Template to generate pages that fall under Indexes, GameFiles, or References ... this makes assignment of Properties and Categories automatic based on criteria included in the Template (which can also use a Form so that users don't need to worry about calling the Template correctly ... same as ANY of our Templates, BTW ... see Form:GuideVersion, which uses a few Templates to build the ModList pages ... this is a very complex example, but you can see that any ModList page is just a bunch of Template calls built by the form ... same is true of Form:Mod mediated by Template:Mod)
  • Use Categories sparingly and avoid creating cats that will only have a single page. If you have 40 cats, each with a single page, then find the commonalities among the 40 and associate the 40 pages using < 40 cats ... probably < 10 or 40/3 (number of 'master' Index, GameFile, or Reference pages)

This is the 'index' page ... are there analogous 'GameFile' and 'Reference' pages? You could simplify if your framework houses all three using a similar structure or heirarchy. Then one Template/Form could be used to build out all of this for each 'new' "NMS Component".

Listing the components in pages like the NMS Index page linked in the OP can be achieved using queries just like you are doing now. Concepts can also be incorporated, depending on other stuff you may want to do (allow users do download lists in CSV or XLSX, or tabulate results ... all kinds of stuff (see Result Formats on SMW).

Share this post


Link to post
Share on other sites

Actually, it may be that NMSPage Template could be used for all of this along with Form:NMSPage maybe. or possibly something entirely new, but hopefully you see where I am going. There should be a way to largely automate everything you want to accomplish with a GUI form that ultimately does all of the work (create pages, assign cats and properties).

This is definitely stuff that we should be mocking up and testing in DEV, since it can get messy and may need major revisions possibly from the ground up over several iterations. No caching out there or users, so rebuilding data is not disruptive, and cleanup is a matter of restoring a DB backup if necessary.

In SMW, I think of Properties as 'Facts' in a relational DB star schema ... Categories are more like 'Dimensions' ... Concepts are dynamic cats defined by queries against Facts and/or Dimensions

Share this post


Link to post
Share on other sites

I'll work on putting together a wiki page for reference what the structure is now and what it needs to be converted to. It'll help me keep track as I probably won't be doing this rework immediately...but soon.

The reference page is here: https://stepmodifications.org/wiki/NoMansSky:Reference_Guides
It has an alphabetically list at the both so you can see I'm already using different output formats.

The GameStructure is here: https://stepmodifications.org/wiki/NoMansSky:Game_Structure
It is probably just going to stay a manual process for now. It could be automated, but would be a very complex structure.

I do see where you're going. Ideally, I'd like to have a form that creates new pages; adding the page structure automatically (PageTitle + menu + Cats). Relevant content for PageTitle could be input boxes and drop-down menus for Cats. This would be the easiest thing for users. I just haven't gotten to that point, yet. This would take care of getting the pages categorized by users.

Share this post


Link to post
Share on other sites

Sounds good ... still should consider using at least one NMS Property though. We may find use for more as we go (as I work with the data and understand more about what it means and how it's used)

Share this post


Link to post
Share on other sites
6 hours ago, TechAngel85 said:

@z929669
If I'm following along the right track, this seems to just be shifting maintenance from Cats to Properties. Still just as many properties vs cats:
https://stepmodifications.org/wiki/NoMansSky:IndexDevelopment

Is this looking correct so far?

Yes, essentially the same principle as Cats, but Properties allow values and also allow you to share Property values across cats, subcats and sub-subcats. Also, don't forget that you can use combinations of Properties, Cats, and other Concepts in Concepts (dynamic cats) ... or a Concept can be based upon any single of these. I can't think of a use case offhand, but maybe you will see the value. Read up on when to use Cats. Properties and Concepts to get ideas.

It could be useful to set up Cats or Concepts for Reference and Tutorials, but you would know better with your understanding of how it all works together.

EDIT: The Properties you have listed are actually "Allowed Values" for the property, which I assume is NMS_Entity? That's fine, but I would drop the 'NMS_' prefix from each, since it's redundant and throttles them to NMS alone. Properties should be treated like Facts as in they are generic to anything (like a number). The specificity of the context is understood by how the data are used ... in your case, for NMS_Entity (which could also just be 'Entity' and used for any game).

Share this post


Link to post
Share on other sites
9 hours ago, z929669 said:

Yes, essentially the same principle as Cats, but Properties allow values and also allow you to share Property values across cats, subcats and sub-subcats. Also, don't forget that you can use combinations of Properties, Cats, and other Concepts in Concepts (dynamic cats) ... or a Concept can be based upon any single of these. I can't think of a use case offhand, but maybe you will see the value. Read up on when to use Cats. Properties and Concepts to get ideas.

It could be useful to set up Cats or Concepts for Reference and Tutorials, but you would know better with your understanding of how it all works together.

EDIT: The Properties you have listed are actually "Allowed Values" for the property, which I assume is NMS_Entity? That's fine, but I would drop the 'NMS_' prefix from each, since it's redundant and throttles them to NMS alone. Properties should be treated like Facts as in they are generic to anything (like a number). The specificity of the context is understood by how the data are used ... in your case, for NMS_Entity (which could also just be 'Entity' and used for any game).

Okay, I'm going to have to do some reading, I guess, because I'm not understanding what a property is if all of those are values for a property.

Share this post


Link to post
Share on other sites
29 minutes ago, TechAngel85 said:

Okay, I'm going to have to do some reading, I guess, because I'm not understanding what a property is if all of those are values for a property.

A property can hold any value of data type 'whatever', so numbers, text, page, etc. You simply assign the Property value like [[Entity::Textures]] on the page. There is also another way to assign the property silently using this format or using {{#set:Entity|Textures}} I think. Then that property and its value are associated with the page. You can examine our existing Properties and how they are used:

https://stepmodifications.org/wiki/Special:Properties

Share this post


Link to post
Share on other sites
2 hours ago, z929669 said:

A property can hold any value of data type 'whatever', so numbers, text, page, etc. You simply assign the Property value like [[Entity::Textures]] on the page. There is also another way to assign the property silently using this format or using {{#set:Entity|Textures}} I think. Then that property and its value are associated with the page. You can examine our existing Properties and how they are used:

https://stepmodifications.org/wiki/Special:Properties

So is what you're saying that the top-level Cats (like, NoMansSky Index, NoMansSky GameFile, etc) should be properties and then defined by the text that I currently have in the Property column on the Index conversion table? So...

  • [[GameFile::Global]]
  • [[Index::Global]]
  • [[Resources::Global]]

If so then we'll have both Cats and Properties that are mainly 1:1? Cats used for general categorization and Properties used for refining those Cats into specific lists?

Share this post


Link to post
Share on other sites
29 minutes ago, TechAngel85 said:

So is what you're saying that the top-level Cats (like, NoMansSky Index, NoMansSky GameFile, etc) should be properties and then defined by the text that I currently have in the Property column on the Index conversion table? So...

  • [[GameFile::Global]]
  • [[Index::Global]]
  • [[Resources::Global]]

If so then we'll have both Cats and Properties that are mainly 1:1? Cats used for general categorization and Properties used for refining those Cats into specific lists?

No ... not exactly. Let's work via the page you created. I will leave some comments there and we can come up with a strategy.

Nevermind, let's discuss here:

  • GameFiles seem to be folder names that house NMS game assets?
  • Please define the Index ... it seems like an arbitrary categorization of information (like at the end of a book)?
  • What are GameFile subcats you are proposing? How do they relate to GameFiles?
  • Could you define all proposed NMS Cats (GameFile, Index, Reference, Tutorial)? They each seem unrelated to one another (which is fine), but if there are relationships, we should identify them ... example: Are GameFiles, References, or Tutorials listed under Index? Do GameFiles have Tutorials? Are Tutorials a form of Reference? Just want to conceptualize the bigger picture.

Share this post


Link to post
Share on other sites
24 minutes ago, z929669 said:

No ... not exactly. Let's work via the page you created. I will leave some comments there and we can come up with a strategy.

Okay, but per the two questions you posted and are now gone:

  • GameFiles || content that covers an actual file of the game. So a page about camera globals files would be categorized as a GameFile, but also a "Global". Textures and meshes would be categorized as a GameFile, but also a texture or a mesh. Etc.
  • The Index is just that, yes the ending of a book. That is what they wanted, Lo2K said:
Quote

The point of an index is to sort thing [heading] alphabetically, not to sort group [all content] alphabeticaly. 
it was designed to make everyone looking at things in a non-modder way
like I want to tweak terrain, I look at the index at terrain and get pages for terrain generation

 

Share this post


Link to post
Share on other sites
25 minutes ago, z929669 said:

No ... not exactly. Let's work via the page you created. I will leave some comments there and we can come up with a strategy.

Nevermind, let's discuss here:

  • Could you define all proposed NMS Cats (GameFile, Index, Reference, Tutorial)? They each seem unrelated to one another (which is fine), but if there are relationships, we should identify them ... example: Are GameFiles, References, or Tutorials listed under Index? Do GameFiles have Tutorials? Are Tutorials a form of Reference? Just want to conceptualize the bigger picture.
  • Reference is just a general category to hold all references of a subject. So content about Global files may not cover a specific GameFile, or needs to be listed on the Index because it's been manually listed. Therefore, it's captured in just the Reference Cat.
  • Tutorials should be self explanatory. It holds all content that are tutorials (teaching you do to something).

All this has already been explained above, I think.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Similar Content

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.