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

Jump to bottom

OTTD/TTDP GRF loading inconsistency - A6 changes don't persist #1986

Closed
DorpsGek opened this issue May 6, 2008 · 4 comments
Closed

OTTD/TTDP GRF loading inconsistency - A6 changes don't persist #1986

DorpsGek opened this issue May 6, 2008 · 4 comments
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented May 6, 2008

minime opened the ticket and wrote:

As far as I know, this bug is present in all known revisions up to and including r12958.

This bug concerns a discrepancy in the way OTTD and TTDPatch handle loading of GRFs. In TTDPatch, changes done by an Action 6 persist between different loading stages. In OTTD any changes are lost (see attached logs), while only changes done to GRF parameters persist. This causes the algorithm described on page http://wiki.ttdpatch.net/tiki-index.php?page=Action6 to work incorrectly in situations when it is initialized with a non-zero value.

Attached is a GRF which uses an algorithm based on the idea presented in the wiki, and which works in TTDPatch but not in OTTD. Notice that in stage 3, action 6 gets carried out and updates a given section of a pseudo sprite. However, during stage 4, it reads in the unmodified value, instead of the new one.

Attachments

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/1986
@DorpsGek
Copy link
Member Author

DorpsGek commented May 6, 2008

Belugas wrote:

If i understand correctly, you are expecting that the first active sage (i.e. 3) actually sets stuff by action 6. Then, on next stage (4), the said data should still be modified and the changes are then based on the modified version of the data.
Now... question i have in mind is why do yo need such a scheme for your bridges?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1986#comment4063

@DorpsGek
Copy link
Member Author

DorpsGek commented May 6, 2008

peter1138 wrote:

In fact when I asked patchman about this many moons ago, the answer was that action 6 is not persistent between loading stages. As the NFO spec doesn't state either way, I went with that. :)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1986#comment4064

@DorpsGek
Copy link
Member Author

DorpsGek commented May 6, 2008

minime wrote:

Belugas: Yes, that's how I would expect it to behave, both from what I've seen in the wiki, and from my experience with how TTDP acts.
The scheme I use in the set currently allows you to write the sprite offsets for each bridge indexed from 0 - they get adjusted only when the said GRF gets loaded. This allows you to work on them in any order, makes it a lot simpler to write the layout tables, and it lets you change the number of sprites for any bridge without affecting the numbering for others.
Sure, all this math could be done before the GRF is built, but that would mean modifying my toolset, and possibly recoding significant parts of the current set source code. Considering that all the Actions 6 would need to be in the GRF anyway to support GRM (which according to Patchman is the preferred way of adding sprites for new bridges), the overhead added by my scheme consists of maybe 3 dozen simple Action D operations. Since the algorithm is basically what is mentioned on the wiki (and that's where Josef pointed me, when we were talking about GRM with bridges), and it works as one would expect based on the description while running under TTDPatch, I think it's use is justified.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1986#comment4066

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Fixed

In r14102.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1986

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) component: NewGRF This issue is related to NewGRFs bug labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek