Eyecandy (rev9790)

[Frostregen]

@DaleStan:
I never did anything with newgrf,
so I might not have figured out how this system is intended to work

To 1:
Ok, if i figured it right, the normal way would be:
1. Action1 to define sprites
...now some Realsprites
2. Action2 to give the previous action1 an id
3. Action3 to connect the id from action 2 with some internal id (or new-object)
4. Action0 to change/setup some values with ID from Action3

Since new-objects are given a new computed ID anyway,
why the detour over action 2/3 ?
(action0 prop08 creates a new id, which is lastid+1, which may be referred later by action4 or action0 again)

To 2:
As above.
The special handling for category-names will be changed to
"If highest bit is set, the name is applied to the category,
to which given eyecandy(eyecandyID) belongs to"
So no need to have it right after action0 anymore.

So the only difference is: I generate the ID's via Action0-prop08,
and don't have the user to create them with action2+3
I thought this is right because of this:

The IDs are therefore free to be chosen and will in fact be allocated automatically by the patch. In action 0, you only specify IDs relative to the set, i.e. the ID of the first object type is 00, the second object type is 01 and so on.

Quote from http://wiki.ttdpatch.net/tiki-index.php ... on0Objects

To3:
This is info missing
If the highest bit is not set, it is the name for the eyecandy with given eyecandyID.

I thought a default bounding box was sufficient, since eyecandy's always occupy 1 full tile, and nothing else may sit on this tile.

hmm, desert, snow and water will be added soon, forgot about this. Thanks. (Will be groundsprite=4+)

Thank you for reading this.

[DaleStan]

To 1:
...

Yes, except that it's "GRF-specific ID", not "internal ID".

Since new-objects are given a new computed ID anyway, why the detour over action 2/3 ?

Because your system doesn't allow different sprites depending on above/below the snow line, for example.

The question "What types of slopes can this eyecandy be built on?" can only be sanely answered with a callback, and that also requires a 1/2/3 chain.

So the only difference is: I generate the ID's via Action0-prop08, and don't have the user to create them with action2+3
I thought this is right because of this:

The IDs are therefore free to be chosen and will in fact be allocated automatically by the patch. In action 0, you only specify IDs relative to the set, i.e. the ID of the first object type is 00, the second object type is 01 and so on.

That's the way everything except vehicles works, I think. I know it's the case for houses and industry tiles, at the very least, and they have action 2s and 3s.
It's also the case for the D0xx and DCxx TextIDs.

Hmm, I thought a default bounding box was sufficient, since eyecandy's always occupy 1 full tile, and nothing else may sit on this tile.

How do you determine how tall to make the bounding box?

Actually, I lied about the connection between 0/3 and 4. I got it correct for vehicles, but for anything else, byte-sized TextIDs are verboten, because there's no previously existing slot to hold the text. You need to use a TTD ID, a D0xx, or a DCxx ID, depending on the desired usage, and then you connect that to the 0/3 by putting it in a property.

[Frostregen]

Right...
A custom Groundsprite is always the same, which is bad...
Ok, then this action2/3 stuff will be needed.

At first i did not think of custom-groundSprites at all,
because most of the eyecandy-graphics (infra) replace the
whole tile anyway.
(Ok, if they would change depending on snow/desert it would be nice too)

Slopes:
Currently an eyecandy may be build on any slope
(except the steep ones if it needs a flatArea).
if needsFlatArea is set, it will get a foundation,
else it is placed without a foundation.

BoundingBox:
I'm always using (16, 16, 16)
Currently I have no (or have not found) glitches with this.

Action4:
Wouldn't it be ok to set language-id bit 7,
and use C6xx and C7xx (+some other free ranges, i need 1024+256).
Like newstations does it (C4xx and C5xx). ?

The DCxx range is limited to 1024 in total, so i would rather use some other free space.

[Quark]

Code: Select all

