Romania in OpenTTD

[andythenorth]

I code my trucks with GRFMaker.

Oops, sorry forgot about GRFMaker. I can't help, but it looks like Andersl has a solution?
cheers,

Andy

[Cudar]

AndersI: I still don't understand this... You say that I make a normal sprite block, where there are those little 1X1 squares and the vehicle list sprite near the normal sprites. That's OK. But I don't know how to select those sprites. If I select all of them I think won't be good. Or not? If the vehicle is full, would transform into those little sprites. Or if I make two different sprite block, what ID should I give to them? I tried to make a such sprite block, I gave a different ID to it, and I typed the number in the block where I need to write the vehicle sprite ID. I hope you understand what I wrote here... But the result was the same, the error massage appeared. So can you tell me, in detail, what I need to do, please?

[Sensation Lover]

Realy good job guys with the new vehicles!!!

[AndersI]

Cudar: I've PM:ed you a copy of my Swedish set (not the latest version, though). Look at the R steamer to see how I have solved it.

[Cudar]

I don't know, I tried to copy your R steamer, but it still not works. The trailer doesn't need an assign block? Because it works only if my make that assign block, but still with that error massage.

This is my error massage

error massage.PNG (3.44 KiB) Viewed 4153 times

The problem is that there is capacity in the trailer, that must be visible (wood and steel), and can't be coded in the first part of the truck, like at the box van. If I make any type of vehicle list sprite block (classic or normal sprite block made as vehicle list block) this massage appeares at these trucks.

[AndersI]

The problem is that there is capacity in the trailer, that must be visible (wood and steel), and can't be coded in the first part of the truck, like at the box van.

OK, that's more than I know - I've only done articulated engines completely without cargo capacity. It might be a question of callbacks, something I have studied very little so far. I have also only tested my code in TTDPatch, so there might be some difference in OTTD.

Why can't you have the capacity on the lead car? (shouldn't it work, even if it's not 'realistic'?)

[andythenorth]

