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

Support RPG Maker 2000 v1.60 and v1.61 #588

Closed
Ghabry opened this Issue Sep 15, 2015 · 4 comments

Comments

Projects
None yet
4 participants
@Ghabry
Member

Ghabry commented Sep 15, 2015

I don't think it's worth to differentiate between 1.60 and 1.61
No idea how to detect them properly.

https://docs.google.com/document/d/1n-CHoQ0hwHWEnkoiLo7fiRUqS4hY4mhOkv_jkmz2cg8/edit?pli=1#heading=h.wcb2puxulvzi

v1.61 (2015-09-15)

Placeholders in system messages.

  • Battle messages can now contain placeholders (%S, %O, %V, and %U for subject, object, value and unit) instead of having a fixed order and position of those values.
  • Also applies to skill usage messages, state messages and inn messages.
  • additional values can be used in battle strings, such as the attacker’s name for evasion messages, the target name for skill messages (only for single-target skills), etc.
  • Battle messages which become too long for a line will automatically be word-wrapped.

v1.60

  • Picture operations (Show, Move, Erase) are not blocked by messages anymore.

@Ghabry Ghabry added this to the 0.4 milestone Sep 15, 2015

@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Sep 15, 2015

Member

inn_a_greeting_2 and inn_b_greeting_2 are now empty and merged into _1.

The rest is just adding of place holders

A new global chunk was added to the LDB 0x1A (defaults to 0). When this chunk is 1 the Database was updated to use placeholders.
So this is perfect for detecting RPG Maker 2k v1.61 and newer :)

Member

Ghabry commented Sep 15, 2015

inn_a_greeting_2 and inn_b_greeting_2 are now empty and merged into _1.

The rest is just adding of place holders

A new global chunk was added to the LDB 0x1A (defaults to 0). When this chunk is 1 the Database was updated to use placeholders.
So this is perfect for detecting RPG Maker 2k v1.61 and newer :)

@rohkea

This comment has been minimized.

Show comment
Hide comment
@rohkea

rohkea Apr 17, 2017

Member

The messages about winning can contain codes (like \N[x] or \C[x]).

When word-wrapping, RPG Maker 2000 v. 1.61 honours the codes that replace values (such as \N[0]). However, the codes that do text formatting (such as \C[x]) are counted as if they do take some screen estate:

Two screenshots side-by-side. The first screenshot has coloured text, and the line is wrapped too early: there are some space for the next word in the first line, but that word is moved to the second line. The right screenshots has all the words written in the same colour, and it has correct line-wrapping behaviour: it has as many words as can fit.

The left screenshot has more formatting codes, so the first line is wrapped earlier than in the right screenshot.

I can imagine situations when someone could depend on \C[x] taking screen estate when word-wrapping. People might use spaces get exact alignment of two lines, like this (a 'Hello world' is broken into two lines with spaces):

Example showing exact line alignment, where 'Hello world' is broken into two lines, the first having letters H, l, o, w, r, d, and the second having e, l, o, l, and an exclamation mark.

But I really, really doubt anyone would do this. 😕

So, the question is:

Should we emulate this behaviour? Or should we consider that codes like \C[x] don’t take any place?

Member

rohkea commented Apr 17, 2017

The messages about winning can contain codes (like \N[x] or \C[x]).

When word-wrapping, RPG Maker 2000 v. 1.61 honours the codes that replace values (such as \N[0]). However, the codes that do text formatting (such as \C[x]) are counted as if they do take some screen estate:

Two screenshots side-by-side. The first screenshot has coloured text, and the line is wrapped too early: there are some space for the next word in the first line, but that word is moved to the second line. The right screenshots has all the words written in the same colour, and it has correct line-wrapping behaviour: it has as many words as can fit.

The left screenshot has more formatting codes, so the first line is wrapped earlier than in the right screenshot.

I can imagine situations when someone could depend on \C[x] taking screen estate when word-wrapping. People might use spaces get exact alignment of two lines, like this (a 'Hello world' is broken into two lines with spaces):

Example showing exact line alignment, where 'Hello world' is broken into two lines, the first having letters H, l, o, w, r, d, and the second having e, l, o, l, and an exclamation mark.

But I really, really doubt anyone would do this. 😕

So, the question is:

Should we emulate this behaviour? Or should we consider that codes like \C[x] don’t take any place?

@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Apr 17, 2017

Member

I just hope that nobody cared about using this for formating and would assume that \C[x] takes 0 space.

@CherryDT is that by design or a bug?

Member

Ghabry commented Apr 17, 2017

I just hope that nobody cared about using this for formating and would assume that \C[x] takes 0 space.

@CherryDT is that by design or a bug?

@CherryDT

This comment has been minimized.

Show comment
Hide comment
@CherryDT

CherryDT Apr 17, 2017

@Ghabry it's a bug in fact, thanks for pointing that out!

CherryDT commented Apr 17, 2017

@Ghabry it's a bug in fact, thanks for pointing that out!

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