1. Do you need support for Assetto Corsa Competizione? Please use the proper forum below and ALWAYS zip and attach the WHOLE "Logs" folder in your c:\users\*youruser*\AppData\Local\AC2\Saved. The "AppData" folder is hidden by default, check "Hidden items" in your Windows view properties. If you report a crash, ALWAYS zip and attach the WHOLE "Crashes" folder in the same directory. Do not post "I have the same issue" in an existing thread with a game crash, always open your own thread. Do not PM developers and staff members for personal troubleshooting and support.
  2. As part of our continuous maintenance and improvements to Assetto Corsa Competizione we will be releasing small updates on a regular basis during the esports season which might not go through the usual announcement process detailing the changes until a later version update where these changes will be listed retrospectively.
  3. If ACC doesn't start with an error or the executable is missing, please add your entire Steam directory to the exceptions in your antivirus software, run a Steam integrity check or reinstall the game altogether. Make sure you add the User/Documents/Assetto Corsa Competizione folder to your antivirus/Defender exceptions and exclude it from any file sharing app (GDrive, OneDrive or Dropbox)! The Corsair iCue software is also known to conflict with Input Device initialization, if the game does not start up and you have such devices, please try disabling the iCue software and try again. [file:unknown] [line: 95] secure crt: invalid error is a sign of antivirus interference, while [Pak chunk signing mismatch on chunk] indicates a corrupted installation that requires game file verification.
  4. When reporting an issue with saved games, please always zip and attach your entire User/Documents/Assetto Corsa Competizione/Savegame folder, along with the logs and the crash folder (when reporting related to a crash).

About that maybe-server-api

