SmartlyDressedGames / Unturned-Docs

Documentation for Unturned's modding features.
134 stars 49 forks source link

PlayerSpotLightConfig properties and ENPCHoliday #271

Closed MoltonMontro closed 1 year ago

MoltonMontro commented 1 year ago

Adds the SpotLight_ properties now available to tacticals/glasses.

Maybe it would make more sense for Enums and Dictionaries to have their own doc (e.g., in the data/ folder) to reduce the number of times the same info is copy-pasted? Unsure.

For now, the info is just identical across both the tactical-asset and glasses-asset docs, and whenever melee-asset is documented it'll be the same there.

SDGNelson commented 1 year ago

Maybe if the same type is mentioned in more than two docs we create a new page like you suggested? Enums, structs, and classes all being candidates for this.

I appreciate that I think you referred to them as dictionaries because I documented the dat format with dictionaries and lists. The reason I did this was the DatDictionary type is mostly a wrapper for a regular c# Dictionary, and DatList is mostly a wrapper for List.

For the asset documentation however I think we should keep the existing wording of referring to the parsed values as "Properties", for example "Spot Light Properties". The spot light properties are still using the older style of SpotLight_ prefix, whereas with the new scopes I documented DistanceMarkers with "list of dictionaries" as the type and Distance Marker Properties below.

What do you think? I'm not sure this is clearest or not. From the point of view of someone reading the docs hopefully we can make it clear how to set it up without necessarily even needing to refer to existing assets or the code. In particular:

  1. Avoiding confusion about whether the dictionary { } sub-object should be used vs prefixing like with item blueprints.
  2. That reading List always means [ ] and dictionary always means { }?
MoltonMontro commented 1 year ago

Hmm.

I agree that being consistent with how certain terms appear is good. Dictionary/object { }, vs. List/array [ ], vs. whatever else. In this case, do you think calling it a Struct in a new page (for the type) and on the assets that can use this Struct would make the most sense?

And then since it'd have its own page, we would list the properties on that new page – but the asset pages would just link to the type's page rather than listing each property as well.

Of course, there's some pages that currently exist and would make sense to move around too. Actions, Blueprints, Conditions, and Rewards come to mind as some fairly meaty classes that are all kept in the Assets folder right now. And then there's a fair number of enums used on multiple pages, like ENPCHoliday.

Would it make more sense for the actual name to be used (i.e., PlayerSpotLightConfig) instead of SpotLight?

MoltonMontro commented 1 year ago

Above commit contains the changes/thoughts described above.

SDGNelson commented 1 year ago

Your suggestions sound good to me, and thanks these changes! I think it is probably good for the documentation and code to match closely (e.g. using the type names).