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

Hero names containing control commands are not interpreted #460

Closed
fdelapena opened this Issue Apr 28, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@fdelapena
Contributor

fdelapena commented Apr 28, 2015

The following command input selectable is shown under certain circumstances:

captura de pantalla de 2015-04-25 13 13 59

@fdelapena fdelapena added this to the 0.3.1 milestone May 8, 2015

@fdelapena fdelapena changed the title from Nested message input selectables ignore text control commands to Message input selectables ignoring text control commands Aug 26, 2015

@Ghabry Ghabry modified the milestones: 0.3.1, 0.4 Sep 6, 2015

@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Dec 14, 2015

Member

Can you tell the map id where this happens?

Member

Ghabry commented Dec 14, 2015

Can you tell the map id where this happens?

@fdelapena

This comment has been minimized.

Show comment
Hide comment
@fdelapena

fdelapena Dec 14, 2015

Contributor

Save05.lsd.zip

How to trigger: just press the decision key, it will open a menu with 4 options. The first two options will show options with control commands.

Another couple of bugs there:

  • When pressing cancel key, it will show game menu. If you try the same with RPG_RT (this player savegame works with it), it won't show the custom game menu. It looks like some key status is not clean or whatever.
  • In the Game Menu, the "End Game" asks for a confirmation, and the selectable bar has not the proper width (has the size when face is available), compated to RPG_RT, which has the full size.
Contributor

fdelapena commented Dec 14, 2015

Save05.lsd.zip

How to trigger: just press the decision key, it will open a menu with 4 options. The first two options will show options with control commands.

Another couple of bugs there:

  • When pressing cancel key, it will show game menu. If you try the same with RPG_RT (this player savegame works with it), it won't show the custom game menu. It looks like some key status is not clean or whatever.
  • In the Game Menu, the "End Game" asks for a confirmation, and the selectable bar has not the proper width (has the size when face is available), compated to RPG_RT, which has the full size.
@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Dec 14, 2015

Member

This game uses an interesting technique:
It uses Hero names to generate strings. :O

The choice list contains
\N[15]\N[16] and this is substituted to "\C[4] whatever". So is basicly double substitution, wtf. This will need some code rewrite (the replaced hero name must be pushed back into the text-string, so the []-substitution applies again)

Member

Ghabry commented Dec 14, 2015

This game uses an interesting technique:
It uses Hero names to generate strings. :O

The choice list contains
\N[15]\N[16] and this is substituted to "\C[4] whatever". So is basicly double substitution, wtf. This will need some code rewrite (the replaced hero name must be pushed back into the text-string, so the []-substitution applies again)

@Ghabry Ghabry modified the milestones: 0.4.1, 0.4 Dec 15, 2015

@Ghabry Ghabry modified the milestones: 0.4.1, 0.5.0 Feb 19, 2016

@Ghabry Ghabry changed the title from Message input selectables ignoring text control commands to Hero names containing control commands are not interpreted Mar 7, 2016

@Zegeri

This comment has been minimized.

Show comment
Hide comment
@Zegeri

Zegeri Apr 7, 2016

Member

77af9ca should fix this.

Member

Zegeri commented Apr 7, 2016

77af9ca should fix this.

@carstene1ns

This comment has been minimized.

Show comment
Hide comment
@carstene1ns

carstene1ns Apr 8, 2016

Member

Great, this also makes the code easier to read! (no more call_depth). One potential issue i see is the possibility of endless recursion, but I think we can neglect this possibility.

Member

carstene1ns commented Apr 8, 2016

Great, this also makes the code easier to read! (no more call_depth). One potential issue i see is the possibility of endless recursion, but I think we can neglect this possibility.

@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Apr 8, 2016

Member

Yeah the endless recursion is a thing I wanted to test in RPG_RT to see what happens :D

Member

Ghabry commented Apr 8, 2016

Yeah the endless recursion is a thing I wanted to test in RPG_RT to see what happens :D

@Zegeri

This comment has been minimized.

Show comment
Hide comment
@Zegeri

Zegeri Apr 9, 2016

Member

Endless recursion was impossible in RPG_RT. If an actor's name is "\n[1]" or "\v[1]", the output will always be "[1]". If the name is "\v[\v[1]]" or "\n[\v[1]]", the output is "[[1]]". Separating the commands in two or more names won't change the result (e.g. if \n[1] is "\n[", and \n[2] is "\v[1]]" the output of \n[1]\n[2] is still "[[1]]").

So the patch doesn't replicate perfectly RPG_RT, but it extends the behaviour one would expect from these combined message commands,

Member

Zegeri commented Apr 9, 2016

Endless recursion was impossible in RPG_RT. If an actor's name is "\n[1]" or "\v[1]", the output will always be "[1]". If the name is "\v[\v[1]]" or "\n[\v[1]]", the output is "[[1]]". Separating the commands in two or more names won't change the result (e.g. if \n[1] is "\n[", and \n[2] is "\v[1]]" the output of \n[1]\n[2] is still "[[1]]").

So the patch doesn't replicate perfectly RPG_RT, but it extends the behaviour one would expect from these combined message commands,

@Ghabry Ghabry closed this in #860 Apr 10, 2016

@Ghabry Ghabry modified the milestones: 0.5.0, 0.4.2 Apr 11, 2016

@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Sep 4, 2016

Member

Actually this regressed a bit:
ribbonerr

Expected output:
ribbonexpected

Member

Ghabry commented Sep 4, 2016

Actually this regressed a bit:
ribbonerr

Expected output:
ribbonexpected

@Ghabry Ghabry reopened this Sep 4, 2016

@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Sep 9, 2016

Member

The problem here is some oversight: The code doesn't distinguish between empty hero name and parse error.

Another problem is the handling of , this actually doesn't(!) escape the next command character m(

Member

Ghabry commented Sep 9, 2016

The problem here is some oversight: The code doesn't distinguish between empty hero name and parse error.

Another problem is the handling of , this actually doesn't(!) escape the next command character m(

Ghabry added a commit to Ghabry/easyrpg-player that referenced this issue Sep 9, 2016

Handle some corner cases (empty \N, incorrect \\ escape handling) cor…
…rectly. Parse backwards to implement the EasyRPG extensions \v[\v[N]] and \n[\v[N]]] again.

Fix #460

Ghabry added a commit to Ghabry/easyrpg-player that referenced this issue Sep 9, 2016

Handle some corner cases (empty \N, incorrect \\ escape handling) cor…
…rectly. Parse backwards to implement the EasyRPG extensions \v[\v[N]] and \n[\v[N]]] again.

Fix #460

Ghabry added a commit to Ghabry/easyrpg-player that referenced this issue Sep 10, 2016

Handle some corner cases (empty \N, incorrect \\ escape handling) cor…
…rectly. Parse backwards to implement the EasyRPG extensions \v[\v[N]] and \n[\v[N]]] again.

Fix #460
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment