Planeset patch (now supports Planeset 1.5)

[mart3p]

I have written a patch to allow OTTD to use Planeset 1.2.

I initially concentrated on getting custom helicopter rotors working but many other features such as the Concorde droop nose and cargo plane loading doors are now also working.

You can get Planeset here

If you want a win32 exe see below or use the miniIN which has the Planeset 1.5 patch included.

Edit: Planeset 1.5 support added 22/06/06

Edit: Patch updated to r5350 24/06/06

Edit: Patches removed. The only patch that is now required to support Planeset 1.5 is the NewGRF Livery Selection/Cargo Subtypes patch. 29/06/06

Edit: The Livery Selection/Cargo Subtypes patch is now in the trunk. Planeset 1.5 can now be used without additional patches. 6/10/06

[DaleStan]

* Chinook goods sling disappears before landing at an airport.

That's not a bug, it's a feature. And it's a feature of the PlaneSet. The other two options are:
1) Have the Chinook float absurdly high at the airports/heliports. (breaking at least the aircraft details window, possibly other windows)
2) Have the slung cargo move off to the side as the Chinook lands.
I decided that
3) Have the cargo sling detach before the Chinook lands.
was the best choice.

As for the Osprey rotors, they depend on variables E2 and E6 functioning as they do in TTD.

If you want to implement the third byte of var 44 as listed at the end of this post, I'll use that instead.

[mart3p]

Thanks for the info DaleStan. I thought I was going to have to dig into the nfo file to find out exactly how the Osprey works. I will check out E2 and E6 as you suggest.

As for the Chinook goods sling I understand the problem but the bug I have at the moment is that it behaves differently at an airport to a heliport. At an airport the goods disappear just before the copter makes its decent. At a heliport the goods disappear as it lands.

Win-32 exe added to first post.

[DaleStan]

As for the Chinook goods sling I understand the problem but the bug I have at the moment is that it behaves differently at an airport to a heliport. At an airport the goods disappear just before the copter makes its decent. At a heliport the goods disappear as it lands.

Oh. It sounds like the heliport is correct, but I have not checked.
The Chinook is also dependent on var E2. (As is the Concorde)

I thought I was going to have to dig into the nfo file to find out exactly how the Osprey works.

You may have to do that anyway. But I'll give you a bit of a hand. This is the code that controls the Osprey's engine nacelles:

Code: Select all

//IDs 30..32 are nacelles vertical/diagonal/horizontal, resp.
   31 * 14	 02 03 33 82 B4 00 FF 01 31 00 00 1E 32 00
   32 * 26	 02 03 34 82 E2 00 FF 04 30 00 17 17 30 00 19 1A 30 00 1C 1C 31 00 00 07 33 00
   33 * 18	 02 03 35 82 E6 00 FF 02 32 00 00 00 30 00 01 03 34 00

The Chinook's sling is controlled by:

Code: Select all

//ID 00: no sling
//ID 0C: Slung cargo
 1761 * 14	 02 03 20 82 44 08 FF 01 00 00 00 08 0C 00 // Airport
 1762 * 14	 02 03 21 82 44 08 FF 01 00 00 00 48 0C 00 // Heliport/Oil Rig
 1763 * 30	 02 03 22 82 E2 00 FF 05 00 00 00 07 20 00 17 17 20 00 19 19 21 00 1A 1A 21 00 1C 1C 0C 00