+static void DrawEyecandyPreview(uint xoffset, uint yoffset, uint frameWidth, uint frameHeight)
+{
+	SpriteID image;
+	uint ymod = TILE_PIXELS / 2;
+	uint xoff, yoff;
+	uint lineLen, linePos;
+	uint x, y, w, h, i;
+	Point pt;
+	
+	//We have to draw it like the real drawer would do.
+	w = _eyecandy[usedEyecandy.realEyecandy].width;
+	h = _eyecandy[usedEyecandy.realEyecandy].height;
+	
+	xoff = (w - h) * ymod; //see yoff
+	yoff = -((w + h - 2) * ymod); //todo, center it real... (1x2, 2x4 etc...)

yoff, w, h, ymod — all is unsigned, why last line is there?

[Quark]

Please test if eyecandy correctly work

[Frostregen]

@Quark: right, should both be signed int.
The strange thing is:
I just changed it to int, and it kept working the same way as before.

Did you change anything besides this in your release.7z?
I can not test it, because of some "grf missing" errors.
Is this MiniIN, or your own multipatch build?

When my exams are finished (around mid-march) I'll continue to develop this patch.

[Quark]

@Quark: right, should both be signed int.
The strange thing is:
I just changed it to int, and it kept working the same way as before.

Did you change anything besides this in your release.7z?
I can not test it, because of some "grf missing" errors.
Is this MiniIN, or your own multipatch build?

When my exams are finished (around mid-march) I'll continue to develop this patch.

I change minus to plus in variable declaration and change sign on every use of yoff. Maybe error is invisible there or it's compensated by second error, anyway there was at least one error.
In my build your patch was merged with MiniIN, trunk r.7865 and some additional patches.

[Chicago Rail Authority]

Could you post a version that is either lined-up with a recent nightly, or the latest RC? I tried to load the file(s) you posted, but I'm not interested in shopping around to find all of the missing pieces that are req'd to make this run...

Thanks

[Quark]

I can not test it, because of some "grf missing" errors.
Is this MiniIN, or your own multipatch build?

It's something that I currently describe as MiniIN2, because it is more that MiniIN, but not that multipatch yet.
If some grf is missing try installing all grfs from MiniIN. It's based on MiniIN.

[hiperboreo93]

I liked this feature very much, buy it seems to be forgotten in time

hope someone else will keep working on this one (I know very little about c++)

sorry for the bad english.

[Sir A. Boey]

Hello,

I really like this idea, but I wanted to add a suggestion...
Why not add a buffer which is NOT a station but a single track like in real life...
Also why not create a track with several carriages on them, like they do at most of the
traindepots... The traincarriages are left there when they are for example useless...

I will look for a picture to show you guys what I mean ok?

greetz

[Wolf01]

is possible to do all with this patch, it only needs the grf loading system
if you look at the picture in the first page, the city is entirely made by hand (roads apart) with this patch

[athanasios]

I will look for a picture to show you guys what I mean ok?

[Sir A. Boey]

yes that's what I meant...

Great that this could be possible, this could make my games more realistical...

[twistid]

heys guys, noob question but how do i install and use this patch?...iv tried downloading it and installing it but it wont let me start the game at all..

any help would be cool.

Thanks

[one billion daleks]

Yeah, I had the same problem when I tried it yesterday ... it doesn't seem to compile successfully with the latest versions of OTTD. Note though, that this thread is now exactly a year old, so possibly the patch is no longer compatible and is not being maintained...

However, there is an eyecandy patch that works posted in http://www.tt-forums.net/viewtopic.php?f=32&t=35468 - but it only works within the Scenario Editor unfortunately ...

[twistid]

ohh i see....thanks for the link though!

[Sir A. Boey]

There's also something else take a look with the search-engine and look for
"pseudo-lok" or "-look"...

You can do such thing allready with a GRF file but I'll like the patch to BTW

Looks really realistic If you take a look at the Belgian railroads just before you enter Ostend.

Edit: They don't cost you anything

[stunt_monkey]

I'm Impressed, this gives those bored players opportunities to build useless junk and waste the billions of dollars

[Batti5]

The exe in the EYE_9790.rar is corrupted.