Open cloudkucooland opened 4 years ago
cloudkucooland
commented
2 years ago scrap all above. work is ready in the server
each marker will have an []attributes
{ ID: 40 character random string created by client assignedTo: GID who this attribute is assigned to (e.g. deviousness install shield; lejeu install link amp) name: the value name (e.g. "mod") value: the value (e.g. "link amp") }
The name/value pairs of the attributes will be defined by Wasabee-IITC and WebUI as we identify them.
cloudkucooland
commented
2 years ago Initial suggestion for attributes:
Upgrade
level: <1-8> (max 1)
mod:
Link target portal: ???
Meet:
agent:
destroy: ???
capture: ???
let decay:
last charge:
exclude: ???
Farm: ???
Goto: ???
GetKey: desired count
MeetAgent: agent: who
Other:
description:
Recharge:
frequency:
Virus: ???
bgillock
commented
2 years ago I'll throw out some user stories to hopefully get some ideas going.
cloudkucooland
commented
2 years ago I'll throw out some user stories to hopefully get some ideas going.
- As a planner I want to specify what mods are needed on a portal.
That's the point of this FR
- As an operator I want to specify when the mods need to be installed and by who.
"when" is trivial to add with another attribute on the mod type
- As a boot, I want to know what mods i need to install on which portal and when I need to do it.
... the point of this FR
cloudkucooland
commented
2 years ago "when" is trivial to add with another attribute on the mod type
actually, just use the delta on the Task - standard place of saying "when" -- unless different mods need to be installed at different times, but now that we can have multiple markers of the same type per portal, just have 4 upgrade markers, each with 1 mod, each with the respective delta
We need the ability to specify the mods to install. I'm listening back to previous ops and "do I need to put a link amp on this?" "what mods?" is a common question.
Possible locations: on a marker
on the anchor pin:
on the portal: there is no UI for working with raw portals, but we could present it on marker/anchors
on the link:
I'm thinking the best place would be on the underlying portal (where the portal comment is stored) that way it can be displayed on either marker or anchor pin.
anchor.js/marker.js classes would need setmods() and showmods() methods - the portal.js class will need a mod array with appropriate setter/getters, and probably some additional stuff in operation.js