Transport Tycoon Forums

mart3p wrote: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.

The correct handling is defined, just not implemented anywhere.
Cargo: First available cargo (in this case, coal)
Capacity: Whatever callback 15 returns. If callback 15 fails or is not enabled, pax_capacity/4+mail_capacity/2 tons/items (AIUI. Patchman? (or check how the planes from Planeset 1.0 or the 459 Remix do it.)), except for pax (as defined), mail (twice as many bags), and goods (twice as many crates)

As I explained in the PlaneSet thread, the 150 "capacity" is a workaround for a TTDPatch bug. With the possible exception of the purchase list, that number should never actually be used.

8: In that image I see only horizontal nacelles in the vehicle list and details window, but the vehicle window clearly shows non-horizontal nacelles for two of them.

This may not be a bug, provided the rotors and the nacelles always agree, and provided livery refits (cargo- or F2-based) are properly reflected in the details and vehicle list.

Dalestan, the Osprey nacelles where moving correctly in the aircraft details window and aircraft list windows. What was not correct was the rotor movement, they where always pointing forwards. This is now fixed. I am not totally happy with what I had to do to make it work, and I'm still looking for a better solution, but at least it now works correctly.

I do not yet have the cargo capacity working. Although I now have some code working to implement callback 15 for aircraft, it is not much use as all Planeset's cargo capacity calculations depend on action 2 type 85. I have looked at what it would take to get this working, but I have heard that Peter1138 already has some code written for action 2 types 85 and 86.

Update - latest patch and win32 exe in the first post.
Fixed:
* Fixed rotor movement in vehicle list window and vehicle details window.
* Renamed some functions for better consistency with existing code.
* Removed some unnecessary variables.

I have a bug that might be triggered by the planeset patch, but as I played with the 6 new airports patch as well, I don't know that yet.

I noticed that on certain tiles when planes move right-down (screen-wise) or right-up parts of the head and tail of the aircrafts are overdrawn by ground sprites. This doesn't happen everywhere, it's certainly reproducable on the runways of the new Intercontinental airport.

I'll try to dig deeper to find whether the patch, the 6 new airports or the actual planeset are at fault, but somebody else might have an idea here.


This aside, I think this patch is a great work and should be posted to http://bugs.openttd.org/ so it might have a chance to be included into trunk. I might try to bug a dev about it later.


-- Michael Lutz

Michi_cc wrote:I have a bug that might be triggered by the planeset patch, but as I played with the 6 new airports patch as well, I don't know that yet.

I noticed that on certain tiles when planes move right-down (screen-wise) or right-up parts of the head and tail of the aircrafts are overdrawn by ground sprites. This doesn't happen everywhere, it's certainly reproducable on the runways of the new Intercontinental airport.

I'll try to dig deeper to find whether the patch, the 6 new airports or the actual planeset are at fault, but somebody else might have an idea here.


This aside, I think this patch is a great work and should be posted to http://bugs.openttd.org/ so it might have a chance to be included into trunk. I might try to bug a dev about it later.


-- Michael Lutz

I think that one is an error in my airports patch. Granted Ive not looked into why it happens, but Im pretty sure its my fault The error will be in the sprite definitions in station_land.h

richk67 wrote:I think that one is an error in my airports patch. Granted Ive not looked into why it happens, but Im pretty sure its my fault The error will be in the sprite definitions in station_land.h

Might be, but it doesn't happen on vanilla OpenTTD with only your patch and default aircrafts, so there's obviously some kind of connection.


-- Michael Lutz

Michi_cc wrote:I have a bug that might be triggered by the planeset patch

I don't think this is a bug with either patch. The screenshot below, was taken in r4298 with no patches added and no GRF files. Was the edge of your airport built on a slope? If so I think this is a known bug, reported here.

Thanks for testing my patch with Rich's new airports. I have been meaning to do this myself but haven't yet had the chance. I would be interested to hear of any new bugs you find.

Michi_cc wrote:I think this patch is a great work

Thank you.

mart3p wrote:Thanks for testing my patch with Rich's new airports. I have been meaning to do this myself but haven't yet had the chance. I would be interested to hear of any new bugs you find.

