Trying to understand how GMS 2 processes the .yy files of objects in the resource tree

I am a legacy user looking to "roll-back" GMS 2 projects from yyp format, and convert them into GMS 1 format.

Most noticeably the structuring for objects is very different, and the one issue I'm struggling to get past.

In GMS 1 all the events are handled in a way that's visually easy to peruse, and verify, the results of changes. Putting the GMS 2 info back into that structuring would be easy, but I don't understand how GMS 2 refers to the files. Since the information it uses appears to be encrypted, or does not handle human readable strings like GMS 1. I assume that not using strings in the old way, makes it more performant?

Some details are obvious: the event type, and event number, are handily referred to in the same way between both 1 & 2

But then when you try to find what piece of code is running that event in the .yy file, the files it is referring to (various .gml for each game event the object has) are a bunch of numbers / letters / dash (minus?) character.

Code:
"id": "89add546-49ff-49eb-8bf0-848e93ec8f26",
            "modelName": "GMEvent",
            "mvc": "1.0",
            "IsDnD": false,
            "collisionObjectId": "00000000-0000-0000-0000-000000000000",
            "enumb": 0,
            "eventtype": 3,
            "m_owner": "0889dbe5-68ab-492b-a71e-88f1ee439990"
If I can figure out what this jibber-jabbering is (it being hexadecimal was a wild swing in the dark for me), or decrypt it if that is what this is (though if it's encrypted that seems strange to me), then I could parse the gml files. But as is: I have no idea what I'm looking at, or whether I can do anything to be able to make use of it.
 

gnysek

Member
It's a random number, called UUID or GUID (or whatever). They slowly are removing use of this, as initially idea was to mark somehow unique things, so when several people work on same project, you can find out that for example two persons crated resource with same name (thanks to uuid you know, that it's not same, as it's generated on creation). Maybe it was required by extensions too. However, as it only tells you the problem, it still doesn't solve it.
Also using it with git only complicates everything. What's worse, in case of sprites, using random names doesn't help to track changes (lot of tools now supports displaying image diffs), and with every replacement of image new random one is created, sometimes leaving old one orphaned, which makes a mess, and lot of unused files is kept on disk. What's even worse, some antivirus software treats GUID/UUID files as suspicious.

So definitely maybe that was some idea to distinguish things, but generally you shouldn't care about it, and it will be removed at some point nearly everywhere (2.4, 2.5? who knows).
 
It's a random number, called UUID or GUID (or whatever).
At least I now know of this term :)

So this is actually some kind of encryption?

uuid.png
There's things like this online. Has it actually returned anything I can use to identify the gml file it is referring to?

Or is it a key from encryption, and it has to be decoded using SHA or something else.

I really want to know how to decode this, and have seen an old thread where YOYO staff say the yy files are very "hackable". Which suggests that want I want to do is acceptable, and doable, but it's beyond me to figure this out.


There's no pertinent information here, unfortunately, but comments by Mike from YOYO are quite suggestive

"Yeah, it's fine to poke around in the project files - this is one of the reasons they aren't in a binary format, but be aware they may change format without notice"

It would seem a bit odd that they're saying they've deliberately kept it readable, if there is something in there that is hashed (?), and also the program must be able to decode it. I can use GMS 2, but again wouldn't know where to find where it is decrypting this, or how.

The whole point is to get yyp files back into GMS 1, as many tutorials etc are now in the GMS 2 format, and I much prefer using GMS 1.
 
Last edited:

TsukaYuriko

☄️
Forum Staff
Moderator
The UUID is a randomly generated number. You can at most decode parts of it to find out how it was created. It has nothing to do with encryption, there is no data being hidden in it that is of any use to you. The site you refer to explains this at the very top of the page:
Embedded in every UUID is the version and variant of the UUID. Other information such as the time the UUID was generated can also be extracted in some cases. The tool above extracts this information automatically.
The UUID version is represented by the 13th digit of a hexadecimal UUID string ("M" in the diagram below). The variant is represented in the 17th digit ("N" in the diagram below).
That's all you're ever going to get out of that.


Mike saying that the .yy format is very "hackable" merely means that it is human-readable and that you can figure out what stuff in it does by reading it.


You can figure out which event .gml file goes where based on enumb and eventtype.
 

gnysek

