Log in to reply
 

What type of hash generator OpenIV is using?



  • I want to convert a hash to name but unfortunately OpenIV only has the option to convert the name to hash :(

    I have looked a lot of hash generators, ascii converters, hex stuff but none of them is giving the same result with the OpenIV's.

    Can anyone tell what type of code it's using so I can look at it and hopefully find a website that can also convert from hash to name as well <3



  • @Aurora11 never had a need to do that. Normally convert crack or heroin to name, but never hash,

    What about this tool?

    https://www.gta5-mods.com/tools/hashtool

    Are you converting peds, vehicles, or methods/functions?



  • @Aurora11
    It's Jenkins hash GTA V uses, but the issue you will run into is that any given hex hash can have an infinite amount of text alternatives/collisions:

    Example: (this is nowhere near the full list for hash_E03115BB/0xE03115BB by the by, just a few of them. 'vigero_engine' is the correct one etc)

    Hex Hash Collision

    Maybe try Hash Collider 0.5.0, I've never used it properly (other than look at it the now), but I would reckon that's probably your best shot.

    HashCollider Basic Usage Instructions:

    HashCollider

    That's^ just the basics, you might find other methods fruitful for your specific usage case etc. Haven't read any detailed documentation on HashCollider usage myself, I just glossed over the download & comments page quickly, so any documentaion you can find is probably worth looking at & figuring out etc. :thumbsup:

    If you're lucky you might find what you need on gtahash.ru also.

    Alternatively, in the past I've managed to discover a few text names from hex hashes by searching similar files for common Rockstar naming schemes (that Rockstar left in plain English) & then using them to guess what the name might be & confirm if correct in OpenIV's Hash Generator etc. One in a billion+ chance that though, & certainly not a reliable method, especially for unknown prop/object names etc (can work well in audio related '.rel' files though, where naming schemes are usually somewhat similar).



  • @a63nt-5m1th Eh yikes. Like you said, there is no wise versa conversion I was able to find :(

    It's really weird though game manages to read the model names properly every time :thinking: I guess there are other factors at play in here :thinking:



  • @Aurora11 Just curious, what entities are you trying to convert? I looked at the native functions but they don't seem to do what you want.

    GET_HASH_NAME



  • @JohnFromGWN Oh it was a prop from a mod. Strangely when I selected it with Menyoo, Menyoo only show it's hash instead of name. I'm assuming it was like that because in ymap file author wrote the hash name instead of model name. So I was trying to find the name of the prop :D



  • @Aurora11

    Did you try saving the prop from Menyoo as a favorite? And then opening the xml file?

    <PropModel modelName="v_ilev_trev_pictureframe2" modelHash="0x8519cc23" />


  • MODERATOR

    @Aurora11 said in What type of hash generator OpenIV is using?:

    I want to convert a hash to name but unfortunately OpenIV only has the option to convert the name to hash :(

    I have looked a lot of hash generators, ascii converters, hex stuff but none of them is giving the same result with the OpenIV's.

    Can anyone tell what type of code it's using so I can look at it and hopefully find a website that can also convert from hash to name as well <3

    That is never going to work. Hashes are computational checksums, as it were, over a string. They are inherently irreversible... unless you already have the name(s). We have the hashes for all Natives, for instance. Those can be reversed by simple look-up. I often do the same, with a custom tool of mine, for prop names (and everything hash) in a ytyp, for example, with only hash names. I collect all prop/meta data names, compute their hashes, then replace the hash names in the ytyp with the corresponding prop/meta data names again. Just because it looks cleaner.

    Just taking a hash, however, without a (limited) set of prop names to generate hashes from, and trying to turn it into a name again, is impossible, though (unless you were to iterate through trillions upon trillions of generated names).



  • @meimeiriver I follow what you wrote, but to answer @Aurora11 's original question, and for my own knowledge, does every prop hash have an associated name just as every native function hash translates into a native function name.

    As I wrote above, as an example, I frequently use Menyoo saved xml files to provide information on the values of component variations or teleport locations (rather than read them off hud). I then use Excel to batch generate code with string formulas in C# or lua.

    So, will Menyoo return the prop name when saved as a favorite for props only displaying the hash, or does this only work for game props? And what about rpf explorer, can it help.

    I mean the question was really about assigning a name to a prop and it seems it may have gotten sidetracked into a discussion on converting from hash to name which both you and @a63nt-5m1th have pointed out is impossible.


  • MODERATOR

    @JohnFromGWN said in What type of hash generator OpenIV is using?:

    @meimeiriver I follow what you wrote, but to answer @Aurora11 's original question, and for my own knowledge, does every prop hash have an associated name just as every native function hash translates into a native function name[?]

    In princple, yes. Early versions of addonprops and such had ytyps with only hashes. The props themselves held the names, of course. If a prop name is known to the game, then it will recognize and resolve the hash.

    In aurora's case, the test is very simple. Create a test ymap somewhere, put the hash in question into a randon entry, save the ymap again, and reopen it (all in OpenIV). Then, if a corresponding prop exists for it, anywhere in the game, OpenIV will have 'resolved' it to a name. If not, there's simply no corresponding prop name for the hash ingame (or the dlc with the prop in it hasn't been loaded).

    Menyoo typically stores props with both hash + name, like:

    	<ModelHash>0x46699f47</ModelHash>
    	<Type>2</Type>
    	<Dynamic>false</Dynamic>
    	<FrozenPos>true</FrozenPos>
    	<HashName>Akula</HashName>
    

    Menyoo, unlike OpenIV and CodeWalker, doesn't use a name resolver, but relies on its own props.ini for name lookup. That is no big issue, really, as you pick those names (from props.ini) via the spooner mode anyway. You can, for example, right-click on an object ingame, and add it to the database; but when that prop name isn't in props.ini, Menyoo just stores it as a hash.



  • @meimeiriver Thanks for the clear explanation.

    Speaking of ytyps, is there any reason why the def_props.ytyp from MethOd's AddopProps mod can't be exported to xml from OpenIV?

    I've exported other ytyps from OpenIV, as text/xml, but this particular one remains binary.



  • @JohnFromGWN
    Not sure exactly why that 'def_props.ytyp' doesn't export from OpenIV (other than 'Error code: plrNotSupportedType'), but if you XML export > import it using CodeWalker, it'll work correctly in OpenIV from then on :thumbsup:



  • @a63nt-5m1th thanks. It's not a file I edit normally, I just investigated it because some clueless modder uploaded a mod where he packaged his map in addonprops and custom maps folders. Of course he wasn't aware or didn't care that replacing folders overwrites existing folders. In other words all the noobs who followed his instructions essentially wiped out their custom map folders and those who might have had addonprop folders also wiped those folders as well.

    This is the same clueless behavior as the creators who package their own dlclist.xml and gameconfig.xml in OIVs.

    And then users post here saying their props or maps no longer appear and wonder how come?



  • @JohnFromGWN
    Talking about people potentially wiping out their modded files with an '.oiv' install, the Nbvisual/GTA V Remake patreon mod's '.oiv' installer completely replaces the user's 'update.rpf' & 'common.rpf'. Maybe he warns people in the documentation, & hopefully doesn't just say 'fresh mods folder required' etc, but still, that's a super risky manoeuvre I bet a few people fell foul of :confused:.



  • @a63nt-5m1th Scary and sad. Whether they mention it or not, it's a deplorable and selfish practice.

    It's the "My mod takes precedence over all your other mods" attitude.

    You would think these guys would know better or just care. And if you're going to put warnings, make sure they are in the package installer, in the instructions, everywhere. And the unwary users who install this then blame scripthook5 or whatever for the fact their game "suddenly and for no apparent reason" no longer works.

    Anyway, I would never use a third party OIV installer for the reasons above. Extract, read the assembly.xml, and decide what to install or not. If it wants to replace key files with its own, then there's a special place for the mod in the recycle bin.

    P.S. Slightly off topic, and apologies to @Aurora11 for hijacking, but why does the addonprops content.xml file refer to

    <filename>dlc_addonProps:/def_props.ityp

    when the actual filename is def_props.ytyp and def_props.ityp does not exist.

    I know this isn't an error, just curious.


  • MODERATOR

    @JohnFromGWN said in What type of hash generator OpenIV is using?:

    @meimeiriver Thanks for the clear explanation.

    Speaking of ytyps, is there any reason why the def_props.ytyp from MethOd's AddopProps mod can't be exported to xml from OpenIV?

    I've exported other ytyps from OpenIV, as text/xml, but this particular one remains binary.

    Yeah, I remember. Could be opened only with something called 'Meta Toolkit' (and then only the lastest beta version). It's no longer to be found anywhere. Doin't sweat it, though, the ytyp in it was horrifically bad, choke-full of egregious errors (in extents, centers, etc). Back in the day, people simly didn't know yet.

    Yes, their props, no offense, are crap too. They were all set to be 'skinned mesh', iirc. And those don't show up in a ymap. At that time, ymap was new too. Just forget about that whole addonprops. It's extremely obsolete.


  • MODERATOR

    @JohnFromGWN said in What type of hash generator OpenIV is using?:

    P.S. Slightly off topic, and apologies to @Aurora11 for hijacking, but why does the addonprops content.xml file refer to
    <filename>dlc_addonProps:/def_props.ityp
    when the actual filename is def_props.ytyp and def_props.ityp does not exist.
    I know this isn't an error, just curious.

    That is WAI. :)

    For instance, it is common, in meta files, to refer to say .imap, whereas the actual file extension is called ymap. Same with .ityp vs. .ytyp files. Entirely normal.


  • MODERATOR

    @a63nt-5m1th said in What type of hash generator OpenIV is using?:

    Talking about people potentially wiping out their modded files with an '.oiv' install, the Nbvisual/GTA V Remake patreon mod's '.oiv' installer completely replaces the user's 'update.rpf' & 'common.rpf'.

    MODERATOR CAP ON: I surely hope not, as it is against the Rules to distribute original game files. And an entire update.rpf (despite possible minor changes in it), we consider an original game file. Much like we don't allow people to redistribute an entire, say, mpapartment.dlc or something in their mods either. Will investigate.

    EDIT: Not seeing it on 5mods, fortunately. Or unfortunately, as the case may be, as that mod is assuredly going to make some victims that way.

    It is, btw, also simply terribly irresponsible: an imported update.rpf will BREAK your game, guaranteed, at the next update. And update.rpf is likely the file almost everyone running mods has customized, one way or the other.



  • @meimeiriver said in What type of hash generator OpenIV is using?:

    also simply terribly irresponsible: an imported update.rpf will BREAK your game, guaranteed, at the next update. And update.rpf is likely the file almost everyone running mods has customized, one way or the other.

    Couldn't agree more. That could cause a lot of pain (if no backups etc).

    It's the full mod, only available on his Patreon, that replaces 'update.rpf' & 'common.rpf'. The 0.1 version he has on gta5-mods is just the timecycle & weather texture files (+vehshare) & doesn't contain any full '.rpf's :thumbsup: (GTA V Remake 0.1 gta5-mods download page does contain a link to his patreon (if putting a warning there for gta5-mod users is applicable etc)).

    His last patreon update was Nov 2021. So not sure if he's still actively modding GTA V.



  • @meimeiriver I still have the meta toolkit, have used it (and RPF Explorer) to add textures to peds. Or is this another tool with the same name?



  • @meimeiriver said in What type of hash generator OpenIV is using?:

    And update.rpf is likely the file almost everyone running mods has customized, one way or the other.

    For sure. Dlclist.xml gets replaced which is a big deal. So does gameconfig.xml. Not to mention other, as you wrote, customized user files....all in a 1GB+ file!



  • @meimeiriver said in What type of hash generator OpenIV is using?:

    For instance, it is common, in meta files, to refer to say .imap, whereas the actual file extension is called ymap. Same with .ityp vs. .ytyp files. Entirely normal.

    Intended or not, it's kinda strange to refer to a file that doesn't exist.

    By the same R* logic, dlclist.xml could refer to dlc.rpf as ilc.rpf. Obviously, the path would be wrong, so engine would do the translation:

    if filename = ilc.rpf then filename = dlc.rpf
    

    But thanks for the explanation.


Log in to reply
 

Looks like your connection to GTA5-Mods.com Forums was lost, please wait while we try to reconnect.