Michi_cc wrote:I think this patch is a great work

Thank you.

Your patch is included in the mini IN. I do get a compile warning from it, as noted in the description of the mini IN. Can you take a quick look (maybe need to see if Ive snafu'd something in the integration - unlikely as I think I applied your patch first, and it has given it from day 1! ) Great patch tho. I love all the planeset features.

richk67 wrote:Your patch is included in the mini IN.

That's great news! The patch still has a couple of very minor bugs which I'm currently fixing. I will be posting an update in the next few days.

richk67 wrote:I do get a compile warning from it, as noted in the description of the mini IN.

I haven't seen this warning in MSVC6 but I will check it out. I think it's probably due to declaring sprites as spriteID (as suggested by Darkvater) when most of the other sprites in aircraft_cmd.c are declared as int. If so it's the original code that needs correcting!

richk67 wrote:Great patch tho. I love all the planeset features.

I think your New Airports patch is great, although I have only played with the old Three Airports version. It was playing with it, that gave me the inspiration to get Planeset working with OTTD!

mart3p wrote: I don't think this is a bug with either patch. The screenshot below, was taken in r4298 with no patches added and no GRF files. Was the edge of your airport built on a slope? If so I think this is a known bug, reported here.

You seem to be right here, I've checked my savegame again and indeed, the problems happen on tiles build on slopes. I've migrated the bug to new tracker, so it will hopefully get fixed sometimes.

-- Michael Lutz

richk67 wrote:I do get a compile warning from it, as noted in the description of the mini IN.

It's fixed, I'll post a new patch tomorrow morning. It was a typo but MSCV6 didn't spot it, even with compile warnings set at the highest level!

Michi_cc wrote:

mart3p wrote: I don't think this is a bug with either patch. The screenshot below, was taken in r4298 with no patches added and no GRF files. Was the edge of your airport built on a slope? If so I think this is a known bug, reported here.

It will only be fixed when 32bpp is done and a new spritrehandler is written. These kind of bugs are inherent to the game-engine in use, and therefoe unsolvable (quickly)

I'm afraid that feels very much like a cop-out of an answer to me.

This bug, if it ever existed, was fixed in TTDPatch some time before 2.0 rev 1[0], which was released two years, five months, and twenty days (903 days) ago.
Reading the changelog makes me suspect the fix appeared, at the latest, in 2.0 beta 4 (two years, seven months, and twenty-three days; 967 days)

[0] Translation: I just checked 2.0r1, and could not find evidence of this bug.

Last time I played TTDPatch, they also have these clipping issues. When I have time I'll make a screenshot of it.

The latest patch against r4412 and a win32 exe are now in the first post.

Fixed:
* Compile warning.
* Noses for cargo planes now close as soon as the plane finishes loading (main view now agrees with vehicle list and details windows) (number 2 in Dalestan's bug list).
* Small bug with position of Concorde nose while moving to takeoff position at international airport.
* Improved commenting.

DaleStan wrote:mart3p: PlaneSet 1.5 can pretty easily contain code to set the Ruslan's capacity to 400 pax in Open. (As a matter of fact, such code is already written, just not tested.)

That would be great, although as you said before, once callback 15 is working this will only effect the purchase window. It would be good to have this correct though.

Current progress on Planeset cargo capacities:-
I have working code for callback 15.
I have the purchase window displaying the first available cargo for non-passenger aircraft.
I have working code for action 2 types 85 and 86 but it needs lots more testing.
I am currently working on advanced action 2s and have it sort of working.

As I'm trying very hard not to break any existing code I have quite a lot of testing to do before I'm prepared to release any of this in a patch. Can you suggest
any existing GRFs that use action 2 types 85 or 86 (non-advanced) for test purposes? The only one I have found so far is UKRS but they are only used there for selecting
new sounds, which isn't (yet) supported by OTTD.

mart3p wrote:Can you suggest any existing GRFs that use action 2 types 85 or 86 (non-advanced) for test purposes?

Ah. The advantages of knowing the NFORenum source backward and forward. Makes searches like this far easier.

I have lots of files using non-byte varactions in my test suite.
Unfortunately, (1) most of them are bits of the planeset and (2) all of the remainder (except the UKRS) are industry or station GRFs.

If you're interested anyway:
http://www.tt-forums.net/viewtopic.php?p=361284#361284 (newindustry)
http://george.zernebok.net/newgrf/downloads.html#decs (ECSAgriw and ECSWoodw, both newindustry/newcargo)
http://as-st.com/ttd/newusa/download.html (JCIndStaw, newstations)

You may be stuck coding it yourself. One thing I did, at one point, was "*0 02 03 XX 89 91 46 FC FF 03 00 00 00 00 00 B5 05 00 00...", to convert from date of last service (variable 92, aka the second and third byte of variable 91) to year of last service.

I had a look at the diff and have a few questions:

1. DrawAircraftImage(). This function has become very confusing. It draws the plane and changes its state? Draw..() implies you only READ the data and draw it, not change it.
2. Judging from the diff you translate the TTDP/OTTD aircraft states each time it is needed. Is it not easier to do this translation only once in the beginning and in effect changing the grf file (in memory)?

Darkvater wrote:2. Judging from the diff you translate the TTDP/OTTD aircraft states each time it is needed. Is it not easier to do this translation only once in the beginning and in effect changing the grf file (in memory)?

I strongly suspect that insanity lies in that direction.

Consider just variable E2 (if you prefer E6, it should be simple to change it to variable E6), and the following <type> : <var> <var-adjust> sets: (which may or may not be meaningful, but are all legal)
85 : E2 00 FF FF
81 : E1 04 FF
81 : E2 04 FF

In each case, how should the <min>/<max> pairs be modified? Or, if you'd prefer to modify something else, what should be modified, and how?

Similar issues apply when a shift-and-add-divide or shift-and-add-modulo var-adjust is used, even when only the eight bits of E2 get through the shift-and part. And then there's advanced varactions.

This is not entirely theoretical; there are definitely circumstances where taking E2 modulo 3 is meaningful. The only reason I didn't end up doing because it would have required an additional pseudo.

Darkvater, thanks again for showing an interest in my patch.

1. I agree with your point concerning DrawAircraftImage(). This was a solution to the problem I had of making the Osrey’s rotors display correctly in the aircraft list and aircraft details windows. As I said in my post above:

I am not totally happy with what I had to do to make it work, and I'm still looking for a better solution, but at least it now works correctly.

I am actually only temporarily changing the vehicle’s state and direction before it is passed to GetCustomRotorSprite(), I change them back to their original values immediately afterwards.
The difficulty occurs because, when a vehicle is displayed in the details window, it must show the vehicle’s current state (livery, loading status etc.) but must always face to the left (i.e. the vehicle’s actual orientation is ignored). The function that determines this is ResolveVehicleSpriteGroup() in newgrf_engine.c. This function normally returns 8 sprites (one for each direction). To display a vehicle in the vehicle lists, the correct sprite (the left facing one) can be selected after the set of 8 are returned by the function.

In the case of helicopter rotors this function will return 4 sprites (one for each rotor animation position). The selection of the sprites on the basis of vehicle direction and in the case of the Osprey, the rotor position (horizontal, vertical or in-between). has already taken place within ResolveVehicleSpriteGroup(). I therefore found it necessary to make these temporarily changes before passing the vehicle to the function.

Perhaps better commenting of what I’ve done in DrawAircraftImage() would help.

If a better solution can be found to this problem I will be more than happy to use it. Please let me know if the above explanation is not clear and I will try to explain in more detail.

2. Unfortunately there is no direct correspondence between TTDP/OTTD aircraft states. In some cases I found it necessary to determine the TTDP patch states using aircraft properties such as its speed or current order status. These can only be determined each time the information is needed.

1) This same issue (the varactions selecting rotors in the details window according to the vehicle's direction, rather than selecting the west-bound rotors) was an issue in Patch for a while too[0]. It may be interesting to ask Patchman how he solved the problem.

[0] Alphas in the 38..42 range, IIRC.