Thread Rating:
  • 2 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PocketBuddies!
#16
(09-27-2016, 07:23 AM)amaranthineApocalypse Wrote: Well fuck if those conveyor belt lines aren't the second most heartbreaking thing i've ever seen in SS13

What's the first?
Reply
#17
(09-27-2016, 06:35 AM)locusts Wrote: So that the coders don't have to write thousands of lines of buddy speech, I've made an editable spreadsheet so that we can contribute buddy speech ourselves. Feel free to add triggers and alternate lines.

https://docs.google.com/spreadsheets/d/1...sp=sharing

I'll take a crack at adding to this. Changed a couple of gendered pronouns to "they" forms for more flexibility.
Reply
#18
(09-27-2016, 07:31 AM)Noah Buttes Wrote:
(09-27-2016, 07:23 AM)amaranthineApocalypse Wrote: Well fuck if those conveyor belt lines aren't the second most heartbreaking thing i've ever seen in SS13

What's the first?

The RP i did as Paul Heckendora during D-Day 1 round 2
Reply
#19
Imo destroying someone else's Pocketbuddy feels like it should make your life forfeit, at least by the owner's hand. It's very rude and mean.
Reply
#20
If the owner is borged, the pocketbuddy should fit into one of their upgrade slots, where it would sacrifice its own powercell to keep the borg powered should it run out.

And a little hoverdolly so it can float around and follow you outside of your pocket!
Reply
#21
Code notes: An overarching event messaging datum is probably a good idea for this (generic for global usage, with pocket buddy shit as a child datum). Pocketbuddy datum would ideally read from a dict file (list? file2list() parsed on world new?) for easy message tweaking in one place. Actual event firing would probably have to be a mix of specific procs (e.g. gib() on owner) and controller loops (e.g. checking for crit on owner), as such a separate loop handler might be an idea. The pocket buddy obj itself would also need to have a shit load of unique tracking vars to keep state correctly.

Basically I see this as non-trivial, but do-able.

Edit: Note that this isn't me volunteering to actually do any of this.
Reply
#22
I'd possibly like to see this to be ported over to guardbuddies, because they are rarely used and could be a bit more vocal. A "bit", it would not detract from the pocketbuddies, in comparison they'd be a bit more mute, but all the same.
Reply
#23
Isn't this getting way too out of hand for something only a few people will use, if ever? It's a dang Tamagotchi, I want to maybe push a button to play with it and have it say something about wanting to jump one day, not have it wail horribly over my death!

I don't put this lightly, but the scope and view of this thread is beginning to match something MaRCuS would have posted about a year ago.
Reply
#24
^ Not really? If it's trivial to impliment like wire said, then it's a fun little side project for people to do and having a pocketbuddy has some benefits while also being flavor text.
Reply
#25
I said it was non-trivial, not trivial. It's definitely a decently large project with all the event integration. I still like the idea though.
Reply
#26
Might be helpful to trim the list of responses down by a lot. 

I think the basic idea of saying something on pickup, dropping, when the holder is injured/dying/dead, or when the buddy is destroyed as well as random sayings would be enough.

Maybe it can be added to later but that's basic enough not to be incredibly daunting.
Reply
#27
The coders are free to add as much or as little as they want. The spreadsheet has gotten rather large, I would personally be happy with basic stuff. The main reason I set it up was to offer some variance and see of there were any finny scenarios that people might list as triggers, the honking one is one that I like, for example.
Reply
#28
I'm okay with basic responses.

I still want emagged pocket buddy to be a jerk though. I'm the nerd who wrote "Ha ha, cripple" for the delimbed response, but that might be too ableist, but it fit with my idea of emagged pocket buddy being the worst companion ever.

(09-27-2016, 09:08 AM)Wire Wrote: Code notes: An overarching event messaging datum is probably a good idea for this (generic for global usage, with pocket buddy shit as a child datum). Pocketbuddy datum would ideally read from a dict file (list? file2list() parsed on world new?) for easy message tweaking in one place. Actual event firing would probably have to be a mix of specific procs (e.g. gib() on owner) and controller loops (e.g. checking for crit on owner), as such a separate loop handler might be an idea. The pocket buddy obj itself would also need to have a shit load of unique tracking vars to keep state correctly.

Basically I see this as non-trivial, but do-able.

Edit: Note that this isn't me volunteering to actually do any of this.
Getting a list out of a dictionary file actually sounds pretty easy.

var/list/PocketBuddy = dd_file2list("strings/PocketBuddy.txt")

Basically an exact copy of every other dialog text.

I imagine other stuff like emagged could just be it's own distinct list and text file.

Of course I don't know if copy and pasting the NT code is a good way of handling dialogue.

https://github.com/goonstation/goonstati.../nt.dm#L10

Now that I think about it, using line number to get a specific location might break things if somebody removes a line later.
Reply
#29
You picked the absolute easiest part of my code notes to comment on :v.
Reply
#30
(09-28-2016, 05:33 PM)Wire Wrote: You picked the absolute easiest part of my code notes to comment on :v.

I totally understand that the actual "DO THING AT x" part of the code sounds like a total nightmare.

Maybe some of the murray code could be butchered into something useful.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)