Discussion in 'Chit Chat Room' started by Minolin, Jun 11, 2015.

  1. Minolin

    Minolin Staff Member KS Dev Team

    Yep the UDP-Redirector should be part of any "plugin manager" in this way, no question. The dependancy is pretty unhealthy. But raw UDP isn't for everyone and I think a comfortable API implementation has it's place (and hopefully the python and whatever competitor as well, in a perfect world).
     
  2. cooknn

    cooknn Alien

    You should get on Stefano's code session/chat tonight and ask him!

     
  3. ABernardo

    ABernardo Racer

    Code session. Right. Just like we're getting that 1.2 update in early July.

    It won't even come in July, period. Kunos has promised a lot, and has delivered very little. This game is still in beta. It's a hot-lapping sim.

    I only wish there was another racing title that had the physics of AC. I'd leave this game tomorrow. Great sim-- poor implementation, empty promises.

    Brands-Hatch? When-- in 2020? Kunos cannot be trusted, it being always that way.


    Alan
     
  4. Minolin

    Minolin Staff Member KS Dev Team

    S01E05 had nice preview about the current plugin system:

    The auth plugin is not handled via the "usual" two-way UDP interface, but directly calls a webpage (that of course can be generated by a local plugin). Screenshot of the config file from the livestream:
    upload_2015-7-19_11-4-15.png

    His sample webpage for authorization looks like this; If the auth fails the server redirects the error message to the client.

    upload_2015-7-19_11-5-7.png


    Sample "session started" UPD message:
    upload_2015-7-19_11-8-29.png

    The plugin can register a realtime report (for car X with resolution N ms).
    This is pretty huge and looks well done. Cutters-server-edition could instantly be done based on this.
    upload_2015-7-19_11-11-53.png

    Send chat message to client or to all. Wow. Whispering and personal information/warning incoming.

    If I understood correctly the plugin can decide wether a lap is valid Oo

    The messages are encoded in UTF-32.
     
    Last edited: Jul 19, 2015
  5. Stereo

    Stereo Alien

    No, it just reports whether the user cut during the lap, so the plugin can use that info if it cares whether laps are valid. (eg. if RSR was server side)
     
    Minolin likes this.
  6. myimac

    myimac Alien

    Wow....

    I am having a blast racing, not just driving.

    Today 1.2 is locked down and beta testing will continue before releasing.

    Educate yourself on where things stand before slinging mud.
     
    Eero likes this.
  7. Minolin

    Minolin Staff Member KS Dev Team

    You raised several important points.

    UPD redirector
    After what we've seen today I'm pretty sure the redirector would work fine. The only real synchronous call seems to be the Authorization, and this one is solved in a special way. But this one could also be redirected, but we'd need rules for a) timeouts and b) a convention what happens if A says "yes" and B says "no" and C says "no" with a different reason.
    We'll buy a bit of overhead, but local, non-blocking UDP shouldn't be that evil if we don't get a lot realtime reports with 1ms resolution. But what we buy is a necessary runtime again, which leads to...

    Language independence
    Staying on UDP only is very nice because every plugin-author can use whatever language he wants. But this is resulting in three further problems:

    #1 Binary vs. scripts
    Was a topic inside the Python->C++ discussion: If somebody would do a native C++ plugin, there's a lot trust and danger involved. Easily decompilable java or .net binaries aren't that big threat, and so on.
    But honestly this is probably not comparable to client apps, server admins shouldn't be so clueless about what they do as the average joe.
    Still a bit scary.

    #2 Runtime requirements for different plugins, admin overhead
    Imagine there are 5 top-notch server plugins you really want to use on your server (plus the redirector). They are written in python, native c++, ruby, java and .net.
    You'd need to install all of the runtimes and prerequesites. And - until we have managers for that - you may have to start 8 programs for a single server (5 plugins, 1 redirector, 1 acServer, 1 sTracker).
    Server admins out there, how is your view on that?

    #3 Heterogeneous code available
    Also a good point in the Python->C++ discussion. The point was that the advantage of .net (having C#, VB, C++, F# syntax) could easily be a disadvantage: We'd have different apps, tutorials etc.
    It would be more difficult - especially for beginners - just to read "how did he do this, and what did the other guy there" or even just copy&paste cool code. If this is true for the syntax inside .Net, it's even more valid between C++ / .Net / Python / Ruby / Javascript / ....
    In fact Stefano does us a favor when restricting to one language. But on the other hand the good programmers may have their environment they are used to, and are *much* more efficient there. Probably there are also python apps that never have been written - because of python (insert whatever you aren't that familiar with).
    Of course there's not much we can do about it. Giving the options is wrong, committing to one decision is also wrong, just in different ways.
     
  8. Hey, I'd think that redirecting the AUTH requests wouldn't make sense (you could do that inside the http servers, if really necessary). We might loose some realtime-message semantics (e.g., plugin 1 registers at 1 Hz and plugin 2 registers at 10 Hz, probably both would get messages at 10 Hz?), but yeah, otherwise this should be quite easy.

    #1 I'd think that the server admin should decide whomever he trusts or not. Honestly this is the same for all the languages. It would be very easy to inject malicious code in current python apps if you really wanted to. I bet that this would survive for a very long time before getting noticed. Same for whichever computer language you are using unless you restrict its functionality in a sandbox.

    #2 Should be easily managed by using starting scripts, shouldn't it? I suppose most servers are already controlled by some web-service tool... Talking about stracker, this is a python app compiled into an executable; the system requirements for it are quite minimal (on windows, it is a VS runtime environment package most likely already installed). [off-topic: Unforntunately I am not very keen on rewriting stracker in another language...]

    #3 I think what there will be language bindings available after the UDP protocol is out. Stefano has announced that there will be a c# example from KS, and I'm sure that *someone* will release a python binding as well soon ( :D ). If the bindings are minimal and complete, the difference between the languages are not that huge, I presume....
     
  9. What is really missing in the current server API, are the normalized spline positions of the cars additional to positions and velocities. I'm also not sure what the cutting detection would look like. Will it work only, if the server has penalties enabled? That would be a pity...

    I'd love to ask @Lord Kunos myself, but unfortunately google live streams are not accessable from Germany (because of some stupid german laws).
     
  10. Minolin

    Minolin Staff Member KS Dev Team

    Oh I think so. Imagine the admin wants to use the following inputs:
    - the central blacklist of theautomotivemayhem.com/blacklisted.txt
    - a minimum acRating from RSR live timing
    - a minimum safety Rating from raceme
    - his personal, conventional blacklist

    This isn't that far out, is it? It made sense if they would be simply combined as "AND".

    Good point, didn't see that. Honestly I also didn't have direct registration in mind, but more a more-or-less realtime cache. But yes, if we have plugins that need really high resolution this is gonna be ... funny. (Could imagine that the server-sided-replay-builder needs high frequency. Situation-analyses like cutting are difficult as welll)

    For me, it's a huge difference in the question "can I trust him" if the developer can effectivly hide functionality. It's much easier to trust someone who's code can simply be read (like scripts); reading a .net assembly is almost as easy with professional tools. In fact I've read most of the python apps I use. I would never do this for something I'd have to de-assemble, and there is no hope someone else does this for an game related mod.
    But ok, I know how alone I am on this opinion, so do whatever you want :) I'll just keep on things I could use for myself.

    Funny that you note the web-service-controllers and ptracker. To get sTracker working on a widespread server platform there has been extra programming only to get sTracker working well. This isn't something you want be done for every single plugin ;)
    But yes, managable. I really hate process handling across windows + linux, but I'm confident we'll find someone who is good there. Still something that can be simplified by running plugins inside one plugin-process.

    But yes, you also mentioned the other side of binary files: Just a OS-runtime that is probably there and you're good to go. And btw. you'd be stupid if you rewrote sTracker. As you said it'll be cool if you just wrap sTracker into a plugin that can avoid some workarounds.

    Disagree about the differences in the implementations, if not done with the same concepts in mind. I don't think we'll get more than "this is how you get and parse a string message out of a UDP message in C#". The resulting designs will be very different, even inside one language. This isn't that bad of course, but a newcomer basically starts with zero or one template.

    Was my first thought as well. The SplinePos is incredible useful and used by a majority of apps for different purposes. I hope this is one of the first additions to the UDP talk.
    @Lord Kunos might we already report this as a bug? :)

    *handshake* :(
     
  11. Stereo

    Stereo Alien

    Fairly easy to write a service that'll do that for you, right? if you have aggregator.com/lookups?steamid=xxx&sr=4&services=tam-blacklist,rsr,raceme&aggregate=AND or whatever, as long as the other services ok your bulk page requests it'd work fine to just send them along minus the aggregator tags, and then merge them back together. If you've got a 'global safety rating' server it's a pretty easy service to tag onto requests to it.
     
  12. Minolin

    Minolin Staff Member KS Dev Team

    Possible, yes. But just another managed piece that must be hosted/payed and who every new contributor (more every new model of contribution) has to be implemented. Who manages the aggregator? Who decides, if the TAM blacklist is worth, but not the martcerv's one? Same for RSR vs. Rivali vs. the-next-new-acRating, and so on.
    I'd prefer different plugins (they would be trivial) that the server admins can plug together as they wish. (at least if we manage the "simply plug together"-part in a reasonable way)
     
  13. Stereo

    Stereo Alien

    Well, naming them is just a matter of convenience; the url could just as easily contain their base urls url-encoded, like radiator%31springs%30com%25107%22 or so on, and be able to form the requests with 0 knowledge of the site.
     
  14. Yes it makes sense, but does it have to be a part of the discussed redirection plugin? I'm not sure about this, but otherwise a simple AND connection wouldn't introduce too much logic...

    I'd like to summarize the requirements for the redirection plugin so far (from my point of view, please correct me, if you disagree):
    1. The redirection plugin shall provide an interface just like AC server does (i.e., based on UDP with exactly the same semantics), but should allow multiple connections (further called clients). The difference between connecting to the original AC server or to the redirection plugin shall be as small as possible.
    2. The connection targets and sources shall be configured either by an .ini file or by command line arguments. The configuration consists of addresses to send messages to and corresponding ports to listen to for incoming requests.
    3. State-less (e.g. kick_player, ...) requests from clients should just be redirected to the server.
    4. Requests requiring a state shall be redirected to the server, but the redirector needs to keep track of the requests (to provide proper responses with the same semantics than original AC server). This is true for the following requests:
      1. Request realtime tracking messages at a specific interval. Note: The requested interval might be changed; we may decide to accept powers of 10 only (100 Hz, 10 Hz, 1 Hz, 0.1 Hz).
      2. ??? (unclear yet)
    HTH
    Neys
     
  15. Minolin

    Minolin Staff Member KS Dev Team

    Sounds good.
    Do you already see reason to say "shall be as small as possible" instead of "exactly no difference"?

    Indeed a tricky one. Needed a thought to realize what your suggestion is: You want to force the plugins to request specific intervals and then keep track of "when to broadcast this to plugin X". Good idea, especially towards CPU usage. [Edit: clarification]Otherwise it could get really messy if every plugin needs to receive high-resolution updates to a full field of drivers. This requires the server beeing singlethreaded, but I'm pretty confident this is true.

    Hehe but you also start defining the intersection between a simple UDP bridge and core functionality of my plugin-manager suggestion. My idea was that the manager (or redirector) consumes the reports and builds a cache of information, that can be accessed pretty much like the carState stuff in the python API - no mess with broadcasting and routing around. Resolution and cache size could be configurable by the admin, something in between hardware resources and plugin requirements.
    Main motivation is to be able to do things that are used by multiple projects once; especially true for nasty hacks.

    Either way, we should consider if the addons may chose their update interval or just get the highest resolution available. I'm pretty sure tracking the timing between two messages will be important anyways.


    Further recommendations to discuss:

    - How do you think about the ability to start/stop the acServer executable? Regarding those web control panels, they want exactly 1 executable to start and kill
    - The code should be a) blazing fast and b) executable with (almost) no preparation on windows & linux. Both calls for binary files like C++, C or Go (or compiled python?), but then again there is this issue about security.
    - The redirector would be a single point of failure in the future plugin structure; best solution would be an opensource project where Stefano is (inactive) project admin
     
  16. Yeah, the realtime messages would behave slightly different because the interval cannot be chosen freely (plugin A wishes 10 Hz, plugin B wishes 15 Hz would be quite complex to solve, in this case giving both 10 Hz would be fine from my point of view).


    Why is a single threaded server required for this? I'm pretty sure this is not true :)

    This would be the other route we could head to: Introduce another API upon the existing one (Interface could be SHM together with TCP connections).

    Pros:
    - could probably be implemented more efficiently
    - workarounds could be applied directly to this layer

    Cons:
    - we're getting the "one-plugin-only" problem, if someone decides to build his app upon the original API

    [I hope that the amount of necessary workarounds would be much lower than with the python API.]

    Hmm - it would be not that difficult set up a python service which starts all the tasks necessary (including the ac server) and kills them when the service is killed. Should be more or less portable (minor tweaks might be necessary for linux/windows support).

    Python is not really the tool to use here (though it could be a quick starting point :) ), so probably it should be C++ or Go (if anyone has the skills). +1 for opensource. +1 for getting Stefano into the boat (in whatever role).
     
  17. Minolin

    Minolin Staff Member KS Dev Team

    Shouldn't be a problem in any case; I'd encourage every plugin developer to write the code in a way it's simply not important in which interval (and irregular) the data is coming in. Sure, there will be a threshold per plugin to be still useful (like cutters can't work below 1 Hz because almost every clean corner would be detected as cut), but it shouldn't hurt if the interval is much higher than required.


    Ok, this was shot too fast. Of course the server will accept incoming messages asynchronously, but I have the feeling (nothing more) that the broadcast to the clients is snychronized. You think it's not?
    But yes, the UDP-data is probably taken off the incoming message, so asynch. Uh, that would imply that we have to add lag to the timing. But then my other thought doesn't make sense and I'll take back the "is required".. This might get pretty interesting then.

    Efficiency:
    How important/significant is the efficiency? I have no feeling about the CPU load we're gonna see. Usually this shouldn't be an issue, but we're talking about >20 cars with maybe 10+ Hz.
    If we ignore that for now (textbook says don't tweak performance until you need it), there will be zero chance to reintroduce this layer later. This would be like if I come and say "hey neys, I've got a decent anti-stutter framework, wanna rewrite pTracker?" ;)

    Workarounds:
    Much stronger point. If we hack something in a really ugly way, things happen:
    - plugins will use the function
    - we can point stefano to that stuff and demonstrate which plugins already use the new feature
    - he can improve the UPD part, next redirector-version uses this instead of the exploit

    One-plugin-only
    Absolutely :(
    Maybe we have 8 plugins next year, that would have loved to work inside a API-API. Maybe we're splitting the market apart with 3 exclusive API-APIs, where every single one has it's own outstanding plugin.


    Right, isn't a big number. I'm just asking if it's worth to separate really mandatory things or just say "hell yeah, you'll need that starter for using plugins".
    I can easily expand my AcServerWrapper. Just should check in the latest sources. -.-

    Go could later be intergrated into the acServer if Stefano likes it :) But honestly I'm not sure if I want to do this as my-first-go-project...

    Anyway, thanks for your time. We're developing more questions than answers, this means we're on the right track.
     
  18. f_deutsch

    f_deutsch Hardcore Simmer

    I just hope that

    • We got proper documentation and code samples to initial take off development
    • Hope programming language choose will not be C++. Python, C# or even Go (which I would have to learn) would be OK
    • Have myself enough time to be able to implement something

    I think we are over speculating a lot of things. We should wait and see what go got to start with. For the only one plugin supported. If this is the case we probably could have one plugin to recast all data to other plugins, like a plugin bridge, LOL.
     
  19. Minolin

    Minolin Staff Member KS Dev Team

    The Lord was so kind to let us preview his demo-plugin, have it attached, but

    DISCLAIMER
    Please realize that this is no commitment or anything else than a WIP tech demo to give us an imagination of the current thing. Nothing is set in stone and could literally change or disappear never to be released.
    It's also just dropped as-currently-is, so it might not be as polished as a final version.


    So please do not build expectations or anything else against this.




    I'll try to find some time to create a fake-acServer with this example, so we have something that could behave quite similar to the 1.2 server. This fake-Server can be the playground for some redirector-prototypes with Go and C++.
    Btw. Go is really strange, wtf. Probably cool, but if you just open the first asynchronous UPD-tutorial ...
    [​IMG]
     

    Attached Files:

  20. Praise the lord :D
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice