My big, dumb idea about custom skins and params

Suggest, discuss and store new and old Tools.

Moderators: Huki, jigebren

My big, dumb idea about custom skins and params

Joined: 11 Sep 2013, 16:47

16 Feb 2017, 10:41 #1

Ugh, you're just reposting this stupid skins changer thing again aren't you?
Not entirely. This thread is meant to include more information, and to simplify the understanding of my idea without actually doing any code, pseudocode (since hey, I'm not a developer but I like to think about this kind of crap) or topic bloat with including extensive examples (because it would be an OP ten pages long otherwise).

Just because I know people won't bother to read to the end of this anyway, I'll skip ahead to the good and bad of my idea;

Intended solution results and potential issues
What this should do
The end result of this idea is to make it easy for people to author repaints and reparams, while at the same time allowing people to mix and match skins and performance to go for a look and feel the end-user is after. This implementation is intended to reduce the number of folders in ./cars so users can have a more manageable cars folder, with modifications being in the same folder as their target vehicle, making it so the game considers these repaints and reparams as dependent files requiring the original content, and allowing for users to keep content they wish to share separate from content for their personal collection or beta work.

For users to exercise their creativity and make things for what they have without interfering with the author's original work or appending onto it directly, the capability for a user to add their own files named independently from an author's work would provide a degree of separation between an authored creation and a end-user creation.

...And it can totally be submitted as an original work later with tweaks to the filenames so they're different from other works only available to the local user, and so people playing online could get it, too.

What problems this may cause
Considering the naming method is completely different from what a user of Re-Volt should expect, this may cause significant confusion for users old and new, even with sufficient explanations provided in this thread. While online distribution is nice, it would also incentivize people to be horrible trolls by using an author's indexing scheme the game by presenting the opportunity to have explicit imagery by a malicious user, and needs further refinement to ensure that users do not become malicious with their content by either trolling others with their own original work or ruining an author's reputation with their own nonsense.

The same problem of mismatched skins will still happen if people choose to keep their own content to themselves as files for the local user only (not to be distributed online), but that is a choice for the end user, and it should be exercised for beta work, while allowing the user to race online with their beta work. User parameters is also another, more significant issue but this is already a problem with users being able to modify parameters and become cheat cars that go faster than their peers.

There is also the problem of the skins and params falling a bit short without hackish workarounds for the issue, such s using a skin with a different vehicle's UV map. This is unavoidable, but it is also why user preferences should be a thing.

Naming scheme (once again)
The intent of this naming scheme is for RVGL to intelligently handle skins and parameters separately using the filename, so no special parameter variables are required to define the file as such This is also intended to influence online availability, provide shorthand names for what each vehicle the file belongs to, and make it less tedious to create these files for authors, especially if there are a lot of them.

What the letters should mean
The below will be used in the following examples;
s: Skin (Models, texture, shadow, envRGB, spinner, aerial)
p: Parameters (frontend display, Speed, weight, handling, AI, carbox, s)
u: User preferences for s (us) and p (up); Not usable online.
foo.x: "foo" being anything, "x" being s, p, us or up
foo.xn: Same as above except n meaning any number from 1-255
Corrected from earlier; I mentioned foo.x.n when the below uses foo.xn

An example using original works
Let's say for the sake of argument that The Me and Me published their K22A Virus with different colours. (The vehicle doesn't come in different colours but let's say anyway.) These colours are red, yellow and black. And they come packed as the following;

Code: Select all

For each file, since there is no change in parameters, all that is needed are the skin files. They are provided as such;

Code: Select all

It doesn't matter what the order are, so long skin files 1, 2 and 3 have different appearance properties defined. So, 1 could be red, 2 could be yellow, and 3 could be black. When at the selection screen, the user is allowed to cycle through these skins, and RVGL, by virtue of the skin files being with the car they belong, knows already they are for the K22A virus, and will use them only for that car.

For repaints and reparams
On Re-Volt Zone, there is a repaint of the K22A virus by FireBlade_2049 called Xtreme Green. I will assume for sake of argument the vehicle is faster than The Me and Me's K22A Virus. All the author needs to provide are a few files (and the author can name the files anything, really, so long RVGL knows it's a skin and param);

Code: Select all

No numbering order is needed because RVGL will know there's only one skin and parameter file for "Xtreme Green". The parameter file by default will load the Xtreme Green texture for its appearance, but since it is a separate file, the K22A Virus can also use it, and the K22A Virus bitmap can go to Xtreme Green if a user chooses. Now, the filenames change if an author wants to provide multiple repaints;

Code: Select all

xtg.s2.txt can load the other texture included, xtgreensolid.bmp which would just be a solid green colour available alongside The Me and Me's red, yellow and black colours if one doesn't want the rather garish paint scheme Xtreme Green uses by default.

Let's say I want to release a modified version of the K22A Virus model with hood scoop and spoiler called K22A Tuned. I would need to release a separate parameters file for it, but if I am careful in how I skin the scoop and spoiler, the colours from K22A Virus and Xtreme Green can be compatible with it. I could release a "Stock params" version of it, and a faster version called "K22A Tuned Xtreme". here would be my files;

Code: Select all

In my parameter files, I would need to exchange the default .hul file with a .hul that is for the K22A tuned, so that can reside where the default hull.hul is and be used only in my parameter files. I would also need to define in the parameter files the model i want to use from ./misc so it loads correctly, and appears as a part of the vehicle.

...And it'll still be selected under "K22A Virus" because everything else for it is dependent on that vehicle.

How the game may end up using these files
With the file naming scheme and files in place, We're ready to talk about how the game could implement the files. The core reason why there are separate skin and param files is so the game can load only the bits that are relevant to the combination of parameters and skins. RVGL can load the initial parameters file (parameters.txt), or if the game detects a p file is used instead, use that as a base, and apply on top of it the contents of an s file by completely ignoring the parts of the parameters file defining a skin. User skins and user parameters are placed last in the vehicle's list of skins and parameters, but they are treated the same.

Skin and parameter files with text before them (Picking from the previous section as an example, xtg.s2.txt) are sorted by alphabetical order. This is why having them differ would matter, as the game would sort skins bothalphabetically and numerically. When the game loads it will use whatever mix of parameter files and if there is no skin assigned in the parameters file itself, pull from an s file inside the car's directory it is trying to load from, or use the skin defined if it chooses to load from a p file.

So why the stupid name stuff in the first place?
For limiting how the files can be used, and to have a clear distinction from Re-Volt content vs. RVGL content, a radically different naming scheme would certainly prevent the file's use in Re-Volt. If users want it to work in Re-Volt 1.2 and lesser so badly, they can manufacturer their own parameter files since nothing about them is different except parting them out to two different types of files, and the p files can also have their own skin and such defined anyway, there really isn't much work for the end-user to perform in order to have whatever magic they're trying to conjure happen.

That's stupid.
What's also stupid; The game not being able to readily use high definition files unless they're named as .bmo, .bmn and .bmm files. But nobody complains about that now, do they?
I occasionally make stuff at Re-Volt Live. Come and check it out some time.
Traitors deserve the monsters they make.

Join us on Discord!

Joined: 28 Sep 2017, 21:54

01 Oct 2017, 21:15 #2

Why not a separate application?

As for CHT cars, you can have the client send a md5 checksum of their parameters.txt file to the host, then an autokick for unmatching codes could be in place... a CHT host would kick everybody, but hey, not our problem XD