Add truck stops

[sebamarynissen]

This PR adds a bunch of truck stops.

I've had to split up a lot of packages in resources and lot parts because the American Truck Stop has an insane amount of dependencies. I was thinking that maybe this kind deserves a separate subfolder category, like 110-shared-resources or something because 100-props-textures doesn't cover the purpose. For now I've put all these resource packages under 100-props-textures.

This PR also relies on a few dependencies that @Zasco has added in his own channel. I'll let the GitHub action fail and have it find out which ones I still need to copy over.

[sebamarynissen]

Apparently the only dependency missing was w-swietwoot:dutch-prop-pack.

[Zasco]

This PR also relies on a few dependencies that @Zasco has added in his own channel. I'll let the GitHub action fail and have it find out which ones I still need to copy over.

I'm not sure having the default channel depend on other channels is a good idea... It is expected to remain maintained as long as sc4pac is, but other channels have no garantee on that. The default channel should be complete in itself.

[sebamarynissen]

@zasco Yes I agree, that's why I added the missing package in this PR as well. Once it gets merged, you can deleted it from your channel.

[sebamarynissen]

By the way, probably this is not the right place to discuss it, but speaking about other channels, I was thinking that for me the ideal situation would be that the big exchanges (Simtropolis and SC4) host their own channels that update automatically when new content is posted. More specifically, when someone uploads a new file, they should get the option to immediately write the yaml metadata for it that when published immediately becomes available in the exchange's channel.

The exchanges might not even need to implement all of this themselves, I can imagine an approach where they just call a server endpoint with the new metadata that then compiles it for them and returns the compiled metadata somehow. The only thing then is that those channels might depend on one another (ST metadata referring to packages available on SC4 and vice versa). I'm definitely willing to help here. What's your take on this @memo33 ?

[memo33]

@sebamarynissen I'd love that. It would give the original plugin authors direct control over the metadata for their files.

My main concern is how much work this will require from the admins of those sites. They aren't necessarily programmers and I'm not sure if this is asking too much. The sites are mostly black boxes to me, so I'm not sure how much we can assist from the outside.

The second concern is that writing correctly formatted metadata seems to be quite difficult for many people. @noah-severyn's editor can be very helpful though. Perhaps combined with an automated check whether the metadata compiles (this could maybe be integrated into the GUI).

That said, a basic approach for such a system might even be:

• plugin authors upload an additional .yaml file on their STEX entries
• a server runs a nightly build script, finds those newly added .yaml files using the STEX API, downloads them and builds the channel.

(It's a bit more complicated due to download limits, the lack of my own server and the fact that uploading a .yaml file to the STEX would alter the timestamp for that entry which in turn cannot be part of the .yaml file itself, but those are details.)

Edit: Discussion moved to #49.

[memo33]

By the way, I'm going to try to review your PRs in a few days.

[sebamarynissen]

Take your time, there's no rush from my side. Just know that my scraping scripts are now in a state that very little manual intervention is still needed, even for the descriptions and dependencies, so you'll probably see some more PRs coming in from me in the following days. :)

Btw, I'll create a separate issue to discuss the exchange-specific channels. If you could move your comment to that issue, then I'll reply to it there. Keeps this PR clean.