signal-k/sytizen

Citizen Science (Sci-tizen) visualisation in the Unity.com engine

sytizen's Issues

DeepNote Initialisation for LightKurve plots -> [HDASH-4]

Deepnote doc

TIC = 'TIC 284475976' # TIC Star ID
sector_data = lk.search_lightcurve(TIC, author = 'SPOC', sector = 23) # can remove each arg if needed
sector_data
lc = sector_data.download()
lc.plot()

select
    stars.star_id,
    stars.author,
from
    stars-sailors

Then:

retention.loc[retention.Week == 4][['variant','Retention']].reset_index(drop=True)

[STA-34] Enable IPFS Uploading to Nodes, contracts or postgres

Use Flask + the client to allow users to upload their data in an organised structure to IPFS, where it can then be pulled in via contracts or from Supabase/postgres.

Game frontend

Linear info:
https://linear.app/star-sailors/issue/STA-33/enable-ipfs-uploading-to-nodes-contracts-or-postgres
Id: STA-33

_STA-34

🏳️‍🌈🗝 ↣ Supabase CRUD Frontend component

Allow users to edit and augment their profiles on the frontend in the current iteration of the dashboard.

Claim anomalies & have posts be generated automatically

There should be enough information (images/deepnote-lightkurve assets) for the user to make an informed decision based on our "house rules" for this demo. Duplicate the gallery feature in pages/journal/gallery.tsx to set up assets (which will be manually uploaded for now) and displayed in the planet's card. Also add the postformcard and have an automated post that tags the planet and is then displayed on that planet's card.

Linear info:
https://linear.app/star-sailors/issue/STA-36/claim-anomalies-and-have-posts-be-generated-automatically
Id: STA-36

👾🔬 ↣ Generator (Ansible) + Evolution mechanism for NFTs in [SCD-8]

To test out a crafting/evolution system, I've begun work on a Pokemon-type evolution smart contract. Burning two of the same ERC-1155 IDs (e.g. a base-class spaceship) creates a new NFT (e.g. a second-tier spaceship) using the following data flow:

• msg.sender holds contract.tokenId = 0 * 2
• Contract _burns contract.tokenID = 0 * 2
• Contract _mints contract.tokenId = 1 & sends it to msg.sender

This can be used for crafting items, transferring items, etc

Let's try and get user NFT metadata working inside the frontend, add a crafting feature (triggering _burn & _mint functions of deployed contract using Moralis Unity/C# SDK) and have all actions be recorded & retrievable from our backend infrastructure in #1 #5

[STA-33] Enable IPFS Uploading to Nodes, contracts or postgres

Use Flask + the client to allow users to upload their data in an organised structure to IPFS, where it can then be pulled in via contracts or from Supabase/postgres.

Game frontend

_{From SyncLinear.com | STA-33}

🌌🤖 ↝ [STA-31] Claim anomalies & return stats

Create a feature on individual anomalies to claim them to a user's profile. Send a request to Flask with the following information:

1. TIC ID (of the claimed anomaly) → this will be changed to different identifiers based on what type of anomaly it is (could also be multiple identifiers per anomaly if each identifier is used in a different dataset like lightkurve and something else).

   Down the line it will be the other way around - an anomaly will be generated by a user and a TIC ID/identifier will be assigned to it, however for now we're just manually adding anomalies to the database (which will be moved across to the DeSci Nodes setup)

2. Metadata tags (as JSON) → Things like dataset, discovery info, etc.

3. User ID/Account info

Flask will then generate images and return those images, as well as other parameters, which will be passed into the planet's sandbox page -@zaq42 (with the "other parameters" e.g. orbital period being passed into the sandbox's generator). For now, only the "owner" of a planet can edit the sandbox, however users will be able to "fork" someone else's anomaly and manipulate it as they wish.

What needs to be done then? For the frontend, we need to knock in the windows for the images and other metadata to be included, and then I need to update the planets table with the following new fields:

