You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.
You need to add variants to the enum messages that go between the clients and servers.
The place to start for that is in hcor, specifically hcor/src/wormhole/mod.rs
that's where all of the Asks and Notes are defined; for more info on those build the crate level backend documentation.
(as the crate-level documentation will tell you, Asks are things the client wants the server to do, and AskedNotes are messages from the server that respond directly to Asks.)
so in hcor/src/wormhole/mod.rs, the structs you're looking for are Ask and AskedNote.
add a Nickname or Rename variant to PlantAsk. I don't think the variant should need to store more than a tile id and the name you want to set it to? I can't imagine we'd need more information than that to change a plant's name.
For renaming Gotchi, the path is less clear; there's no GotchiAsk. Just add GotchiRename or Rename to Item and once we have a bunch of Gotchi routes we'll probably pull that out into a discrete GotchiAsk.
Adding an AskedNote should be somewhat simpler, since all AskedNotes are stored alongside each other without any sort of nesting. You will have to chose what you want your rename routes to return; cloning the entire plant or gotchi and sending that back over the network is a possibility, as is simply returning (), it's your call.
Step 2 -- Responding Serverside
If you compile backend, you should already get a handful of errors saying that your new Asks you've added aren't handled by the server. You can address that by going to the appropriate places (/backend/wormhole/session/tile/plant/mod.rs and /backend/wormhole/session/item/mod.rs) and adding routes to handle renaming. Consider reading that entire plant/mod.rs (it's not very long at all) to get a feel for the patterns (In particular, I want you to see how all routes have their own file). I would copy /backend/wormhole/session/tile/plant/summon.rs to a new file, nickname.rs, and start whittling down from there (for example, summoning a plant has to set up timers for that plant, which isn't necessary when you're just renaming. Also, summoning inserts a plant, I think you'd rather modify a plant, so consider the .plant_mut method.) Note that all of the route files start with an enumeration of possible error cases (man, we could make those so much shorter and prettier with thiserror), then have the actual implementation of the route, then end with (hopefully comprehensive) tests of that route.
FYI:
Note that routes which can't be handled by a single user's Session (like transferring items between two different users) are sent to the Server to handle, because the Server is the only thing capable of handling interactions between multiple users. Renaming plants/gotchi only requires a single user and a single user's Session, so this isn't entirely relevant to what you're doing.
Consider checking the documentation on SessSend in /backend/session/mod.rs or looking at the implementation of handle_ask at the bottom of that file. SessSend is your primary tool when implementing Asks and timer responses, so it may be useful to learn why it exists and works the way it does.
Step 3 -- hcor: Rust API Bindings
At the bottom of the nickname.rs you copied from plant/summon.rs, there should be a test function which runs against some common error cases. A lot of plant/summon's error cases come from the fact that it has to consume a valid item to properly execute, and fail otherwise without consuming the item, but because nickname doesn't have to do anything of the sort, it should be a lot simpler. You'll note, though, that the test doesn't send the Ask message to the server directly through the websocket, instead it simply calls methods like
let mut hs =Hackstead::register().await?;
hs.slaughter().await?;
or
let open_tile = hs.free_tile().expect("fresh hackstead no open land?");
open_tile.plant_seed(seed_item).await?;
To make it super-duper easy to write clients, tests, and illustrative documentation in Rust, hop back to hcor to add methods on Plant and Item to assist in renaming. I would start by copying an existing handling method -- maybe plant_seed on Plant, and then changing the Ask and AskedNotes (as well as the return type) to match ones you configured in step 1.
Step 4 -- Clean up the Test
This should be pretty straightforward, once you have your Rust bindings to the API.
let (_, seed_arch) = hcor::CONFIG.seeds().next().expect("no items in config that are seeds?");
let mut bobstead =Hackstead::register().await?;
let seed_item = seed_arch.spawn().await?;
let open_tile = bobstead.free_tile().expect("fresh hackstead no open land?");
let plant = open_tile.plant_seed(seed_item).await?;
plant.rename("bobby jr.").await?;
// refresh bob's stead
bobstead =Hackstead::fetch(&bobstead).await?;
assert_eq!(
bobstead.plant(&plant).name,
"bobby jr."
);
Good luck, and if you run into anything, just hit me up on IRC!
The text was updated successfully, but these errors were encountered:
stolen roughly from IRC
Step 1 -- Message Spec
You need to add variants to the enum messages that go between the clients and servers.
The place to start for that is in hcor, specifically
hcor/src/wormhole/mod.rs
that's where all of the
Ask
s andNote
s are defined; for more info on those build the crate level backend documentation.(as the crate-level documentation will tell you,
Ask
s are things the client wants the server to do, andAskedNote
s are messages from the server that respond directly toAsk
s.)so in hcor/src/wormhole/mod.rs, the structs you're looking for are
Ask
andAskedNote
.add a
Nickname
orRename
variant toPlantAsk
. I don't think the variant should need to store more than a tile id and the name you want to set it to? I can't imagine we'd need more information than that to change a plant's name.For renaming Gotchi, the path is less clear; there's no
GotchiAsk
. Just addGotchiRename
orRename
toItem
and once we have a bunch of Gotchi routes we'll probably pull that out into a discreteGotchiAsk
.Adding an
AskedNote
should be somewhat simpler, since allAskedNote
s are stored alongside each other without any sort of nesting. You will have to chose what you want your rename routes to return; cloning the entire plant or gotchi and sending that back over the network is a possibility, as is simply returning()
, it's your call.Step 2 -- Responding Serverside
If you compile
backend
, you should already get a handful of errors saying that your new Asks you've added aren't handled by the server. You can address that by going to the appropriate places (/backend/wormhole/session/tile/plant/mod.rs
and/backend/wormhole/session/item/mod.rs
) and adding routes to handle renaming. Consider reading that entireplant/mod.rs
(it's not very long at all) to get a feel for the patterns (In particular, I want you to see how all routes have their own file). I would copy/backend/wormhole/session/tile/plant/summon.rs
to a new file,nickname.rs
, and start whittling down from there (for example, summoning a plant has to set up timers for that plant, which isn't necessary when you're just renaming. Also, summoning inserts a plant, I think you'd rather modify a plant, so consider the.plant_mut
method.) Note that all of the route files start with an enumeration of possible error cases (man, we could make those so much shorter and prettier withthiserror
), then have the actual implementation of the route, then end with (hopefully comprehensive) tests of that route.FYI:
Session
(like transferring items between two different users) are sent to theServer
to handle, because theServer
is the only thing capable of handling interactions between multiple users. Renaming plants/gotchi only requires a single user and a single user'sSession
, so this isn't entirely relevant to what you're doing.SessSend
in/backend/session/mod.rs
or looking at the implementation ofhandle_ask
at the bottom of that file.SessSend
is your primary tool when implementingAsk
s and timer responses, so it may be useful to learn why it exists and works the way it does.Step 3 -- hcor: Rust API Bindings
At the bottom of the
nickname.rs
you copied fromplant/summon.rs
, there should be a test function which runs against some common error cases. A lot ofplant/summon
's error cases come from the fact that it has to consume a valid item to properly execute, and fail otherwise without consuming the item, but becausenickname
doesn't have to do anything of the sort, it should be a lot simpler. You'll note, though, that the test doesn't send theAsk
message to the server directly through the websocket, instead it simply calls methods likeor
To make it super-duper easy to write clients, tests, and illustrative documentation in Rust, hop back to hcor to add methods on
Plant
andItem
to assist in renaming. I would start by copying an existing handling method -- maybeplant_seed
onPlant
, and then changing theAsk
andAskedNote
s (as well as the return type) to match ones you configured in step 1.Step 4 -- Clean up the Test
This should be pretty straightforward, once you have your Rust bindings to the API.
Good luck, and if you run into anything, just hit me up on IRC!
The text was updated successfully, but these errors were encountered: