Page 4 of 5

Posted: 02 May 2006 17:46
by c2R
Hyronymus wrote:Can you tell me what grf's you had loaded beside the roadset, DarkVater? I had some glitches with the tubular bridge too but strangely not all the time. I never noticed the glitch with one of Purno's bridges. I'll have to look into it.
I'm getting the same problem with the tubular bridges.

grf settings as follows:

newgrf/arcticsetw.grf
newgrf/cargosetw.grf
newgrf/dbsetxlw.grf
newgrf/elrailsw.grf
newgrf/newshipsw.grf
newgrf/nsignalsw.grf
newgrf/tempsetw.grf
newgrf/trkfoundw.grf
newgrf/tropicstw.grf
newgrf/VolvoTrucksw.grf
newgrf/SpitzerTrucksw.grf
newgrf/ScaniaTrucksw.grf
newgrf/NavistarTrucksw.grf
newgrf/McTrucksw.grf
newgrf/LongBusesw.grf
newgrf/canalsw.grf
newgrf/combroadw.grf 0 1
newgrf/newstatsw.grf
newgrf/newcargow.grf
newgrf/onewayw.grf
newgrf/guiw.grf
newgrf/paperw.grf
newgrf/tramtrkw.grf
newgrf/ccol2w.grf

Kind Regards
Chris

Posted: 06 May 2006 10:31
by Chrill
Is this compatible with OpenTTD?

Posted: 06 May 2006 11:23
by PikkaBird
ChrillDeVille wrote:Is this compatible with OpenTTD?
afaik OTTD doesn't do grf parameters or new bridges, so no.

Posted: 06 May 2006 13:01
by DaleStan
It does parameters in the nightlies, but not new bridges (unless something has changed really recently).

Posted: 06 May 2006 13:15
by Purno
DaleStan wrote:It does parameters in the nightlies, but not new bridges (unless something has changed really recently).
It works quite well in the nightly, I'm using it. But some sprites are placed in front of the wrong sprites, and such. But it works quite well.

Posted: 06 May 2006 14:10
by Born Acorn
DaleStan wrote:but not new bridges
It has newbridges, but it doesn't affect the bridge name (So, for example, Pikka's brick viaduct still displays "Wooden" as a name, but still has 80mph running)

Pillars are a bit off too.

Posted: 06 May 2006 14:16
by DaleStan
I stand^Wsit corrected.

Posted: 31 Oct 2006 12:47
by peter1138
Are there any plans to get this set using GRM for the bridges? Would be nice to avoid the sprite conflict with DBSetXL...

Posted: 01 Nov 2006 04:51
by DaleStan
GRM is cooperative. Until or unless DBSetXL at least marks sprite 1213 (which I don't think it does), GRM won't do much.

Posted: 01 Nov 2006 07:07
by peter1138
Maybe I misinterpreted the spec, but with GRM it should be possible to allocate new sprites and thus not overlap that particular one. That would need a bit of action 6 magic though...

Posted: 01 Nov 2006 07:14
by Hyronymus
I'll have to consult my coder to see what he can do for this set,

Posted: 01 Nov 2006 09:21
by DaleStan
Actually, it's NewStations, not DBSetXL. That doesn't change the material part of the discussion, though.

Feature 08 GRM (general sprites) does not create new sprites[0], it simply allocates TTD sprites that would otherwise be unused (eg the toyland building sprites in the non-toyland climates) to sets that request them. (Most commonly bridge sets, but recolor maps also must be placed in TTD's sprite space.)

Since NewStations doesn't reserve sprite 1213, the GRM implementation is free to assign that sprite to any set that requests it.

To borrow from the Perl documentation, "[GRM reservations] are analogous to green traffic lights: If you have a green light, that does not prevent the idiot coming the other way from plowing into you sideways; it merely guarantees to you that the idiot does not also have a green light at the same time."

(BTW: That's sprite 1213h, or 4627 decimal)

[0] In TTDPatch. AFAICT, allocating up to 14 bits[1] of "Action A" sprites would be conformant, provided that modifications to the first ~5k sprites continue to overwrite the sprites loaded from trg?[r].grf.
[1] But no more. Both sprite-number fields in most sprite dwords are 14 bits wide. Occasionally they may be wider, but GRM cannot know if the sprite is going to be used in such a location.

OT: I'm not aware of any (documented?) way to overwrite the sprites that Open loads directly from autorail.grf, airport.grf, and openttd.grf, with the possible exception of the character glyphs in openttd.grf. Action A sprite numbers above the TTD sprite space would be immediately compliant, and I expect Patchman would be willing give out as many action 5 types as are necessary.
Disclaimer: I do not speak for Patchman, he is quite capable of speaking for himself.

Posted: 01 Nov 2006 09:44
by peter1138
Ah, okay then. I implemented it differently, clearly.

For OpenTTD, it just "reserves" from the current sprite ID and returns that. The sprite replace will then just replace the blank entries. No marker is made for it because nothing would normally replace those sprites, and any future reservation would get a new block.

The vehicle reservation stuff works (mostly) in the same way though.

Posted: 01 Nov 2006 20:14
by Patchman
Just some clarifications...
DaleStan wrote:Feature 08 GRM (general sprites) does not create new sprites[0], it simply allocates TTD sprites that would otherwise be unused (eg the toyland building sprites in the non-toyland climates) to sets that request them.
As implemented, feature 08 GRM actually allocates sprites beyond the TTD sprite range to be safe, i.e. sprites 4900+ in the "other" range of the extended sprite limit, which corresponds to real sprite numbers 4900..16383.

Therefore if one file uses GRM, it is guaranteed[*] that no other file will mess with those sprites. The only collisions happen if neither file uses GRM, or uses it incorrectly.
[1] But no more. Both sprite-number fields in most sprite dwords are 14 bits wide. Occasionally they may be wider, but GRM cannot know if the sprite is going to be used in such a location.
For that reason GRM only returns sprite numbers below 16383. This is not documented; maybe it should be.

[*] An action A attempting to overwrite sprite numbers beyond 4900 will fail unless the file has previously reserved sprites, so it's impossible to overwrite these sprites unless the file uses GRM.

Posted: 01 Nov 2006 20:33
by DaleStan
Oh. OK. In that case...
*sits down*
*shuts up*
*listens earnestly*

Posted: 15 Nov 2006 02:54
by athanasios
Seems that Combined Road Set is incompatible with the Newstations grf (newstatsw.grf).
My Windows TTD crushes when I try to build the first suspension Bridge. (So don't ask for a screensave.) This does not happen with DOS TTD. (A bit odd?)
* I loaded the game with only these 2 grfs to make sure.
* I tried the DOS grf (converted with grfcodec) of CRS in Windows but the problem appeared again. (I did not do the same with DOS Newstations grf, maybe I am lazy after all.)

I like this set, and I hope the new highways will be included in a future version.

Posted: 15 Nov 2006 04:15
by DaleStan
Load them in the other order. CRS and NewStats use the same sprite for different purposes, so until at least one of them uses GRM, this is the only solution.

Posted: 08 May 2007 23:07
by ISA
Bug report!
In tropic clime sandy road crossing have little bug! When train crosses the crossing only one light is plinking but they should plink by turns.
Hope You devs understand what I mean! :)

Posted: 09 May 2007 17:35
by m3henry
a dig scince the day after my previous birthday!
its just a missing action colour, and I didnt think anyone used this anymore...

Re: [REL] Combined Roadset

Posted: 25 May 2008 13:37
by LoWang
I have the same problem with this graphics like with CS road set - all roads are still brown, regardless of the actual year :(
Besides there is a strange blue line on the road side when I build it on the SW-NE direction. I play OpenTTD so maybe it is not ment to be used in it?