[TC] Gaming Forums

Hello there,

Would anyone be interested in learning to code using the [TC] API?

I'm thinking anyone who's new to programming who is maybe lacking any ideas and wants a place to start, or someone who maybe isn't sure how to get started with working with an API.

If so, I'd like to know because it might be a fun way to start building up some useful applications that use data from the [TC] servers. Plus people get to learn a skill along the way.

I've been thinking about a couple of starter projects I'd like to do with NodeJS, PHP and ReactJS. If this idea sounds interesting, let me know below.

Hey,

I'd be interested, with mainly PHP, as it may help me pick up some skills that I can use in the future as I'm currently learning it at the moment )

Evening Pete,

I know quite a bit of PHP but building something useful which utilises the [TC] API would be good! I think other people would appreciate this project as well!

-Kyle

Hey, I'm a bit of a programmer myself, but mostly Python and C. The [TC] API is pretty cool, and I've made a short python script that constantly pulls the # of players so I don't have to sit at the server list for ages. I'd love to integrate it with an InSim that joins the server when told to, but IDK if that's possible? I also have some pretty cool ideas for integration between the API and InSim, like choosing a player to chase instead of the nearest one.

Also a pro-tip: many people and businesses are moving away from PHP in favor of things like Golang and Node, so if you were to do some tutorials I'd start with Node

(2018-12-25 17:52)kxait Wrote: [ -> ]I'd love to integrate it with an InSim that joins the server when told to, but IDK if that's possible?

The LFS Command "/join" can be used to do this!

e.g: /join [TC] CityDriving One
or whatever. Send this with an InSim packet and you're sorted

(2018-12-25 18:04)Kyle Wrote: [ -> ]

(2018-12-25 17:52)kxait Wrote: [ -> ]I'd love to integrate it with an InSim that joins the server when told to, but IDK if that's possible?

The LFS Command "/join" can be used to do this!

e.g: /join [TC] CityDriving One
or whatever. Send this with an InSim packet and you're sorted

That's definitely possible, but not reliable since there's no reliable queuing mechanism, LFS has join spam protection and the API is cached.

---

kxait Wrote:I also have some pretty cool ideas for integration between the API and InSim, like choosing a player to chase instead of the nearest one.

It's not currently possible. The API is currently for read-only functions.

(2018-12-25 18:37)Pete Wrote: [ -> ]That's definitely possible, but not reliable since there's no reliable queuing mechanism, LFS has join spam protection and the API is cached.

I thought of getting the player # from the API very frequently and then joining when there is a free slot (assuming the API reports the player # accurately)

(2018-12-25 18:37)Pete Wrote: [ -> ]It's not currently possible. The API is currently for read-only functions.

I meant getting the cars from InSim and then using a command with a player name parameter to choose who to chase, not using the API (would require server update)

(2018-12-25 18:47)kxait Wrote: [ -> ]

(2018-12-25 18:37)Pete Wrote: [ -> ]That's definitely possible, but not reliable since there's no reliable queuing mechanism, LFS has join spam protection and the API is cached.

I thought of getting the player # from the API very frequently and then joining when there is a free slot (assuming the API reports the player # accurately)

(2018-12-25 18:37)Pete Wrote: [ -> ]It's not currently possible. The API is currently for read-only functions.

I meant getting the cars from InSim and then using a command with a player name parameter to choose who to chase, not using the API (would require server update)

It's still not possible to use a command to choose a player to chase.

You can get the accurate player count, but there's a 60 second cache.

I'm more interested in doing some Node apps, rather than PHP to be honest, but if others want to do PHP, that's fine.

(2018-12-25 18:48)Pete Wrote: [ -> ]It's still not possible to use a command to choose a player to chase.

Yes, I know, just a suggestion.

(2018-12-25 18:48)Pete Wrote: [ -> ]You can get the accurate player count, but there's a 60 second cache.

Well, with a minute of delay this wouldn't really work that well. Any plans to make it more real-time?

(2018-12-25 18:48)Pete Wrote: [ -> ]I'm more interested in doing some Node apps, rather than PHP to be honest, but if others want to do PHP, that's fine.

Node is clearly the way to go here, even when a website is needed

(2018-12-25 18:56)kxait Wrote: [ -> ]

(2018-12-25 18:48)Pete Wrote: [ -> ]You can get the accurate player count, but there's a 60 second cache.

Well, with a minute of delay this wouldn't really work that well. Any plans to make it more real-time?

The online list is actually on 10s cache at the moment, but we could look to reducing that.

I started working on a React front end for an API playground so people can easily create and test API queries. Hopefully I'll have it ready by tomorrow so I can write a tutorial and so you can actually start using it to get the data you want.

The plan is to build an API playground so that people can get up to speed with creating API queries. Then, you can use the code I wrote to make the API playground itself to write your own React applications that use the API. I've essentially killed two birds with one stone here.

Here's how it looks so far:

In order to build the playground, I needed to build an API specification which lays all of the endpoints out logically so that I can present and query the list of APIs, their mandatory and optional parameters and other information. Usually you write these specifications in JSON. Once this list is populated, I can write a parser to output the information I need on the playground app.

It took a while to come up with a sensible structure that doesn't nest too much. There's a fine balance between this structure being too flat, or too nested. If it's the former then your parser will likely be more complex whereas if it's the latter, the specification itself can become a confusing mess. This seems to be the best option right now:

And here's a draft of the v2.0.0 API schema: https://gist.github.com/PButcher/059b2ed...9bd799eae7

It's a draft because I might hit bugs when I write the parser tomorrow.