Planed changes in GRF System may influence coding/sprite err

Discuss, get help with, or post new graphics for TTDPatch and OpenTTD, using the NewGRF system, here. Graphics for plain TTD also acceptable here.

Moderator: Graphics Moderators

User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Planed changes in GRF System may influence coding/sprite err

Post by eis_os »

Hi

I have rework the internal Action 0 property system for TTDPatch and plan to commit the changes in the TTDPatch trunk branch the following week.

What does this mean as grf author / player ?

Revisions after around r1893 may fail with sprite errors because the new internal system has an unknown bug or the old parser simply ignored something in your grf.
The first test with DBSetXL and stations didn't show any problems.
You may want to test an old nightly http://nightly.ttdpatch.net/ then.
Bridge GRFs may fail. (see below for more)

What changes are done? Why changes in newgrfs core algorithm are done?

Action0 in it's current system manages internal 3 separate ways to set properties for a id. Currently we lose 8 properties for any non vehicle.
Neither is the current system flexible enough to replace these with custom internal function handlers to keep grf compatibility when the internal may change in the future. New features may be more logical structured
Old features are mostly impossible to extend id wise.
Lot of special code handling but less memory usage by definition.

New System:
Uses more memory to define the properties, but is a lot easier to maintain and can be extended, a lot code paths are removed and replaced by table lookups.
As the bridge Action0 was quite a hack, it couldn't be converted.
The result was a rewrite of the current bridge functions. While I haven't managed to fix the gui and add new stuff. The internal system now allows theoretical new 100 bridge ids. :D
Therefor some new stuff needs to be introduced property wise. (New icon handling, text handling, fail back handling) so the bridge grfs may fail... (As a grf author may want to add your wishes for bridge properties here)

Note: If you have currently errors with sprites with r1893, or sprite errors in beta it's not my fault.
User avatar
minime
Transport Coordinator
Transport Coordinator
Posts: 339
Joined: 18 Jan 2004 10:02
Skype: dan.masek
Location: Prague, Czech Republic
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by minime »

There are only few extra properties that I can think of that bridges could use - custom icon is definitely a must even if you'd keep just the current number of bridges. It may be handy to have the ability to define a bitmask of track types the bridge will be available for (avoid maglev on wooden bridge, for example). It would also be handy to have the ability to define layout tables for different track types independently(so that you could modify only road bridges, for example).

This is problably out of the scope of what you're doing, but here it goes anyway - The really neat features would involve having a VA2 support for either setting properties (speed/availability/length limits/etc. different for different tracks), or for picking of layouts to draw (with inputs such as position from beginning of the bridge, height above ground, length of bridge, info about the map tile). If that was possible, it may be handy to have the ability to define more layouts per bridge, maybe even have ability to track date built.

Currently the bridge heads are common for all climates, so you can't for example have part that's covered with grass, because it would look odd in the middle of desert or snow. This would be solved by VA2 support mentioned above, or possibly there could be an extra layout for bridgeheads on snow.
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. --Albert Einstein
Image Image Image
Patgreg
Engineer
Engineer
Posts: 12
Joined: 09 May 2008 02:57

Re: Planed changes in GRF System may influence coding/sprite err

Post by Patgreg »

Would signals onm bridges be a remote possibility?
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by eis_os »

A bridge id can only be edited by one GRF at a time, (we can't resolve TextIDs across grfs without storing each textid with grfid). Actually the layout of a bridge is quite fixed, the layout functions haven't been changed.

Currently for climate different sprites you have to switch via Action7, thats how TTD does it internal too...

I don't want to switch to Action321 now, as this would mean all current bridge/roadset grfs are invalid and would be again void for newroutes. *
The new action0 system depend on the rewritten bridge code.

L8 is planed for storing the date, but because Action321 isn't used, it would have very limited usage...

-edit-
Patgreg: No - thats quite impossible because of a lot of facts.

Please only grf authors or at least people who have an idea how O)TTD(Patch works (GRF, Savegame or internal wise)

-edit 2-
* A pre-newroutes possibility would be to add some dummy newroutes lookups that always result in Action5 based fixed sprites, GRF authors of road and rail pieces could then add then necessary 2*4 route type sprites... And bridge authors would add the necessary spriteid for calling these in an new layout system. Again a bridge shouldn't know the track style on top...
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
User avatar
minime
Transport Coordinator
Transport Coordinator
Posts: 339
Joined: 18 Jan 2004 10:02
Skype: dan.masek
Location: Prague, Czech Republic
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by minime »

eis_os wrote:Currently for climate different sprites you have to switch via Action7, thats how TTD does it internal too...
Indeed, however that does not solve the issue of landscapes with two different ground types (which now with support for snow in temperate means all). See attached picture - that's something action 7 can't help you with (ignore the wrong shade of grass).

EDIT: I suppose that without A123 and with respect to changes being done for newroutes, there really isn't anything useful I can think of (that would be worth it). Some provisional support that may allow people to start preparing things for newroutes would be handy tho.
Attachments
bridgehead-issue.png
bridgehead-issue.png (20.76 KiB) Viewed 7353 times
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. --Albert Einstein
Image Image Image
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by eis_os »

TTD should draw the ground, not the bridge sprite... (so coasts can be seen) But after all, only with action321 this can be done
A other solution is to use a partly transparent dithered sprite...
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
User avatar
minime
Transport Coordinator
Transport Coordinator
Posts: 339
Joined: 18 Jan 2004 10:02
Skype: dan.masek
Location: Prague, Czech Republic
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by minime »

True, I completely forgot about coasts. Too bad - in that case i'm content with what's there now, since anything that I can think of are just limited workarounds for lack of A123.
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. --Albert Einstein
Image Image Image
User avatar
thgergo
Route Supervisor
Route Supervisor
Posts: 391
Joined: 29 Mar 2005 12:44
Location: Hungary

Re: Planed changes in GRF System may influence coding/sprite err

Post by thgergo »

Its nice to see, finally bridges will have proper action 0-1-2-3 support in the near future isnt it? Altough this is a nice development, even it does not offer too much yet, I`m looking forward to this. Only this that disappoint me, these new changes break the compatibility with older bridgesets, which made with the older hackish method, including mine, wont work with TTDpatch anymore. Would it possible to keep the old bridge action while developing this new?
eis_os wrote:As a grf author may want to add your wishes for bridge properties here
-defineble sprite usage for every length : The ability to define the sprites from the north corner to the south per tile. Same thing should be used for pillars. I think a good solution would be good to introduce bridgetiles, then construct the final bridge with those predefined tiles.
-pillars should differ in length! : With the current system the pillars isnt very nice, pillars are a 8 tile long samples, tall bridges looks ugy with them. It would be nice to the pillars look different per height. Also, the front pillar, and the back pillar should be defined seperetly.
Its just my 2 cents...
Image
Image
User avatar
PikkaBird
Graphics Moderator
Graphics Moderator
Posts: 5631
Joined: 13 Sep 2004 13:21
Location: The Moon

Re: Planed changes in GRF System may influence coding/sprite err

Post by PikkaBird »

eis_os wrote:(As a grf author may want to add your wishes for bridge properties here)
Be careful what you wish for... :twisted:
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by eis_os »

As I said, the action0 rewrite already needs an change in Action0 for bridges, so it may be easier to already write code that may be reused later (or already allows later to add a requested featue) As example, while the bridge icon spriteids can't be changed yet, the code already restores them properly. Ohh, and the new code should be robust to TTD Alter changed exe files. (Bridge speeds are located now completely different)
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
User avatar
Lakie
TTDPatch Developer
TTDPatch Developer
Posts: 1799
Joined: 26 May 2004 16:37
Location: Britain
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by Lakie »

Thought I might post a few bugs I've been experiencing since r1896.
  • Errors:
  • Generating a new random terrain game hangs,
  • Some bridges have 0 mph speed limits or broken costs,
  • Bridges (newgrf and stock) use the wrong graphics.
~ Lakie
Last edited by Lakie on 31 May 2008 16:21, edited 2 times in total.
Reason: Stickied it for a little while.
TTDpatch Developer 2005 - 2010 ~ It all started because of shortened vehicle not loading correctly, now look where I've gone with it!
Grfs coded ~ Finnish Train Set (Teaser) | Bm73 (Release 3) | Emu 680 (Release 3)| Glass Station (Release 1) | UK Roadset (Version 1.1a) | New Water Coasts (Version 7)
Pikka: "Lakie's a good coder, but before he'll add any feature to TTDP you have to convince him that you're not going to use it to destroy the world as we know it."
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by eis_os »

At least the bridge problems should be fixed in r1898
-edit-
In r1900 ...
-edit-
or in r1901 when a bridge grf may have changed the introduction years
User avatar
Mickeye
Chief Executive
Chief Executive
Posts: 751
Joined: 08 Apr 2005 19:09
Location: Kromeriz, Czech Republic

Re: Planed changes in GRF System may influence coding/sprite err

Post by Mickeye »

I found another bug since r1896: Pikka's Aviators Aircraft set doesn't work. See attached picture:
Attachments
AV8 in r1897
AV8 in r1897
Snap1.png (5.86 KiB) Viewed 6524 times
AV8 in r1895
AV8 in r1895
Snap2.png (5.28 KiB) Viewed 6523 times
Image
Mickeye on devArt | Last.fm || Winner of "Best TT-Forums signature, 2006" award
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by eis_os »

Hmm, I found an error in the property size of capacity :? , should be fixed in r1905.. :D
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
mav1701
Engineer
Engineer
Posts: 19
Joined: 02 Jun 2008 20:39

Re: Planed changes in GRF System may influence coding/sprite err

Post by mav1701 »

Using r1902, the US Set (trains) doesn't build its vehicle list correctly: 1921 is blank, 1925 has the newer diesel and electric trains, steam is hardly seen. Also, the planes vehicle list (not affected by any grf addon) shows all the jumbo jets and future aircraft, even in 1921.
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by eis_os »

Thanks for the report, please try r1906.
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
User avatar
belugas
OpenTTD Developer
OpenTTD Developer
Posts: 1507
Joined: 05 Apr 2005 01:48
Location: Deep down the deepest blue
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by belugas »

If I can propose a few change/additions in properies, please consider
Climate Availability (see minime post)
Life Time usability

For now, those are the only two properties i'm about to add to the code.
Of course, available callbacks, but that is really usefull while action 1/2/3 are not done ;)
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by DaleStan »

belugas wrote:Climate Availability (see minime post)
Wouldn't it be better to guard the controlling actions with a climate-dependent 7, instead of consuming a bridge slot for a bridge that's only available in not-this-climate?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by eis_os »

Can you explain me the details how you want to add "Life Time usability" ?
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
User avatar
belugas
OpenTTD Developer
OpenTTD Developer
Posts: 1507
Joined: 05 Apr 2005 01:48
Location: Deep down the deepest blue
Contact:

Re: Planed changes in GRF System may influence coding/sprite err

Post by belugas »

@Dalestan : True that currently, we do not have much room to navigate, with only 11/13 slots. On OpenTTD side, the numbers will grow to quite a few more slots (although the exact number is not decided yet). So, I was thinking of a convenient way for bridges creators to dispatch their creations by setting simply a property, much like what happens with house's property "Building availability mask (13)".

@eis_os : First, after expiration of the said time life, no bridges of that type will be allowed to be built. Technologically wise, it makes sens. Second, for an already built bridge of that type, when life time expires, that bridge is going to be prone to collapsing. In fact, it's linked to the disaster system... This, of course, is a feature i've already started to code. The default would be to determine, my current one is 0, as eternal bridge, kinda.

Now, while I was typing, I remembered something else I wanted to suggest:
Maximum number of appearance. Tis comes from the fact that a bridge can be an architectural structure that has no counterpart or copy anywhere in the world, like the Golden Gate and others alike. So, in order to avoid over population of the same bridge everywhere on the map, such a property would allow to have a more evenly spread use of more diversity of bridges. and not just the fastest anymore... This is, too, something i have started coding.
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
Post Reply

Return to “Graphics Development”

Who is online

Users browsing this forum: Ahrefs [Bot] and 12 guests