1. Multiplier → will be set to 1 by default, can be edited/changed based on what is returned from Lightkurve. For now, we'll only have one currency → "resources", which in the MVP will be split into the different resource types described here. In the MVP, there will be a different multiplier for each resource type (JSON!). Maybe the multiplier can be set by the earthRadius field for this demo
2. Owner → reinforce the relationship between profiles table & planets table
3. Contract → Address of the planet. This is so that we can return fields to interact with a token (push/pull) on the frontend, like updating/adding metadata. 3, 4, 5 & 6 are more for when we move this data/Supabase instance to an IPFS setup on Nodes
4. TokenID → Id of the anomaly on the contract (for future discussion → where does the split between ERC1155 & ERC721 occur in the flow?
5. ChainID → What chain is the address on?
6. Owner Address → Just in case the owner address is different to the id in profiles of Owner …. for debugging purposes only atm
7. Forks → JSON. Who has forked this anomaly
8. ForkFrom → UUID. What was the original ID of this anomaly (if it was forked)
9. Posts → What shortform/discussion posts & comments was this anomaly mentioned in?
10. Articles → What long-form discussions was this anomaly mentioned in?
11. Datasets → What datasets was this anomaly part of?
12. Returned/Generated fields → JSON

Then we can add some reputation points to the user → for now it can be 1 point for every anomaly they claim/classify, as that's the flow I'm thinking will be in place at MVP.

_{From SyncLinear.com | STA-31}

🧪🏳️‍🌈 ↣ Create test protocols/smart contract for planet generation

Create new planets (including planet NFTs) based on users' performances in mini-games (some of which will be 100% smart contract-based

Let's augment these with DAO integrations

https://skinetics.notion.site/Base-P2L2E-Game-structure-17015f978aa7465d8c6047ac593b021d

Linear info:
https://linear.app/star-sailors/issue/STA-25/create-test-protocolssmart-contract-for-planet-generation
Id: STA-25

🎋🦉 ↝ Understanding current interactions & identifying value

Plane.so doc

#42

---

Objective: determine the current functionality in the current build (as of date of issue creation i.e. 21.1.2024), identify what data is being stored/retrieved, what data/contributions & classifications is being sent, and identifying value, gameplay and ways to improve

How does it feel to "play" Star Sailors? How does "playing" this build change our views of the "first hour of gameplay" goals originally written out in December?

Identifying data sources and more builds. Identifying Unity requirements (e.g. planet generator). A comprehensive identification process must be undertaken to ensure that what we choose to build and sink resources into will actually be useful. Finally, determining a packaging solution & roll-out plan for the sytizen repository, as well as the creation of any APIs & hosting on Supabase that needs to take place.

What changes/improvements to the UI need to be made/designed & implemented?

---

Index

Home page shows feed, specifically MultiClassificationFeed. There is currently no limit to how many posts are shown on this feed, and as of now it only shows the post creator, their avatar, the post content and the time the post was sent.

Garden

Desktop

Removing the header menu from the garden page was a masterstroke, so thanks Nathan.

Description -> background image (that will be replaced) with the "profile picture" of each planet overlaid on top. Each picture provides a deeplink to the planet's page (not the instance). Currently, the pictures are set onto different parts of the page, at random - so each refresh will send the item to a different spot.

We need to find a layout & background that allows the planets to be shown in a more traditional format, to scale.

Also keep in mind that currently we're essentially showing all the planets that exist in-game/in the main collection, in reality "your garden" should only be showing planets you've collected/have rights to.

Parent components

Header navigation

I think we're all in agreement that for now, having a horizontal layout for our navigation is the way to go (on desktop). However, a few things need to be changed:

1. A logo needs to be placed on the header
2. Profile-based menu needs to be added
3. Preferably centre the component structure

For desktop it should be fine, but I'm thinking that more texturing might be required. On mobile, we obviously won't be using a large horizontal menu, however I think that we still need to look into some layouts for how mobile games display lots of content. I don't want to go down the Eve Online or Hades' Star route (e.g. using holographic textures to make the mass of text "acceptable" because at least it's in a "generic sci-fi format"); I want to use clever spacing & texturing/wallpapering to achieve a desirable spread of content & whitespace/gameplay actions.

I've noticed that on desktop (at least, on the Arc browser), clicking on links in the navigation (on desktop) can just result in the page being refreshed/going to the same page; you have to click on the button again to be sent to the desired page.

🍄🍀 ↣ Migrating to Next.js

This is going to lead to a few challenges, including the need for a new redesign, away from sass for now. However, the original styling will still be visible in #1 (branch supa-id) and some of it will be moved over eventually

Keep an eye on commits that ref this issue

[STA-32] Claim anomalies & return stats

Create a feature on individual anomalies to claim them to a user's profile. Send a request to Flask with the following information:

1. TIC ID (of the claimed anomaly) → this will be changed to different identifiers based on what type of anomaly it is (could also be multiple identifiers per anomaly if each identifier is used in a different dataset like lightkurve and something else).

   Down the line it will be the other way around - an anomaly will be generated by a user and a TIC ID/identifier will be assigned to it, however for now we're just manually adding anomalies to the database (which will be moved across to the DeSci Nodes setup)

2. Metadata tags (as JSON) → Things like dataset, discovery info, etc.

3. User ID/Account info

Flask will then generate images and return those images, as well as other parameters, which will be passed into the planet's sandbox page -@dave (with the "other parameters" e.g. orbital period being passed into the sandbox's generator). For now, only the "owner" of a planet can edit the sandbox, however users will be able to "fork" someone else's anomaly and manipulate it as they wish.

What needs to be done then? For the frontend, we need to knock in the windows for the images and other metadata to be included, and then I need to update the planets table with the following new fields:

1. Multiplier → will be set to 1 by default, can be edited/changed based on what is returned from Lightkurve. For now, we'll only have one currency → "resources", which in the MVP will be split into the different resource types described here. In the MVP, there will be a different multiplier for each resource type (JSON!). Maybe the multiplier can be set by the earthRadius field for this demo
2. Owner → reinforce the relationship between profiles table & planets table
3. Contract → Address of the planet. This is so that we can return fields to interact with a token (push/pull) on the frontend, like updating/adding metadata. 3, 4, 5 & 6 are more for when we move this data/Supabase instance to an IPFS setup on Nodes
4. TokenID → Id of the anomaly on the contract (for future discussion → where does the split between ERC1155 & ERC721 occur in the flow?
5. ChainID → What chain is the address on?
6. Owner Address → Just in case the owner address is different to the id in profiles of Owner …. for debugging purposes only atm
7. Forks → JSON. Who has forked this anomaly
8. ForkFrom → UUID. What was the original ID of this anomaly (if it was forked)
9. Posts → What shortform/discussion posts & comments was this anomaly mentioned in?
10. Articles → What long-form discussions was this anomaly mentioned in?
11. Datasets → What datasets was this anomaly part of?
12. Returned/Generated fields → JSON

Then we can add some reputation points to the user → for now it can be 1 point for every anomaly they claim/classify, as that's the flow I'm thinking will be in place at MVP.

Linear info:
https://linear.app/star-sailors/issue/STA-31/claim-anomalies-and-return-stats
Id: STA-31

_STA-32

🏨📦 ↝ Rover image urls aren't being sent to backend schema

https://signalk.atlassian.net/browse/FCDB-21

The metadata is working, but the url of the image isn't setup yet

create table
  public."contentROVERIMAGES" (
    id bigint generated by default as identity,
    created_at timestamp with time zone not null default now(),
    metadata text null,
    "imageLink" text null,
    planet bigint null,
    content text null,
    author uuid null,
    media json null,
    "basePlanet" bigint null,
    constraint contentROVERIMAGES_pkey primary key (id),
    constraint contentROVERIMAGES_author_fkey foreign key (author) references profiles (id),
    constraint contentROVERIMAGES_basePlanet_fkey foreign key ("basePlanet") references "basePlanets" (id),
    constraint contentROVERIMAGES_planet_fkey foreign key (planet) references "inventoryPLANETS" (id)
  ) tablespace pg_default;

🦈🔗 ↝ Generate asset, ID & stats/elements for anomalies when being claimed

See STA-31 STA-32 STA-33 STA-34

Use matplotlib to generate an image (will be a 3d asset in MVP/prod) when an anomaly is being created. Cross-reference it with the metadata mentioned at #29, i.e. adding new metadata like its radius. This metadata is then used in the Generator component (3JS/Unity as well as in Matplot).

Update the fields to include things like the "seed" in https://steveasleep.com/stellardream/. This should match the seed in the 3JS planet editor:

const seed = usePlanetEditorFieldState('seed', randomSeed(), value => {
planet.seed = value;
planet.regenerateTerrain();
planet.regenerateShading();
return planet.seed;
});

Star system should be the same as the TIC Id (which will cause conflicts between the correct/real fields like radius from lightkurve and the fields created by stellardream → however, this is useful for fictional planets, plus comparing the two identical seeds/ids in-game. Helps to train models/users to identify differences between candidates.

So: Create a planet by entering some fields in a new createPlanet form.

First, a random TIC ID will be sent to the server which will return 1 image (graph) and the estimated radius. This radius is then sent to the Generator:

"Send a request to the python Generator" →

import numpy as np
import matplotlib.pyplot as plt

from tqdm import tqdm
from noise import double_perlin3D, background

from geometry import normal, cos_vec, reflection
from colour import colorize

res = 2048
radius = 0.4 ...

Return this image (saved as examples/out0.png to the client) and then delete it from the server so the next time it is called, the image generated will be saved to the same path.

A planet with id "ticId" is created with a profile image (examples/out0.png) and in its stats, the field "radius" and the graph generated from Lightkurve above.

A copy of a notebook that has that anomaly's dataset will be added to the "profile page" of that anomaly/planet, as well as the 3JS/Unity generator with the radius field filled in from the dataset.

The planet is then owned by the player who generated it. It costs 1 reputation/credit/currency to create it, but they can then earn 2 by adding some new data to it (saved as a new field), which will be a demo of the classification process.

Then, save export its fields from its table (including owner address) to a new lazy minted NFT

Linear info:
WB3-14