Lots of DKMP players use the "guest costumes" as ride operators or employees selling food. If it's gonna be possible to freeze guests and be able to give them items, this issue can be solved.
Freezing guests also will have a concequence for the park rating so that needs to be taken into account.

Thanks for weighing in @Manticore-007. I appreciate what your community is doing with the game, so I'll try to be accommodating, within reason. Either way, the current situation is hacky and messy, exposing state that shouldn't be. Let's work towards something that is a bit more sustainable. That is, we allow for creativity, whilst not getting staff entities into a state their shouldn't be in.

From your community's perspective, I see the following:

• Desire to render peeps and staff 'frozen', tweaking their state and position such that they take part in a narrative of sorts (e.g. peeps permanently sitting around a campfire)
• Currently, entertainers are used for this purpose, as it's the only entity type whose appearance can be changed through scripting.

Thinking about this, we could do two things:

1. Add a 'costumeless' entertainer variant, rendering them as a normal peep. This would still just be a basic 'costume'; no food can/should be assigned in this case.
2. Make peeps properly freezable and editable, allowing for changing state (jumping, sitting, eating...), with a special case of specifying food when eating.

The more I think about it, the more caveats I see, though. You've already mentioned park rating might be affected. Similarly, we'd need to make ensure cheats like 'remove all guests' and the 'energy' cheats don't affect the 'special' peeps, much like how they don't affect staff right now.

For now, I think we can add an exception to still allow assigning the 'normal' peep costume to entertainers. We can decide on how best to convert them later, depending on whether we go with route 1 or 2.

Either way, I would much prefer we disallow the food modifiers entirely for now. This is really a kind of state I would prefer staff to never be in.

Existing parks won't be affected while we work out the details. These staff/entertainer objects won't be ready for a while yet.

I hope this is an acceptable compromise. Please feel free to weigh in with your thoughts.

Given those peeps/guests/entertainers are typically frozen why not have animated scenery object instead, perhaps there are some limits I'm not aware of but we could look into making that better.

To be honest, I think these changes should be part of when the new objects and API's are thought out and ready, not when it's the old API's are still actively used. It's not really stopping anything as the API's are already used in a lot of parks. We'll already have to deal with that and that won't change if we block it now or later, but the disappointment will have a bigger impact if we do it now with no further concrete replacements.

Given those peeps/guests/entertainers are typically frozen

Typically they're frozen, but not always. For example, these dancing and waving guest entertainers here.

After talking with @duncanspumpkin, I think it's best to add a new flag to peeps that freezes them completely.

We could expose this to plugins by means of a new boolean property, e.g. frozen (true/false). We could then also add a new property to set the food item peeps are carrying, changing their animation 'costume'. This would replicate current 'functionality' in a more constructive way.

Caveats I see, as above, are that such peeps should not be removed by the 'remove all guests' cheat, nor should they affect park ratings. I think the latter should be fine, though, given such peeps would not lose energy, or change state (and therefore not into a 'lost' state). They will, however, still count as guests.

Another caveat that Duncan mentioned, is that we should avoid freezing peeps that are on rides. This may seem obvious, but players have tried to do stranger things...

We would also need to change staff members that have 1) been frozen and 2) have a non-staff outfit into normal guests. Perhaps we should increment the park version so this pass does not have to be done for newer parks.

After the above has been implement, staffs should never look like peeps any more. That means the road is clear for staff uniforms/costumed to be extracted to objects.

Does this sound good? Any further caveats/ideas/roadblocks/feedback you can see, before we proceed with implementation?

Sorry @Basssiiie, it seems our comments were posted mere minutes apart. I didn't mean to ignore yours.

To be honest, I think these changes should be part of when the new objects and API's are thought out and ready, not when it's the old API's are still actively used. It's not really stopping anything as the API's are already used in a lot of parks. We'll already have to deal with that and that won't change if we block it now or later, but the disappointment will have a bigger impact if we do it now with no further concrete replacements.

I agree. This PR should not be merged before alternatives are in place. Let me make that clear by marking it as draft.

Given those peeps/guests/entertainers are typically frozen

Typically they're frozen, but not always. For example, these dancing and waving guest entertainers here.

Okay, that just means we'll have to support entertainers in 'peep suits' then. Perhaps we can call this 'out of costume', though hidden by default.

I just draw the line at getting entertainers into a food-holding state. That should really be addressed with regular peeps 😅

Sorry @Basssiiie, it seems our comments were posted mere minutes apart. I didn't mean to ignore yours.

@AaronVanGeffen No worries, I've been too busy anyway! 😅

I just draw the line at getting entertainers into a food-holding state. That should really be addressed with regular peeps 😅

How did you have this in mind, some kind of unlimited bites on a food item so it cannot run out for walking staff with food? I think there's some cases where the sandwich food is used like a sword or flute or something, for example.

If it helps, I can find some more examples and existing use cases to help us find work towards a nice API. It would also help if you/we work out the idea for how the potential new costume objects etc. should look like, so we can work towards bringing both ends together. I'm imagining there will still be some form of animation sets we can maybe work with? But that's just guessing at the moment. 😅

Edit: I do think the rest sounds good, I'd just like all bases covered. AFAIK the PeepEditor is the only one using these properties, and Manticore mentioned to me he was willing to update it to keep it working with a better API, so I think the breaking changes are acceptable for the greater good, if we can cover the preferred bases. :)

I just draw the line at getting entertainers into a food-holding state. That should really be addressed with regular peeps 😅

How did you have this in mind, some kind of unlimited bites on a food item so it cannot run out for walking staff with food? I think there's some cases where the sandwich food is used like a sword or flute or something, for example.

