Skip to content
This repository has been archived by the owner on Aug 19, 2019. It is now read-only.

Page Format #4

Open
DeltaDizzy opened this issue Jul 11, 2019 · 10 comments
Open

Page Format #4

DeltaDizzy opened this issue Jul 11, 2019 · 10 comments
Assignees
Labels
help wanted Extra attention is needed

Comments

@DeltaDizzy
Copy link
Member

We also need to decide how we are going to arrange the wiki pages. The two competing options are the Example/Explanation format (used in the KopernicusExamples pages) and the Table format (used in several of the core Kopernicus pages).

@DeltaDizzy DeltaDizzy pinned this issue Jul 11, 2019
@democat3457
Copy link
Member

democat3457 commented Jul 11, 2019

I think the following format would work as a meld between the two::
Description
This is a sample node that samples and is a subnode of Samples { }.

Example (although example could also go at the end)

Samples
{
  Sample 
  {
    name = Sample1
  }
}

Subnodes

  • Sample3 { }
  • Banana { }
  • LandClasses/Class { }

Table

Property Format Description
name String The name of the Sample.
enabled Boolean Whether this should be enabled.

@democat3457 democat3457 added the help wanted Extra attention is needed label Jul 11, 2019
@DeltaDizzy
Copy link
Member Author

Also in relation to this, we should decide on some formatting standards, such as tabs vs spaces/how many we decide to use, spaces before and after comments, and the like.

@DeltaDizzy DeltaDizzy mentioned this issue Jul 11, 2019
@democat3457
Copy link
Member

I think a tab should equal 2 spaces in the examples, (so use spaces, not tabs) and when referencing nodes, use Node(space){(space)}

@democat3457
Copy link
Member

And what do you mean by comments? In-line comments?

@DeltaDizzy
Copy link
Member Author

key = value // this is what that means

@democat3457
Copy link
Member

democat3457 commented Jul 11, 2019

Oh. I think comments should be styled before the line, like this:

// execute the sample
Sample
{
  // the name of the component
  name = hi // no comments like this
  
  // the class
  Class
  {
    // the name of the class
    name = hi2
  }
}

But that's just me.

@DeltaDizzy
Copy link
Member Author

Well that means there can be ambiguity over whether a comment is for the line below or above it. We could separate values like you show there, but for large numbers of values in a row, that could become unwieldy.

@democat3457
Copy link
Member

true... then, instead of putting comments before key/value pairs, put the comments on the same line but keep node comments the same, but with new lines after the node, i.e.,

// node comment
Sample
{
  // Class1
  Class
  {
    name = Class1 // the name of the class
    number = 18005555555 // the destination phone number
  }

  // Class2
  Class
  {
    name = Class2
    disconnected = true // whether the call should be dropped
  }
}

@DeltaDizzy
Copy link
Member Author

Yeah I can do that.

@democat3457 democat3457 unpinned this issue Jul 12, 2019
@democat3457 democat3457 pinned this issue Jul 12, 2019
@DeltaDizzy DeltaDizzy unpinned this issue Jul 20, 2019
@democat3457
Copy link
Member

We need to fix the page formats on some pages. I've already added a "Page Formats" section to the README (you can move it elsewhere if you'd like), so now we have to fix the page formats on existing pages, such as the KEX pages. A list is below; check these off as you complete them.

  • Comet Tails
  • Emissive FX
  • EVA Footprints
  • Procedural Gas Giants
  • Reentry Effects
  • VHDeformity
  • VHM16
  • Wormholes

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants