[Request] Expand Veto Endpoint

[kdev]

Is your feature request related to a problem? Please describe. I'm a dev for a CSGO League. We are currentely using the Get5 webpanel. I want to implement a mapveto website based on a design found on GitHub but I struggle to find Endpoints to send my data to.

Describe the solution you'd like I'd like an endpoint allowing me to send my own mapveto result data.

Describe alternatives you've considered I'm trying to write data directly to the servers but normaly thats a nogo for me.

Additional context /

[PhlexPlexico]

Considering the old implementations for Get5-Web dealt directly with the API plugin, requiring a key, I'll probably put these in, assuming people will disable the vetoes on the server itself / have the map chosen. I think the create match endpoint will also have to have the map updated on the key value pair as well, to ensure that all data is being sent before preparing a match. Will look into this and update everything accordingly when I have some spare time!

[PhlexPlexico]

Also, I do believe there is an endpoint to create or delete vetoes, located here, so I think this is what you're looking for? So long as there a match and user id.

However, I do see the problem that the match has to be made prior to, which would give some issues when generating a veto pool... It is possible to create the match, and once vetoes are complete, send the rcon command to update the match config and restart the map for it to take effect. This is an interesting conundrum because I've never really thought about approaching from a veto-first standpoint. Thanks for pointing this out!

[lukasz922]

Alternatively, instead of veto, admin chooses a map

[kdev]

That an admin chooses a map is not an option for a community league..

[kdev]

Considering the old implementations for Get5-Web dealt directly with the API plugin, requiring a key, I'll probably put these in, assuming people will disable the vetoes on the server itself / have the map chosen. I think the create match endpoint will also have to have the map updated on the key value pair as well, to ensure that all data is being sent before preparing a match. Will look into this and update everything accordingly when I have some spare time!

The problem is, we select the map after creating the match (you pointed that out in your second comment)

[kdev]

Also, I do believe there is an endpoint to create or delete vetoes, located here, so I think this is what you're looking for? So long as there a match and user id.

However, I do see the problem that the match has to be made prior to, which would give some issues when generating a veto pool... It is possible to create the match, and once vetoes are complete, send the rcon command to update the match config and restart the map for it to take effect. This is an interesting conundrum because I've never really thought about approaching from a veto-first standpoint. Thanks for pointing this out!

The problem is, this is not implemented in Get5. Get5 doesn't use the veto table

[PhlexPlexico]

Alternatively, instead of veto, admin chooses a map

I would say maybe fire that off in a different request. I believe this can already be done by setting a BO1 match, then make the veto map pool just one map long, that should allow someone to just choose one map to start a match.

Considering the old implementations for Get5-Web dealt directly with the API plugin, requiring a key, I'll probably put these in, assuming people will disable the vetoes on the server itself / have the map chosen. I think the create match endpoint will also have to have the map updated on the key value pair as well, to ensure that all data is being sent before preparing a match. Will look into this and update everything accordingly when I have some spare time!

The problem is, we select the map after creating the match (you pointed that out in your second comment)

As for this, that's what I was thinking. I may have to rework how some of the match setup goes, or just change how match setup works so that vetoes are to be done on web side. I'm not exactly keen on rewriting all the logic for that, so I think a way that could be done is checking if the vetoes all exist (n-1 count in the map pool table), then sending a new rcon command to the server to setup the match.

Or, alternatively, we could add a param in the body called web_veto or something along those lines, have it default to 0 and save it in the match table. If that's done, then we can check if we should send the match off as soon as it gets created, or wait until all vetoes have been satisfied. Once done, it can send off the proper rcon commands (api key, host, and match schema) to the server.

The problem is, this is not implemented in Get5. Get5 doesn't use the veto table

My fork of get5-web and get5-apistats uses the hooks and tables, which I am mainly referencing from since it's a bit more feature-complete. I always only considered vetoes from inside the game, but since most community-based services, like ESEA/FaceIt/Popflash all use vetoes on-site, I don't see why this API shouldn't allow the same usage.

Personally, I'm leaning more toward sending a bit with a default to 0/false in the match creation, that way it would have minimum impact for current use cases, and just re-working on how the veto endpoints work. For my own sanity, here's how I see it playing out:

• User creates match and sets web_veto to 1/true.
• Match is inserted in match table, before sending rcon commands to the server, it checks if that web_veto is true/false.
• If 0, do usual commands and get server prepped.
• If 1, wait on sending off the match schema, and don't prep game server just yet.
• Moving to veto endpoints, get match id, check what map pool is there and get all maps/mapcount.
• Each strike, update the match table to remove it from the array stored in match.
• For BO1, once last is chosen, then send off the game server prep (API key, etc.).
• For BO3, during a pick, keep the value in the array, or create a temp array so we ensure order is kept for which maps are played out.

As for knifing for sides, etc, that can still be chosen during match creation. I think that makes the most sense in my head, unless you have different ideas, I'm all for it!

[PhlexPlexico]

Okay I think there may be a way to currently implement this. However, I'm not quite yet sure on how everything will tie together.

Since there is already a skip_veto column in the match table, I wanted to use that. However it's not quite possible since there is no way to determine if we need to outright skip the vetoes (pre-chosen maps), or veto on site. So we are going to need that web_veto column, then it will allow us to not yet send the commands to the servers. Once vetoes are completed (which then updates the match table). we can use the same logic to start the match, which sends the match config to the server, and should have the defined maps. So I think the only things I really need to modify is:

• Match creation

• Veto endpoints

• Match config being sent out

After that, it should work as intended without having to deal with any of the other stuff I had in the above comment.

[PhlexPlexico]

Okay, I've included a veto update endpoint. However there already is a way to implement on-site voting. It just requires a workflow.

1) Create match without a server assigned. Can use bare minimum data requirements for the match. Doesn't require the veto_mappool at all. Realistically just need the teams, and start_time, plus ignore_server must be included as true. 2) Begin vetoes. 3) Call a PUT on the match, including any other data that needs to be entered. Server ID would be assigned here. The most recent push I'm doing here should allow the system to look at the veto table and construct the veto_mappool for the match. It will then call the prepare match calls and setup the match.

That in theory should make this work now. Plus, if you really want, I did include a PUT for the veto endpoint, for sake of completeness.

[PhlexPlexico]

Considering there is now a way to do vetoes on a website first, I'm going to close this. Let me know if you run into any issues with that approach, but I believe it should be good to use as such!