Definitely in combination with the peep 'frozen' flag I mentioned in my previous comment (which coincided with yours). We'd have to convert these staff to normal peeps in the process, ensuring parks don't break, though.

If it helps, I can find some more examples and existing use cases to help us find work towards a nice API. It would also help if you/we work out the idea for how the potential new costume objects etc. should look like, so we can work towards bringing both ends together.

Yes, that sounds like a good idea. Perhaps we can coordinate something through Discord? My DMs are open :)

I'm imagining there will still be some form of animation sets we can maybe work with? But that's just guessing at the moment. 😅

Definitely. I've been refactoring a bunch to that end lately. Please take a look at #21711, for example.

Some examples of peep scenes, the dancing scene with moving peep staff that either wave or jump (made by Bluetiful Monday):

Frozen staff as handymen and peeps with sandwiches and a balloon rope without balloon, forming an orchestra (made by Melmak):

Frozen staff as peeps and balloons (made by Manticore):

Frozen staff with a hat and a staff as a floating hat (invisible peep) as Santa (made by Manticore):

Frozen staff as wizards and a frozen mechanic, with litter items as beards and hats (made by BallpitWarrior):

Walking staff as peeps with food, and also jumping/waving (made by Enox/Deurklink):

Frozen peeps with food items and sunglasses (made by Enox/Deurklink):

A pdf from Manticore showing a lot of combinations currently possible:
Peep_animation_sprites_-_Blad1.pdf

This should be most cases with the least amount of duplicates.

After speaking with Aaron on Discord and it seems the following set up could make it all work:

For staff posing as guests:

• They get converted to appropriate guest setup, including food/drink/other items.
• They get a flag that can freeze stats, which means;
  • Food items don't decay.
  • They don't get lost or want to go home.
  • They don't contribute to the park rating.
  • When their energy is set to 0, they won't regain energy.
  • When they do have a non-zero energy, they can still walk around like they could do before (as if they're entertainers) and won't interact with any rides/stalls/park entrances.

For actual frozen staff members, there doesn't seem to be much that needs to be converted, apart from old costume system to new costume system.

One thing I'm not yet sure about is where the floating balloons/hats/umbrella's would fit. Frozen guests? A hidden staff costume? A special litter entity? Or another entity type?

Edit: Another thing I just found out... The walking staff with guest costume and food item in Enox's park have staff zones as well. 😅

Thanks for the examples and summary, @Basssiiie.

One thing I'm not yet sure about is where the floating balloons/hats/umbrella's would fit. Frozen guests? A hidden staff costume? A special litter entity? Or another entity type?

Oh noo, this is yet another hack on another level 😅 Honestly, I'll need to have a think about it. I suppose they stay hidden, frozen peeps. What items they possess shouldn't be an issue, so long as we convert these staff to hold them. Good that you pointed this out, because I certainly wasn't aware of hacked staff on this level.

These kinds of hacks are why I filed this PR in the first place, tbh. I'd rather we narrow the scope of these APIs early, adding new features explicitly rather than seeing parks rely on undefined behaviour...

Following up in #21913. After that PR has been finished and (hopefully) merged, we can revisit this.

Given the food properties added by #21062, I believe all ingredients are set to merge this after #21913.

I've reworked the PR as follows:

• Continue allowing 'peep' style costumes, dubbed none costumes.
• Allow scripts to set costume property by string (or number, as before).
• Allow scripts to fetch a list of available costumes for current staff type via the availableCostumes property.
• Allow costume changes for all staff types, not just entertainers, but limited to costumes for the staff type. (Handymen and mechanics have just one, security staff have two, entertainers have 12, including none)

Requires testing. Shouldn't crash the old/current Peep Editor, but will limit its effect. @Basssiiie and @Manticore-007, could you test this?

We should probably bump the plugin version number before merging.

First test with the current Peep Editor doesn't crash the game, it gives error messages:

CLI:

The entertainer still can be turned into a guest(Peep Editor costume), the costume shows as "none" in the CLI.
But when yiou click an entertainer with guest costume, you will get the following:

there is no crash of the game doing this.

@Manticore-007:

First test with the current Peep Editor doesn't crash the game, it gives error messages: !

This is indeed expected. You can no longer assign entertainer costumes to non-entertainer members. This is due to handymen/mechanics/security staff not having all of each other's animations, and so could eventually lead to a crash.

The entertainer still can be turned into a guest(Peep Editor costume), the costume shows as "none" in the CLI.

This too is expected. Allowing them to be turned into a guest is a concession, as discussed in this PR. Regular guests have a superset of the animations and sprites that entertainers need, so it will render fine.

But when yiou click an entertainer with guest costume, you will get the following:

Requesting the current costume with .costume will now return a string rather than an integer, which the script is apparently expecting. Unfortunately, I don't see a way around that.

@Basssiiie:

Only issue I found is that assigning security1 only assigns it for a second or so. After that the guard switches back to security2. But I think this is likely due to the state machine outside of this PR?

That's correct, yes.

I did notice security1 is used when the guard is falling. He'll switch to the 1st costume after a second or so, until he has landed, after which he'll switch back to security2 after a few seconds. The first costume can also sometimes be triggered by picking him up and dropping him, so it's probably tied to some tick % 128 == 0 or something.

Spot on:

void Staff::Tick128UpdateStaff()
{
    if (AssignedStaffType != StaffType::Security)
        return;

    PeepSpriteType newSpriteType = PeepSpriteType::SecurityAlt;
    if (State != PeepState::Patrolling)
        newSpriteType = PeepSpriteType::Security;