[Reference] Vehicle files (On-hold)
Edit: Due to the completely unreliable sources of information regarding the data for this file, I am putting it on hold for a short period of time. Until this data can be further verified, I cannot consider this file as anywhere near the reliable source of information I originally hoped it would be. I am therefore going to conduct further investigation before I add anything more to this thread.
I don't know if this is of any use to anyone but it was a by-product of something I am toying with and thought someone might find it useful (or not). It's basically the output of a tool I wrote that has parsed all 44 vehicles.meta files in the game and created an alphabetically sorted list of names/make/type and class data... 460 lines of it to be precise.
I have now added the modKitID values based on what I think is the correct number. I have also TAB formatted the file instead of SPACE formatting it, so it is a smaller file. I just can't display the data in this comment, so I have included a screenshot instead.
The top five lines for instance look like this:
Or I have this one that is just an alphabetical list of the spawn names.
It might be of no use to anyone but me, but if someone wants it, it's there for the taking.
@LeeC2202 Good job! It's useful, and maybe you can expand it more, adding which ID for Tuning Parts is using each vehicle, or also to add the path where is located each vehicle, and more. I can give you more ideas to complete the list and make it a great resource for people (this would simplify a lot our life, literally ), really like that
I've practiced something a lot similar last month at my institute (studies) for a homework, and I can guess (if I'm not wrong) you used something similar as BufferedReader's / BufferedWriter's or any other method to copy/paste the desired info and LinkedList's to order them alphabetically in java (I'm at that stage of learning, Collection objects, etc.).
Wrote something similar ages ago for R*acksmile , very good
@Reyser why java
@Reyser It's just a simple XML reader into a SortedDIctionary that then outputs either a block aligned text file or a simple text dump of one parameter. I like writing simple tools that process data into usable formats. It's in C#, that's my language of choice when it comes to most things.
More often than not I do nothing with the end data, it's just something to pass the time and to remind myself of how certain things work... I've never had a complete list of all the spawn names, so part of this was driven by simple curiosity. I didn't expect there to be quite so many vehicles, I must confess.
But yes, in theory I could cross reference the whole meta set and build a kind of database of vehicle info. I'll take a look at some of the other files over the weekend. Now that I know OpenIV will output every instance of a single file-type, it will be easy. With this I just dumped every vehicles.meta into a folder, OpenIV handled the renaming during the export, then this tool parsed the whole lot in one go.
@Frazzlee Because in the course that I'm doing at my institute everything is related to Java or Python.
@LeeC2202 Seems easier in C# (I don't have any knowledge about this language yet) than in Java. Would be great to have a single files containing all handling.meta and other meta files content, everyone could take a look at these files without the need to search into every individual in game files, so if you can do it
@Reyser Thinking about it, having single files containing all that info would also go someway to me making my addon-creator tool. What I will do over the weekend, in-between everything else lol, is I will create a folder for each meta type, extract all the files of each type into that folder and then adapt my tool to process each file type, looking for certain data, or simply to combine all the files.
The main problem comes from the file having nested elements that are the same names. So like in vehicles.meta, I thought I could extract each item based on the
<Item/>element but you also get that element nested inside, so I need to add some kind of stack management for that.
I'll have to tackle each file type over a period of time and see what I can do with it. One other problem, is because OpenIV extracts and renames them, I have no method of determining which versions of the file are newer than the others. I can't guarantee that the file it extracts last, is actually the latest file... that's a significant problem.
@LeeC2202 Promissing, but yeah there are a lot of elements with the same name, that's one of the main reasons why people have crashes when they try their own Add-Ons.
As we know which's the structure that have those files, maybe you can add an statement to keep your program extracting each of them until it founds the last necessary
</Item>for a block code (As example, in carvariations.meta before the
</Item>tag there's one called
<sirensettings>, so you can use something like that as condition).
About file versions, OpenIV change their edit date? If yes, that's bad to found a fix for this problem, because always will be newer the file extracted than the other one.
@Reyser In this tool, I get the end of each item with
if (reader.Name == "firstPersonDrivebyData")because that's the last element before a new
<Item/>element starts to define a new vehicle.
But if you're combining files, you need to process every instance of that
<Item/>element to rebuild it in the new file, so they have to be managed on a depth basis.
And yeah, OpenIV creates a new file, so any existing data that relates to creation time/date is gone. To give you an idea of how that affects things, the handling.meta from the mpimportexport patch is the 11th file out of 28 that would get exported.
@LeeC2202 That's exactly what I had in mind to get every vehicle block code.
If OpenIV just export the entire file without the need to create a new one, would be much easier (Maybe a suggestion for OpenIV team??). I was trying to find a way to extract content from a RPF file with their original creation/edit dates but didn't found anything
@Reyser It has to create a new one because it has to extract the data into a file that doesn't exist. That's the downside with file streams, they're not files as such, they're just data streams that have to be given a location to be streamed into.
The only way to do it, would be to manually extract and rename every instance of the file, to make sure they were dated correctly.
@LeeC2202 Oh ok, I thought they were also data "files" as when you add them using OpenIV. Do you think your program could do the extract/rename of every instance before the process?
@Reyser No, it would have to be done manually. It would take 10x longer for me to even begin to learn how to handle rpf files, never mind being able to search every one for the right file types, deal with the decryption and then extract and rename them.
@LeeC2202 Sad, will be a very long process, but well if it's the only way... Anyway do your priority mods before, don't worry about this if you have something in process.
@Reyser It won't be too bad doing the extracting. For most files, there will only be one per patch update, so for example, there are 28 handling.meta files. It will only take a few seconds to manually extract and rename each one, I will just need to find a chronological list of all the updates so I know which order they came in.
Folders like patchday1ng etc... are self-explanatory but the mp... ones are more difficult. The bulk of it could probably be done in an hour (that's all the files, not just handling.meta), I might do it all later to give my brain a rest from coding.
@LeeC2202 At this website you have a list with the name of each DLC (Ordered chronologically from bottom to top of the website).
The MP folders usually have the name of the dlc itself, but some not (like MPJanuary). To know from which DLC are each one of this folders, the easiest way (at least for me) is to see which cars have every folder, and compare that info with the DLC's information at Grand Theft Auto V Title Update Information.
And yes, give your brain a rest ^^
@Reyser I've just noticed that while the patch folders all have the same time/date stamp, the dlc.rpf files inside are the original date/times, so that makes things easier.
@LeeC2202 lol I didn't realize it, I'm blind
@LeeC2202 you might wanna change your bio, if Christmas was what you were referring to
good show, i wish you could easily identify using a method like this which modkit_id's are in use by the vanilla game
@Frazzlee I could do but it works all year round and I can't think of anything better to put there. I have all sigs hidden so I couldn't even remember what it said.
@Reyser You know how I said this would be simple... I lied.
For starters, those dates are messed up. patchday8ng is 2015, patchday3ng is 2016...
Doh! @Akila_Reigns, you're a genius. I'm not even going to guess what prompted the question you asked me, but it has taken me two hours to realise you handed me the answer I was looking for.
The setup2.xml file is timestamped, every dlc.rpf has one, therefore setup2.xml provides the exact timeline for every dlc patch folder.
@LeeC2202 Uh , so starters have different dates than us on their dlc folders?
@Reyser Actually, I am now 100% certain I have 0% idea what is going on. I was convinced that the setup2.xml idea was onto something, then I see this:
patchday1ng - 23/10/2014
patchday2bng - 23/10/2014
patchday2ng - 23/10/2014
patchday3ng - 23/10/2014
Now I'm not so sure... this is a real pain for what should be very simple.
@LeeC2202 oh haha