Member
In fact those are random numbers. Difference with normal random number and GUID/UUID is that random is just a random number between A and B, while UUID is a random number based on current time+random number, so chance to create two same numbers is minimal (there's 2^128 numbers), as one part is based on incremental value. Still even if same number is created, they are used for so many things, that those numbers will be still unique among their ecosystems (like: it's not a problem if I have same GUID for sprite and some entry in Windows Registry, as those numbers aren't used for same thing, and cannot be merged/compared in any way - so they are still unique).
 
You can figure out which event .gml file goes where based on enumb and eventtype.
I don't know if there's documentation for this, but I've never found any, so that link is very helpful. I'd already started cataloguing events, but that will save a lot of time.

It's still not exactly all that straight-forward converting GMS 2 to GMS 1, and I am still none the wiser how GMS 2 knows which .gml file goes with which event when constructing objects. Thankfully the naming conventions are obvious enough to do it manually, if need be.

It's just that I'd hoped to be able to parse a text file (the yy file), find the event, find the .gml file it refers to, open it as a text file, loop through reading it as a string, and then put it into the object JSON of GMS 1.

In an object folder, I see: .gml files for each event the object has, and a yy file. In GMS 1 that would just be one file, with strings replacing the use of separate text files for the code blocks.

Does the yy file reference the .gml files? and if so: Can I read it?
 

TsukaYuriko

☄️
Forum Staff
Moderator
The .yy file does reference the .gml files, namely via the eventList attribute. Each element within references one event, not by name, but by ID. The IDs of each event can be found in the topic I linked. This is how the engine references them, and that's how you can parse them.
 
The .yy file does reference the .gml files, namely via the eventList attribute. Each element within references one event, not by name, but by ID. The IDs of each event can be found in the topic I linked. This is how the engine references them, and that's how you can parse them.
Are you just saying it has a list (or whatever) of what it calls for each event? It finds the event type, and then looks up what the .gml is for it?

If there is no direct reference in the yy file to the .gml file, then it would seem pointless persisting in looking at it. My impression from what you've said, is that this works behind the scenes because it's been manually set up, i.e:

I have a pre-compiled file somewhere that goes like this:

event = 0 enumb = 0 result = create_0.gml
event = 1 enumb = 0 result = destroy_0.gml

and so on?

I'm going to take a rough guess that I won't be allowed to find this file by the engine, and have to set it all up by myself, as the author of that thread had to?
 

TsukaYuriko

☄️
Forum Staff
Moderator
If there was a direct and literal reference to the .gml files in the .yy file, you'd have found it already. It's not included in the file, neither in plain text nor in encrypted form.

While I don't have access to the source code of GMS to confirm any of this, I'd consider it highly likely that GMS has an internal list of which event ID and number belong to which .gml file, simply because I can't imagine any other way it would know what to map to what. You could probably run a combination of search/replace and regex over the event map in the topic I linked to reform lines like <event eventtype="8" enumb="64"> Draw GUI to events[8][64] = "Draw_64.gml"; to get a list that works the same way. The file naming format seems to be based on the event type's name (Draw), followed by an underscore and the event number (64), but that's just the result of a quick test I did with a single event.
 
While I don't have access to the source code of GMS to confirm any of this, I'd consider it highly likely that GMS has an internal list of which event ID and number belong to which .gml file, simply because I can't imagine any other way it would know what to map to what.
Unfortunately trying to find such a list goes beyond what little I know :)

Whilst there still several plain(ish) text files throughout GMS 2' insides, and some that can otherwise be opened by an amateur such as myself, I don't particularly understand their workings. Which is partly why I'm more comfortable using GMS 1, despite having GMS 2.

The draw events are a good example of why I can't assume the numbering convention, as there is not 64 draw events, and it jumps from 0 to 64, then consecutively from 64 to 65, then jumps to 72 through to 77.

Other things might be numbered consecutively, like keyboard events, and I could apply that to press / pressed / release etc through duplication, and reasoning.

Well, at this point it's clearly got to be manual effort all the way, so I might as well get on with it. Thanks anyway for your assistance :)
 

gnysek

Member
Those numbers in yy files are probably equal to event_perform constants, but I never checked that it's true.
 
I had to take a more manual approach, but in the end I now have file a listing event type / event number / corresponding .gml file name

Each object has a .yy file, and also .gml files

If I parse the .yy file for references of "eventNum" and "eventType" I can find the .gml files, and then parse them into a string. That string is the contents as stored by GMS 1, and needs re-writing with the type and number.

It was really finding out how which .gml file went with which type and number, which was just a process of some deduction, and trial and error. I am confident now that I can get this working, so thanks for the help.
 
Top