Page 30 of 51
Posted: 13 May 2005 16:07
by lobster
it's the version of a few pages back, i'll have to check. or attach.
Posted: 14 May 2005 11:53
by Born Acorn
a new piece for my frieght station, a shed. Now allow you to make massive warehouses, and many improved other sprites,
Posted: 14 May 2005 12:37
by Singaporekid
Yaay! Thanks Born Acorn

Posted: 14 May 2005 14:29
by Oracle
Aegir, I've noticed (while investigating your stations and NewStations v0.4) that your bare stations don't show snow or desert under their tiles. (To be honest, all your other stations don't, but that's more complicated to fix.) However, if you look at the country stations in the US Set, they will (IIRC fox the version I released) show show or desert under their tiles.
I've looked at your code and, whether this is GRFMaker restrictions or how you've chosen to code it, you could fix it quite easily.
Currently, your sprite layout consists of four pairs of tiles of the form
Code: Select all
F4 03 00 00 00 00 00 00 00 00 2D 04 00 00 80
F3 03 00 00 00 00 00 00 00 00 2D 04 00 00 80
Firstly, as you don't actually want the sprite there, you could change those two lines to just
which has the same effect.
However, you don't actually want four pairs of identical tiles - you just need one pair. You can then have a second pair using 0E 04 00 00 and 0D 04 00 00 for the groundsprites - these are the snow and desert track tiles in arctic and tropic respectively.
Then you need to set callback 14 for the station, so you can use callbacks to specify which tile type to draw. Using variable 42 with a bitmask of 05, you can then choose the original tile type 00 if the result is 00; otherwise you want tile 02.
Therefore the code you need is as follows:
Code: Select all
//between sprites 4 and 5
// choose tile type depending on snow/desert/neither
-1 * 14 02 04 10 81 42 00 05 01 00 FF 00 00 02 FF
// check for callback and use cargo-id 10 if callback 14
-1 * 14 02 04 11 81 0C 00 FF 01 10 00 14 14 00 00
//replace sprite 7
// enable callback 14 as well as existing pylon mask
-1 * 9 00 04 02 01 00 11 FF 0B 02
//replace sprite 8
// set new sprite layout
-1 * 27 00 04 01 01 00 09 04
F4 03 00 00 80
F3 03 00 00 80
0E 04 00 00 80
0D 04 00 00 80
//replace sprite 16
// change action 3 cargo-id
-1 * 10 03 04 01 00 01 FF 11 00 11 00
//(in fact this could just be 03 04 01 00 00 11 00)
I've tested this and it works nicely.
You could do a similar thing with the "bare tile" station too - you'll just need to find the bare snow sprite in trg1[r].grf.
Posted: 14 May 2005 14:56
by krtaylor
I take it that means you're now working through the US stations sets' coding, Oracle?

