WP - Introduce Cargo to Maps

From Squad Wiki
Jump to: navigation, search
This page is a Wiki Project.



Aim of this Wiki Project[edit | edit source]

We have chosen the map pages as our first section of the wiki to be upgraded to Cargo. Not only are almost all of the map pages outdated and terribly inconsistent, they are also one of the most important areas for players and server admins to look at.

When we introduce Cargo, we can add map data and vehicle asset data into Cargo table and reuse this data in any way and form on different places on the wiki while everything is neatly managed in one place only. This gives us almost unlimited possibilies to display this data in the multiple views in the best possible ways for our wiki readers.

Background information[edit | edit source]

Related pages[edit | edit source]

How other wikis do it[edit | edit source]

When creating something new, it's useful to look at other Gamepedia wikis first. Here are some useful wikis we found:

Project team[edit | edit source]

Progress reports[edit | edit source]

  • 2020-07-02: We finally did it! The Cargo tables are filled with the latest B20.1 data and we converted all map pages to the Lua script. Cargo is live now! Read all about it here Squad Wiki Editorial/Cargo Maintenance.
  • 2020-06-08: Shanomac and Usgu held the third project meeting. We are making great progress.
  • 2019-12-06: Shanomac joined the project team and we had our second meeting.
  • 2019-03-29: Rosarch and Usgu held a kickoff meeting on 2019-03-04. Progress is slow, there is a lot to learn and cover and we only have limited time to work on it regularly. Below backlog is outdated as the Squad Wiki Editorial has started to use Trello for all our task management.

Backlog[edit | edit source]

Inspired by this forum post.

Please note that most of below text is outdated - the project team is now working with a Trello board and design documents in Google Docs.

  1. Project team kickoff in the Squad Wiki Editorial. How will we work on this project? What needs doing, in which order? Who will do what? How do we make each step transparent to everyone? Write up our conclusions on this wiki page. This project is the biggest project we ever did on the Squad Wiki and it's close to a real software development project, so don't underestimate the complexity, effort and risks of things doing wrong (no pressure!).
  2. List all pages on the wiki that will use the map and vehicle asset information and specific how it will work and why it will be useful/necessary there. With Cargo, we can reuse that data anywhere on the wiki. But we will only do it, where it makes sense and creates value for our readers. We also have to decide on which pages we enter the data and which pages just display it.
  3. Make a final decision what data we want to display on the wiki. This needs careful consideration. We should only show what is really needed as all data needs to be maintained in the long-term future with each Squad update. We also have to think how we get to this data. We also need to decide on the data types we will be using for the data (e.g. numerical, string, wiki page, etc - see Gamepedia Help).
  4. Design layouts for all different target pages. First brainstorm different designs, review and improve them, then finally select the best one.
  5. Create templates and Lua scripts for data entry and data display.
  6. Collect all current map data and vehicle assets from all maps into one spreadsheet for v12.2 (careful, some data is messed up in the Squad SDK, so we have to double-check on a dedicated server). We need this to get a full picture of the size and range of data we need to accommodate before we can design the layouts. For example, how many different vehicles do we have on the maps (this will determine the length of the vehicle asset table)? How many maps have neutral vehicles (this will mean we need three instead of only two columsn for the vehicle asset tables)?
  7. Collect all images we need (mostly: hi-res map images, map layer images). We have to decide on the main proporties and characteristics of these images before starting the processes of creating them all. We also have to decide on a file naming convension and also categorize the media files correctly before uploading them.
  8. Implement the templates and scripts into the target wiki pages.
  9. Enter all data into Cargo.
  10. Wrap-up
    1. Delete all prototype and test pages (unless it's useful learning material for the future)
    2. Record our general learning insights with Cargo/Lua either on Learning Cargo, Learning Scribunto or in this forum post. Including: lessons learned, the biggest mistakes we did and how we do it better next time. This is the first but not the last Cargo implementation on the Squad Wiki. We want to build on our insights and make the next implementation even faster and better.

Design[edit | edit source]

Please note that most of below text is outdated - the project team is now working with a Trello board and design documents in Google Docs.

General[edit | edit source]

  • We will not focus on automation of the data importing process - this will be part of a future project. In this project, we will do most or all of the data management manually. We have to get it all working first before we can think about automation.

Target pages[edit | edit source]

The following wiki pages will be converted to Cargo. Many of these pages will just display Cargo data, but some pages will be used for data entry. Some displayed Cargo data will provide links to other pages - this is considered "functionality".

  • Maps (display)
    • (list all maps)
  • (list data entry pages)
  • (list secondary pages that will utilize the vehilce asset data)

Maps[edit | edit source]

Map Layers[edit | edit source]

Vehicle assets[edit | edit source]

Facts that need to be considered for vehicle assets:

  • Vehicle respawn times are standardized - the same on all maps, layers and game-modes. Only exceptions:
    • One-life vehicles (not respawning after being destroyed = hence, there would be NO respawn timer)
    • Vehicles with delayed spawns (initial spawn delayed, but spawn timer is standard again after destruction)
  • On some map layers, there neutral vehicles that are not associated with either team and can be used by either team - hence, we probably need 3 tables (vehicle assets for team A, for team B, for neutral vehicles)

Data Management[edit | edit source]

Somehow, we have to get the data into the Cargo tables; also, we have to maintain the data (modify for updates or corrections, delete outdated data).

We have several options to do this.

A) External Data Management, script-based import[edit | edit source]

Description: We completely manage the data outside the wiki. Via scripts the data is imported/reimported to the wiki as needed.

Options for external tools:

  • For data storage:
    • x
  • For scripting:
    • Phyton
    • Lua (wiki-side)

Benefits:

  • The external tool is more efficient at managing data
  • Importing/update data is done automatically via scripts (no need to manually enter data into the wiki - we save on labor and errors)
  • We can directly use data exported from the Unreal Engine

Downsides:

  • Additional tools and technology need to be created, managed and operated
  • Public wiki editors cannot easily modify data nor have easy access to these tools

External examples:

B.1) Manual template-based data management, final presentation[edit | edit source]

Description: We use Cargo templates to enter, manage and display the data.

Benefits:

  • This is the simplest solution.
  • Public editors can modify the templates and the data.

Downsides:

  • All data has to be entered manually, even if we somehow where able to export the data from the SDK.
  • There are limitation on what and how we can display data.

B.2) Manual template-based data management, separate presentation[edit | edit source]

Description: We use Cargo templates only to enter and manage data; for displaying the data, we use Lua scripts.

Benefits:

  • We can display and combine Cargo data in any way we want - we have full flexibility.

Downsides:

  • We have to create separate pages for data entry/maintanance.
  • We have to program Lua scripts for displaying the data (additional effort for creating and maintaining those scripts).

C) Mixed mode (both manual template-based data management and script-based import)[edit | edit source]

Description: Use A+B together at the same time.

Conclusions[edit | edit source]

Many options, each with benefits and downsides.

Interim thoughts (not yet final conclusions):

  • We can go in phases. The first phase being the simplest and easiest implementation, probably mostly manual, without external scripts. A future phase could add more functionality and automation.

Conclusions

  • x

Details[edit | edit source]

(will be added soon)