[It might be a question of callbacks, something I have studied very little so far. I have also only tested my code in TTDPatch, so there might be some difference in OTTD.

It is a question of varaction 2 to setup the vehicle menu sprite (although you don't need a callback for it). I use this code (from DJ Nekkid). Can grfmaker apply varaction 2?

Code: Select all

 -1 * 14	 02 01 B2 // provide correct refit/capacity information in buy menu (credits to DJ Nekkid for solution)
               82 40 10 FF // check vehicle length    
               01 // check one range
                 F1 00 00 00 // if length is 0 use purchase menu sprite
               A1 00 // 

[AndersI]

GRFMaker can do varact2, but the internal tables don't allow the same things for road vehicles as for trains. Specifically, the 82/86/8A ('related object') is missing. Maybe it's just a matter of adding this to the GRFMaker tables? I'll try to get some time tonight for a test...

[frosch]

I don't know, I tried to copy your R steamer, but it still not works. The trailer doesn't need an assign block? Because it works only if my make that assign block, but still with that error massage.

error massage.PNG

The problem is that there is capacity in the trailer, that must be visible (wood and steel), and can't be coded in the first part of the truck, like at the box van. If I make any type of vehicle list sprite block (classic or normal sprite block made as vehicle list block) this massage appeares at these trucks.

I assume you already know about callback 16 (articulated parts). Likely your current action3 of the front part distinguishes between cargo 0xFF (purchase list) and the default case.
To make the articulated vehicle work, you have to supply callback 16 for all cargo types, i.e. also in purchase list. And it should return the same engineids in all cases.
Most (if not all) newgrfs that caused this error message only implemented cb 16 for the default case, and forgot the purchase list. Though you won't see the articulated parts in the purchase list, you still have to supply them, so capacity and refittability is known.
In the easiest case [1] you only need to check the callback id in the purchase-list chain and then link to the same action2 chain which also handles cb 16 for the non-puchase-list case.

[1] Neither livery-override nor accessing variables of the first part works in purchase list (and only partly when building). If you need those things will become much more complicated.

[andythenorth]

In the easiest case [1] you only need to check the callback id in the purchase-list chain and then link to the same action2 chain which also handles cb 16 for the non-puchase-list case.

(assuming you've seen DJ Nekkid's solution - code above)...in that case is DJ's code for checking vehicle length actually necessary? Or can I just run cargo FF through the same action 2 chain as the other cargos?

EDIT - I guess I should just go off and try instead of asking. Maybe I will later

cheers,

Andy

[Cudar]

My English is still not perfect, Frosch, I don't understand exactly what you wrote. I understand that you say, that I need to set the callback to the vehicle sprite block? But how I need to do that exactly? It's true, the problem is that in the buy list the callback 16 doesn't work.
Andy: I saw that code, what you wrote. I don't code with NFO, but somehow can I add it to GRFMaker? There is a manual NFO block button.

[DaleStan]

It's true, the problem is that in the buy list the callback 16 doesn't work.

Yes and no. CB 16 does get called in the purchase list, but you didn't supply a handler for it, so Open falls back to the Action 0 settings.

[Cudar]

[It might be a question of callbacks, something I have studied very little so far. I have also only tested my code in TTDPatch, so there might be some difference in OTTD.

It is a question of varaction 2 to setup the vehicle menu sprite (although you don't need a callback for it). I use this code (from DJ Nekkid). Can grfmaker apply varaction 2?

Code: Select all

 -1 * 14	 02 01 B2 // provide correct refit/capacity information in buy menu (credits to DJ Nekkid for solution)
               82 40 10 FF // check vehicle length    
               01 // check one range
                 F1 00 00 00 // if length is 0 use purchase menu sprite
               A1 00 // 

Now, my question is about this, that how I can use this code (if it would help for me). Can I include this code in GRFMaker, in a manual NFO block? I copied the code, but it says, that incorrect hexadecimal code is given. If you tell me, which code means what, I would try to do something with it. Or it's too complicated?

[frosch]

I cannot help you with grfmaker, I only know nfo

But the code you posted looks wrong. One cannot access variables of the "related" object in purchase list. Variable 40 is not available either. The correct method to check for purchase list is cargotype 0xFF in action3. (the cargotype in var 47 will refer to the default cargo, not 0xFF, in recent versions)

However, generally try to not make capacity of articulated parts depend on the front vehicle if possible. That won't work in purchase list and you will need very dirty complicated tricks (some are in http://bugs.openttd.org/task/2581 ) to make it work, and even then it might stop working once someone finds a way to support access to front-vehicle- and chain-related-variables.

[andythenorth]

I'm kind of going off-topic (sorry), but anyway...

But the code you posted looks wrong.

Interesting. This code was given to me by DJ Nekkid. It prevents OpenTTD showing the error message "vehicle's capacity differs from refitted capacity" for articulated road vehicles. I've been using it in HEQS and it does appear to work when used as a varaction 2 for for the default cargo on the lead vehicle. However cargotype 0xFF *must be removed* from the action 3 for the vehicle or the code will fail. (I imagine that if cargotype 0xFF used the varaction 2 above it would actually work fine, but I haven't tested).

If the above is crazy talk, we need to figure it out because me and DJ have been treating this as a valid solution; it's a fair amount of copy and paste fun to change it in HEQS for example

However, generally try to not make capacity of articulated parts depend on the front vehicle if possible.

I tried some hideous code for this last year and it was incredibly painful and didn't work. For HEQS I have an alternative solution, which is use simply define more trailer vehicles each with own action 0 / action 3. Each trailer has a different capacities, but shares the same action 2 chain and real sprites.

The lead vehicle then chooses which trailers to build based on whatever capacity is required. In HEQS for example, bulldozer trailers change capacity over time as the vehicles get more powerful.

This consumes a *lot* of vehicle IDs, but unless it's a huge set, it should be manageable within the ID limits (256, but all trailers have to use IDs below 128). If a set manages to use more than that is probably either (a) too big and confusing for players or (b) doing some inefficient stuff that could be done with varaction 2 somewhere.

cheers,

Andy

[Cudar]

At the box van, oil tanker and livestock van, I coded the capacity to the first part of the truck, but at the timber truck I can't, because otherwise the wood wouldn't appear on the trailer.

If I leave the error massage there, it will generate big problems, or not? It appears only one time...

[Cudar]

Hello! I made a compatible version of the grf with the Long Vehicles by George. The problem was, that the prices of the vehicles became very high, if I loaded LV4 with RVR. Now the prices remain the same.
Note: The LV4 compatible grf can't be used if LV4 is not loaded.

rvr_060-LVcompw.GRF

(54.08 KiB) Downloaded 139 times

[ColdIce]

I like the progress so far. thank you guys for your effort.

now.. i see on your website "There also plans for a Romanian Infrastructure Set".. I just can`t wait to see how you will draw holes in the asphalt and make vehicles avoid them

[Cudar]

I just can`t wait to see how you will draw holes in the asphalt and make vehicles avoid them

Yes, but this is the far future yet. Now I concentrate on the Road Vehicles in Romania.

[DJ Nekkid]

sorry i didnt see this before, but that piece of code is a small piece of code to have as little as little duplicate code as possible. You can ofcouse "only" use cargotype FF in the action 3, but that skips all other code, inluding callbacks and such...

<action2 for the P-list>
<all var2s for the vehicle>
<the code andy posted>
<all callbacks and such>
<action3 with only ref to the callback CID>

See the ZHESM-code in the dutchset for an example. (devzone.openttdcoop.org)