Posted: 15 May 2005 02:50
by Aegir
Thanks for that Oracle, Im already back to working on P:GS again (Although GRFMaker creating screwed up .grf's is slowing that down some), so that info will be quite usefull.
Speaking of your country stations, I've noticed somthing while I was playing around, currently. Both the Concrete (Which uses the same platforms as the concrete platforms in my set) and the normal country stations sit (In some tiles, not all) 1 pixel below everything else. This makes the top of the platforms look as if they sit lower than the tile. Its a bit hard to describe, but when I stuck some platforms from my .grf (The one where I fixed the 1px z rel error) down next to your country stations, the height difference was noticeable.
Its not that serious really, since the auto-adjusting nature of your stations makes laying down other station platforms next to them not really work, but I just thought I should let you know

.
Posted: 16 May 2005 10:03
by The Irish
Hi guys...
I'm kinda lost with the PGS. I'm still using a pretty old version (pigsw.grf) as all newer ones have produced lots of errors in my game (a50).
I have read somewhere that all older versions had to be disabled for that, which i did. However, I still had svline and jcindstatsw etc. enabled. is that what might have caused it?
Further, may I suggest that you post the most recent version of the set in the first post of this treath, so it is easier to find.
Otherwise, I have to say that I really like these stations, even tough competition is high these days...

Posted: 16 May 2005 10:40
by Aegir
Simply put, if you run one version of P:GS allongside another version. You will get issues.
The three pgs .grf's that form the pre2 build of P:GS are:
pgs-stat(w).grf
pgs-plat(w).grf
pgs-bare(w).grf
Loading TTD with any other P:GS .grf's will cause issues due to the way the drop-down list boxes in TTD/Patch function. Namely they have a limit of 18-19 entries. Any more will cause errors.
If you are getting graphical issues, such as corrupted display etc... Then you will have to disable P:GS and wait. This is an error with GRFMaker creating and coding screwed up Station Data Blocks (Combines Action 2 and so forth into one object for graphical manipulation). This error has existed for quite some time, and I usually manage to fix the error by copy/delete/pasting the problematic blocks, but the latest build of GRFMaker availible to me causes almost every single station data block to cause this issue. No-doubt because of a fair few new features added to the program (Many requested by me

).
Price one pays for Alpha testing software, but its un-avoidable.
It has occoured to me that I could simply use GRFCodec to directly compile GRFMakers NFO output into a .grf, but that is a lot more hassle, and I am extrordinarily lazy when it comes to these types of things.
(See, I actually managed to reply to a bug report without yelling and screaming

)
Posted: 16 May 2005 13:22
by The Irish
Aegir wrote:Simply put, if you run one version of P:GS allongside another version. You will get issues.
The three pgs .grf's that form the pre2 build of P:GS are:
pgs-stat(w).grf
pgs-plat(w).grf
pgs-bare(w).grf
Loading TTD with any other P:GS .grf's will cause issues due to the way the drop-down list boxes in TTD/Patch function. Namely they have a limit of 18-19 entries. Any more will cause errors.
If you are getting graphical issues, such as corrupted display etc... Then you will have to disable P:GS and wait. This is an error with GRFMaker creating and coding screwed up Station Data Blocks (Combines Action 2 and so forth into one object for graphical manipulation). This error has existed for quite some time, and I usually manage to fix the error by copy/delete/pasting the problematic blocks, but the latest build of GRFMaker availible to me causes almost every single station data block to cause this issue. No-doubt because of a fair few new features added to the program (Many requested by me

).
Price one pays for Alpha testing software, but its un-avoidable.
It has occoured to me that I could simply use GRFCodec to directly compile GRFMakers NFO output into a .grf, but that is a lot more hassle, and I am extrordinarily lazy when it comes to these types of things.
OK, I will give that a try. I just wondering about the svline and the industrial stations. do those also have to be switched off and are included in your set, or are they still seperate?
Aegir wrote:
(See, I actually managed to reply to a bug report without yelling and screaming

)
Never saw you screaming.

I'm glad you didn't now.

Posted: 16 May 2005 13:51
by lobster
both the svline(w).grf and jcindsta(w).grf are different sets and can be used alongside ours. on a further note, also mr. Bluncks station graphics can be used. in fact, every other station set can be used alongside this one. it's that simple.

Posted: 16 May 2005 18:23
by Oracle
Aegir wrote:Speaking of your country stations, I've noticed somthing while I was playing around, currently. Both the Concrete (Which uses the same platforms as the concrete platforms in my set) and the normal country stations sit (In some tiles, not all) 1 pixel below everything else. This makes the top of the platforms look as if they sit lower than the tile. Its a bit hard to describe, but when I stuck some platforms from my .grf (The one where I fixed the 1px z rel error) down next to your country stations, the height difference was noticeable.
Thanks for this: you're definitely right regarding the concrete stations - I obviously didn't check those enough when coding them. I'm not sure about the other ones but I think you might be right - I'll change them and see whether they look better shifted up a pixel. I think you could argue both ways on that one, though.
I do remember doing a comparison some time ago but that was when yours were a pixel out and therefore weren't any good for comparing with.
Regarding svline, hopefully the stations from that set will be integrated into PGS and jcindsta in the long run so you shouldn't need it. For now though, you do need it if you want the full complement of station graphics.
Posted: 16 May 2005 18:45
by Born Acorn
small error in the last ones, and an example
Posted: 16 May 2005 21:29
by Geo Ghost
looking good Born Acorn

Posted: 16 May 2005 23:29
by Marshy
Hey, I'm sorry, I don't know if this is a thick question or not..
A LOT of people have mentioned the "Silverline Station". I don't think I have this one, so could someone post a screen of it so I can check if I haveit or not? If not, then a download link would be good too.
Great project btw.
Posted: 17 May 2005 00:07
by krtaylor
The Silverline Set includes two stations - a sort of generic platform station, and a wood-log loading station. The wood station will be included in the next version of the Industrial Stations, and the platform station will probably wind up in a future version of the Generic Stations. So if you wait, you'll get the stations soon enough anyway. The Silverline GRF was always somewhat buggy; the graphics will be recoded and retested when they're integrated into the other sets.
Posted: 17 May 2005 00:10
by lobster
speaking of wood stations, i think we'll have to get one into the PGS set. it's along with the iron ore some of the less supported station subjects, which also clarifies my opinion about that wood station from the silverline.

Posted: 17 May 2005 00:30
by krtaylor
Well, I know we have those beautiful freight station platforms etc. from Born Acorn in the PGS set, and they do belong there. It seems to me that it's more logical to include new industry-specific stations in the Industrial Stations set, because that's what the Industrial Stations set is for. Born Acorn's statios are industrial, true, but they are fairly generic, and thus logically fit in the PGS set.
Posted: 17 May 2005 00:41
by Aegir
Personally, I dont see the point of specific industry stations in P:GS. Aswell as merging jcindsta with this set. Project: Generic Stations aims to do just as the name suggests, provide generic stations.
I say, with the wood stations and the Iron ore station Born is cooking up, shift them over into jcindsta (Give that to Oracle to code, lighten my load up a bit

). For the passenger station in the Silverline set, I have no problems with integrating them, I can already think of a good use for them, and the sprite set Arte made for that set has lots of pottential for other uses.
But first I gotta finish what I am allready working on

.
Posted: 17 May 2005 00:57
by krtaylor
Well, you and I agree, and you're the coder, so that settles that I think!
But, don't take this as discouragement from drawing more specific industry stations, people! Oracle will be glad to include them in that set.
Posted: 18 May 2005 10:27
by Aegir
Heheheh, dont make too many assumptions on what the coder will be 'glad' to do, sure, its fun, but having hundreds of sprites pop up out of no-where all wanting to be coded is a tad frustrating

.
Anyways, I have in my hot little hands, a new build (2.15) of GRFMaker, which no-longer screws up. Turns out it was an error in the algorythm that translates .lst's to .nfo's. I wasnt aware .nfo's were used during compile, but supposedly they are.
/me shrugs
So its back to coding now. Im going to work on some concepts before begining the bulk of coding.
Also, on the Side/Island/Dual front, Im going to keep just island and dual, like Oracle is. With certain stations however, I may use Side aswell. They will all be appropriatly tagged in game though, to prevent confusion.