Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rpg::MoveCommand::Code::change_graphic parameter reads as an unknown chunk #441

Open
elsemieni opened this issue Apr 30, 2022 · 2 comments
Labels

Comments

@elsemieni
Copy link
Member

Tested with master lcf2xml.

When trying to read the following command event:
@> Set Move Route: Player, Change Graphic...

It got read in the following way:

      <EventCommand>
        <code>11330</code>
        <indent>0</indent>
        <string></string>
        <parameters>10001 8 0 0 34 6 97 110 105 109 97 108 1</parameters>
       </EventCommand>

Understanding that is a undecoded Change graphic event with it's parameter in decimal.

Obviously this does not affect file reading/writing and it re-generates without problems, but I think liblcf is also unable to read it properly (only having access to undecoded parameters, just like the XML file output of lcf2xml).

By seeing https://github.com/EasyRPG/liblcf/blob/master/src/lmu_movecommand.cpp#L47 it seems to do explicitely in this way. This is beacuse this chunk is not investigated yet? Or it's a bug indeed?

Thanks in advance.

@Ghabry
Copy link
Member

Ghabry commented Apr 30, 2022

The raw data is decoded by the Player.

Problem is the data structure here: this is an event command so all the move commands are part of the parameter. Including the filename for change graphic.

Not sure if it would be possible to make the output a bit smarter when writing xml

@fdelapena
Copy link
Contributor

Not sure if it would be possible to make the output a bit smarter when writing xml

Somehow related: #245
If a parameter value had a specific type, could be defined in the structure for some column as in other CSVs.

Skipping these special cases chunk reads could prevent false positives and pollution once #416 gets in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants