Hey everyone, is there a way to tell the server to auto-accept votes while only the admin or the server GUI can start ones? Thanks! Greetings, guenther
Are you sure you need to start a vote in that case? You can probably just do what you're trying to do with an admin command, instead of voting.
Example: You want to advance to the next session. There is "/callvote nextsession", which somehow do not do anything at all when being executed on the server. Based on this https://steamcommunity.com/sharedfiles/filedetails/?id=580727258 , I do not see an /nextession command to do that directly.
Call vote as admin should do it straight away I think. There is always an entry in the multiplayer.json that says something like votes can't be called if an admin is present.
Already played around with that values, also I'm only calling the votes from the server itself, not the client GUI. Server basically ignores this commands.
yeah, that is all cool, I know that buttons. But: As I'm building my automation tool (see https://forum.studio-397.com/index.php?threads/apx-rfactor-2-orchestration-project.67628/), it's pain-in-the-ass to click buttons, calling text commands would make that more robust.
I thought clicking buttons was just as easy as putting text commands in. I used the buttons where possible when running server automation tools, the commands were the plan B when a button wasn't available.
Yeah, it's not that difficult to identify the button and click it. It's more tricky if the window hasn't the focus, as click events are invoked as actual mouse events with requiring the button to be real "clickable". And this causes the image to be required to be maximized, which is quite annoying.
I still don't follow, but I don't remember the dialog control manipulation I used. I was finding the server windows by name and then using standard windows coding to press the buttons by their ID - which for the most part didn't even change from rF1. It sounds like you're perhaps using a mouse control accepting language.
Well, I'm using pywinauto, nothing exotic. The thing is only, that click events are always a mouse thing. And if your window is minimized/ hidden/ out of focus, this becomes a bit flaky.Thats my issue.
Ok, yeah. My phone corrected 'scripting' to 'accepting' above, that might have been a bit confusing. I just had to revise what I was using (been a couple of years), I had an AutoIT script managing each dedi server window. I left each dedi instance up on screen (standalone server PC) so minimising wasn't an issue, focus didn't seem to affect functionality. It uses a command it calls ControlClick (takes the window handle, and a control ID). The notes do say sometimes controls will resist being clicked unless the window is already active, I never had an issue with that but I should say I had the script as a whole monitoring the window and keeping track of session status etc - so it was never going to try and restart the weekend or go to the next session at an inopportune time (like when the button may not be available) as it knew when the session had started etc. So sounds quite similar I would say (as far as how the languages manipulate the server dialog), perhaps a combo of the particular environment I was using being happier to stay responsive, and my rather in depth monitoring and logic that may have stopped it trying to do things at the wrong moment. Not sure.