But that will change; when I wrote that, I did not realize that there was an important distinction between heliports and oil rigs. (I'll add check of the second byte of var 44 and another copy of sprite 1761/1762.)

(The sprite numbers in these snippets are useless at best; search for the data if you want context.)

[Darkvater]

I had a quick look at the patch and have some comments:
- Try to use proper types. For example I assume sprite_num is a sprite, so it should be a SpriteID.
- Also check those types properly. If your rotorsprite is an int (which I assume is supposed to be a SpriteID), check it with == 0 and not with ! for a zero value since it is NOT a boolean.
- Avoid magic numbers at all costs. In the code below what the heck is 0xEA0???

Code: Select all

w->cur_image = 0xEA0; ///< This avoids a glitch with the rotor sprite when first leaving hanger.

- I am not going to complain (yet) about the coding style

[Invisble]

Good work on the patch, however after playing with it for a short while I have noticed that I am experincing a large amount of Lag. I.e. Trains, aircraft and everything else moves slowly, and hitting the fastforward button does not seem to work.

[mart3p]

@Darkvater
Thanks for looking and for you comments. I will sort out my use of types as you suggest.

what the heck is 0xEA0???

The short answer is I don't know! I copied this magic number from the code a few lines earlier where the vehicle is initialised. As I was trying to do the same thing to initialise the rotor I used the same value. I assume it indicates that a custom sprite will be loaded later. I will look into it.

And as for coding style, thanks for not complaining. I did say in the first post "don't look too closely at the code"!

@DaleStan
Thanks again for your help. I've sorted out variables E2 and E6 and now have the Osprey working quite well. I am now having fun trying to implement variable 47.

@Invisble
Thanks for trying it! I think the lag you have experienced is partly explained by the huge number of GRF debug messages being generated.
I'm working on it.....

@All
I will post an updated patch and win32 exe in the next day or two.

[mart3p]

Sorry about double posting, but here's an update

Fixed:
*Implemented GRF action 2 variable E2 for aircraft. (Used for alternative sprites set by the vehicle's movement state).
*Partially implemented GRF action 2 variable E6 for aircraft (Used for alternative sprites set by the vehicle's movement action). It's enough to keep Planeset happy.
*Implemented GRF action 2 variable 44 for aircraft. (Used for alternative sprites set by the aircraft info (height and target airport)).
*Implemented GRF action 2 variable 47 for aircraft. (Used for alternative sprites set by the aircraft's cargo info).
*Osprey now shows correctly positioned nacelles in all conditions (I hope).
*No more GRF error messages.
*Improved typing of variables.
*Removed most of the magic numbers.


Edits to the first post:
*Updated the bug list.
*Updated the patch file (made against r4145 ).
*Added a new win32 exe file.

[DaleStan]

Looking much better than the trunk's handling of the PlaneSet, but there's still a ways to go. You're welcome to class some of these (especially 1, 5, 6, and 10) as "Not my problem".

The bugs I found:

1. Callbacks 15, 19, and 33 are all non-functional.
2. The 747's nose (in the cargo livery) is non-functional (note that the noses should only swing open when loading solid, non-pax cargos; the nose should stay closed when loading Oil, Water, &c.)
3. The Concorde's nose drops late and rises early on take-off. (all four airports)
4. The Concorde's nose rises late on landing (city, metropolitan, and international airports)
5. The Ruslan is built carrying passengers.
6. The hangar window sprite is not refreshed when refitting the 747 or 747 EUD between pax and cargo liveries.
7. The Chinook does not drop its cargo prior to landing (if it's on the ground (this includes "in hangar"), it should not have slung cargo.)
8. The Osprey's vehicle details window does not reflect the current position of the nacelles.
9. The Osprey's nacelles go vertical early for most takeoff and all landing operations.
10. The vehicle details window, in general, is not refreshed as often as it should be.

Callback 15 may be non-functional because I'm using the "return calculation result" feature (<nvar>==00), but the other two callbacks do not use that feature.

The Concorde's nose should droop immediately upon entering the runway, and should stay down until the climb is completed. After landing, the nose should rise before the plane leaves the runway.

The Osprey's nacelle rules are:

1. Depot and purchase list: Horizontal.
2. Loading/Unloading: Vertical.
3. All other ground operations (all ground motion): Diagonal.
4. Vertical flight: Vertical.
5. Horizontal flight at speeds 240 MPH and below: Diagonal.
6. Horizontal flight at speeds above 240 MPH: Horizontal.

(Summary: If either X or Y are changing, nacelles are not vertical.)
1, 2, 4, and 5 are always obeyed. The other two are sometimes obeyed.
Four out of six is a substantial improvement, though; I think trunk gets one. Maybe.

I can confirm the Ruslan issue, but not the Chinook issue; could you be more descriptive?

[peter1138]

Nice work. I had done a bit of that but didn't get past translating from ottd to ttdp aircraft state.

I would keep the enums for translating to TTDP aircraft state within newgrf_engine.c, as they're not used elsewhere...

[mart3p]

DaleStan, excellent feedback that’s exactly what I need to encourage me to take this further, and I see from your bug list that there is some way to go!

I started out studying the OTTD code just out if interest, as I have loved playing TT, in all its forms, for many many years. I recently acquired a copy of MSVC6. I have never before done any serious programming in C, although I have done a fair amount of programming in other languages - mainly VB. I thought checking out the internals of OTTD would be a great way to learn C.

Any suggestions, comments, help, criticism etc. are therefore very welcome, I can only learn more.

Peter, thanks! - as a great admirer of your work... well, thanks.

[orudge]

Mmm, looks good. Keep up the good work - anything to improve newgrf support in OpenTTD I heartily approve of. Will be nice to use the Planeset fully, too!

[mart3p]

I can confirm the Ruslan issue, but not the Chinook issue; could you be more descriptive?

Here's the problem...

[mart3p]

I fired up TTDPatch for some comparative testing and look!!!

Stepping though the OTTD code the problem seems to occur when the Action 82, that selects sprites on the basis of cargo class, returns ID 0B for Goods (Planeset.grf sprite 959). ID 0B is the result of the Random Action 83 that selects one of four colour sprite sets (Planeset.grf sprite 950). These sprites show the goods sling.

It would appear that the Action 82 returns ID 0C for Liquids (Oil), which is the result of the alternative Random Action 83 (Planeset.grf sprite 951) selecting the other four sprite sets showing slings. The difference though, is that there is an action 3 which is returning ID 60 for Goods. ID 60 is the beginning of the chain, that is controlled by the aircraft movement status, the height above the ground etc. which returns the correct sprite sets.

But I've probably got all the above completely wrong. I hate stepping through re-entrant code, you soon become very lost. And I've been looking at so much nfo in the last few days that it all becomes a blur.

[DaleStan]

I fired up TTDPatch for some comparative testing and look!!!

Great. Just great. I broke the Planeset, didn't I?

I broke it good. Not only did I break the Chinook, I also broke the 747s.

Time for a bugfix release, and then I'll go through and check the associated "bugs" to see if they still exist. (EDIT: Sorry, that's not going to happen for another 12 hours or so.)

BTW: that's Action 2 type 82/83. The only defined actions are 00..12.
Sometimes I get sloppy and refer to "actions" FE and FF, but those are data block entries that start with an FE or FF byte, not true actions.

[Invisble]

OK, possibly a noob question. But how do you get the chinook and the other planes (such as the Ruslan)? I have the patch, I have the planeset 1.1 grf file, but still I cannot get things like the chinook to show up (only the silorsky and the eurocopter)

[mart3p]

Great. Just great. I broke the Planeset, didn't I?

Well that's one I can cross off my bug list!

BTW: that's Action 2 type 82/83.

Noted.

But how do you get the chinook and the other planes...

What year have you reached? The Chinook and Ruslan show up around 1981, the Osprey around 2004.


DaleStan, I have gone through your bug list. My comments:

1. Yes - I'm not even going to start looking into callbacks yet. There is plenty else to do and at the moment. I just about know how callbacks work now, after reading Patchman's GRF wiki page (about 10 or 15 times) and going through your NFO code, but I think I need a somewhat better understanding before touching this.
What I do know is that where you are using callback 15 for the Chinook, you are passing it a value from an action 2 type 85. Word and double-word variation action 2s are not (currently) supported by OTTP.
2. Yes - It's the same problem with the Ruslan. I will look into it.
3. Yes - I agree. I'm working on it.
4. Yes - Closely related to problem 3. I'm my idea works it will fix both.
5. Confirmed - Will look into it.
6. Well it seems to work here if the game is running, but it doesn't update when paused. Same applies to the vehicle list window.
7. Closed.
8. Yes - I will look into it.
9. I think it's actually vertical early on landing but late for take off. This bug has the same causes as 2 and 3.
10.- Well I agree but I think any fix for this would be a separate patch.

[mart3p]

I’m going to have to double post!

Another update - latest patch and win32 exe in the first post.

Fixed:
*Ruslan and 747 (in the cargo livery) noses now open when loading/unloading.
*Chinook (with internal cargos) rear door now opens when loading/unloading.
*Concord's nose now raises and lowers at the correct points during takeoff and landing.
*The Osprey's engine nacelles now operate correctly in all conditions (I hope).
*All window's sprites are now refreshed when refitting the 747 or 747 EUD between passenger and cargo liveries. It sometimes takes a second or two, but that is also the case with train refits.
*Magic numbers (mostly) removed from code.

Known bugs and limitations:
*Callbacks for aircraft are all non-functional. OTTP currently supports a few callbacks for trains only. This means refit cargo capacities are not set correctly and you don’t get the intended sound effects (zeppelins sound like helicopters) .
*The Ruslan is built carrying passengers.

[DaleStan]

Much improved.

1. Yes - I'm not even going to start looking into callbacks yet. There is plenty else to do and at the moment. I just about know how callbacks work now, after reading Patchman's GRF wiki page (about 10 or 15 times) and going through your NFO code, but I think I need a somewhat better understanding before touching this.

You're in good company. When I was learning NFO, callbacks were one of the last things that clicked.

What I do know is that where you are using callback 15 for the Chinook, you are passing it a value from an action 2 type 85. Word and double-word variation action 2s are not (currently) supported by OTTP.

Actually, all of the planes use CB15, and all of them use nearly identical variational 2s to return the result. (Only 1A's and-mask gets changed.)
In any case, word/doubleword varactions probably belongs in its own patch; the devs like lots of small patches. (/me bugs Peter1138)

10. Indeed. It's an issue in TTDPatch too, though Patch does^H^H^Hid more frequent updates than Open.

And an update as to the state of the bugs, as I see it:

1. Callbacks: non-functional, as advertised.
2. Noses for cargo planes: Partially my bug, and improved. The noses open and close appropriately everywhere (with the exception of goods, but that's due to a missing CB19), but in the vehicle list and the details window, it closes as soon as the plane finishes loading. In the main view, it does not close until the plane starts moving. Either would be acceptable, IMO. (To see this, fill up an airport so the first cargo plane finishes loading before the last gets to its gate.
3. Fixed.
4. Fixed.
5. Ruslan built carrying passengers: Still present, as advertised
6. Fixed.
7. My bug, fixed.
8. Osprey's nacelles always horizontal in vehicle details and aircraft list: Still present.
9. Fixed.
10. Fixed.

Just to make sure no one gets complacent[0], Planeset 1.5 may contain UTF-8 encoded strings and will contain strings containing code 81, though these are also probably not your problem, mart3p.

[0] No, I'm not actually that evil. The UTF-8 is so I can chuck a few Russian characters in, and is optional, and the code 81 is to save me a substantial headache if/when I translate " (solid)" and " (liquid)".

[mart3p]

DaleStan: thanks again for testing. My comments:

2. Confirmed. I had a quick look at this one and should be able to fix it.

5. As I've now found that TTDPatch has this same issue (see here), I have a problem with this one. I can fix it so the Ruslan is built not carrying passengers by checking the cargo refit mask. But on what basis should the alternative cargo be selected? I am also going to have a problem if the nominal passenger capacity remains at 150. OTTP divides the passenger capacity by 4 to determine all cargo capacities except mail and goods. Ideally the nominal passenger capacity should be 600. But this may have to remain broken until it's decided how TTDPatch will handle cargo aircraft.

8. I can no longer reproduce this one here. The windows are sometimes slow to update but that's due to 10. See screenshot...