implemented skull trophies logic, api

[m-hynek]

37

Hello again,

since server owners most likely want to display names of their supporters or top ranks from leaderboars (without hunting them around for skulls), I implemented maskull command with skullName argument. Also I couldn't think of another situation, where container persistence could be beneficial. Vehicles could be sorted out by another plugins and only interesting use case to me are very custom lootboxes (fridges with food, large boxes with resources like stone, metal, etc) as another loot source for players, but that would require some extra steps. All that sounds more like custom addon than something MA should support by default, imo.

Changes:

• added SkullName field to SingeEntityController data
• added command maskull to attach named skull and set trophy as busy (without command, skull can be added/removed manually)
• ensure skull is atached on spawn, when data contains skull name
• added api to change skull name externally

API While this solution works just fine, I am not sure if it isn't too specific - I think profile data could be manipulated in more general way, but im not sure how to approach it. What do you think? Motivation for this method is automation of throphy names display based on variable data

[WheteThunger]

Welcome back! Thanks for your continued interest in this project.

I'm fine with the maskull command, but I agree the API feels overly specific. I suggest we leave it out for now. It could be achieved via a custom addon for placing skulls in the worst case.

[WheteThunger]

Thinking about the API some more, I'm starting to think it would make sense to support basically all of the commands as APIs: maspawn, masave, makill, masetid, masetdir, maskin, maspawngroup, maspawnpoint ,mapaste. There would of course need to be minor differences since there is no player argument from which to get perspective. The mawire command would be a bit trickier; would likely need APIs to just "connect" or "disconnect" two entities.

Some examples off the top of my head:

• Guid API_Spawn(string profileName, string monument, string prefab)
  • Need to think about whether it makes sense to have auto position/rotate like we do for some entities (big_wheel, boat_spawner, spray.decal)
• bool API_Kill(BaseEntity entity)
• bool API_Kill(string profileName, string monumentName, Guid guid)
• bool API_Save(BaseEntity entity)
• bool API_Save(string profileName, string monumentName, Guid guid)

[m-hynek]

Thinking about the API some more, I'm starting to think it would make sense to support basically all of the commands as APIs: maspawn, masave, makill, masetid, masetdir, maskin, maspawngroup, maspawnpoint ,mapaste.

What about API for entity profile JSON exchange? Commands like maspawn, makill, maspawngroup, maspawnpoint ,mapaste can be substituted with profile enable/disable command. I dont see too many use cases where it would be neccessary to spawn stuff without previously handpicking location. For rest of the commands, It should be enough to have:

• API metod to retrieve json data of MA entity
• API method to set json data of MA entity

[WheteThunger]

You make a good point. Historically, it's been my position that dynamic changes should be handled by toggling profiles. In my previous post, I was thinking about generally making the plugin more flexible. For instance, most of the command features of the plugin could be re-implemented by another plugin by simply utilizing the APIs, but I doubt anyone would actually do that. Another use case would be to add UIs to manage entities, but I already implemented most of that early last year (not yet committed). IIRC most of the refactoring necessary to make the APIs possible was already done while implementing the UI. One thought that just occurred to me is that we could proceed with the APIs, and make the UI an addon plugin, but now that I think about it, I estimate that will require the UI plugin to have deep knowledge of the JSON structure.

Another related use case, that could be driven via APIs, is that there are various plugins which try to spawn entities randomly at monuments. That feature could eventually be offered by Monument Addons, but it could also be achieved by an addon plugin that generates the entities and spawn points randomly, then adds/removes those via the API.

API metod to retrieve json data of MA entity API method to set json data of MA entity

I'm wary of this approach because it implies that other plugins would be manipulating the JSON. I'm initially against that because it would require enforcing a JSON contract which I'm not inclined to do because it would restrict how Monument Addons can change going forward.

[m-hynek]

I will try to think about some use-cases for the api from server owner perspective, but in general I think that most of the stuff would be interacting with addons instead of using MonumentAddons in different way.. if it makes sense

So for example methods like:

List<BaseEntity> API_GetAddonsByGuid(guid id, string profileName = null) bool API_IsEntityAnAddon(BaseEntity ent, out guid id, out string profileName)

These 2 methods alone are already "powerful" enough that It would allow some interesting functionality