[OpenTTD] Military items

[adpro]

Work on version 0.7.0 continues. It's going slowly, but the halfway point is very close.
A few pictures from the current state with modified An-24 and An-26:

mi_v0-7_preview1.png (546.24 KiB) Viewed 16642 times

And voxel model of L-39:

mi_v0-7_l39model.png (345.44 KiB) Viewed 16642 times

and voxel model of AW101:

mi_v0-7_aw101model.png (234.25 KiB) Viewed 16642 times

The Soviet/Russian and American helicopters are still waiting in line for their voxel models.

[belgi]

Work on version 0.7.0 continues. It's going slowly, but the halfway point is very close.
A few pictures from the current state with modified An-24 and An-26:

mi_v0-7_preview1.png

And voxel model of L-39:
mi_v0-7_l39model.png

and voxel model of AW101:
mi_v0-7_aw101model.png

The Soviet/Russian and American helicopters are still waiting in line for their voxel models.

Hello!
This looks very good!
I look forward to you making them. Thanks for your work.
I wish you a nice day

[bassem.90]

Even if it is a military version but I wish that the An-24 and An-26 could be refitted with some airlines liveries like Aeroflot, Balkan, Czech airlines, interflug , polish airlines,Tarom and Malev . Even in air forces some transport aircrafts could be painted in airlines liveries . Thank you
Please as well kindly add Il-62, Il-18 and Tu-154 .

[RoyalExamination9410]

Even if it is a military version but I wish that the An-24 and An-26 could be refitted with some airlines liveries like Aeroflot, Balkan, Czech airlines, interflug , polish airlines,Tarom and Malev . Even in air forces some transport aircrafts could be painted in airlines liveries . Thank you
Please as well kindly add Il-62, Il-18 and Tu-154 .

Don't forget Cubana or Air Koryo for passenger/cargo liveries

[soiiiso]

Hello! I am writing this text using a translation software, so please forgive me if the text may be strange.

Such a bug (?) on all the airfields that come with this set. is there any way to deal with it?
I don't think there is any problem regarding the years it can be used.
I am using OpenTTD jgrpp ver. 0.54.5 and my OS is macOS Big Sur ver. 11.7.8.
Also, someone I know who uses OpenTTD jgrpp ver. 0.53.3 and OS is Windows 10Home has the same symptoms.

I would appreciate your response. Thank you in advance!

[soiiiso]

2023-08-13_12.58.02.png

(141.42 KiB) Not downloaded yet

Sorry, I forgot to paste the image.

[Argus]

It could be a collision with other graphics providing graphics for the airport - especially if something was changed or added during the game. For example, the Korean aviation set and Opengfx+ airports annoy me, but only one airport.

[adpro]

Hello! I am writing this text using a translation software, so please forgive me if the text may be strange.

Such a bug (?) on all the airfields that come with this set. is there any way to deal with it?
I don't think there is any problem regarding the years it can be used.
I am using OpenTTD jgrpp ver. 0.54.5 and my OS is macOS Big Sur ver. 11.7.8.
Also, someone I know who uses OpenTTD jgrpp ver. 0.53.3 and OS is Windows 10Home has the same symptoms.

I would appreciate your response. Thank you in advance!

2023-08-13_12.58.02.png

Sorry, I forgot to paste the image.

Can you attach a list of the newgrf graphics you are using in this game with this bug?

[Retro Aviator]

Love this GRF, especially the transport planes!

Is there any chance we'll get the F-14 Tomcat added? It's a great plane to add with multiple livery refits, especially with the many squadrons that operated it.

[adpro]

Love this GRF, especially the transport planes!

Thanks a lot.

Is there any chance we'll get the F-14 Tomcat added? It's a great plane to add with multiple livery refits, especially with the many squadrons that operated it.

I'm not ruling it out at the moment, but it's not the primary plan. If you would like to speed up the appearance in this GRF, at the moment it would help a lot if you prepare a voxel model in 4:1 resolution. Timberwolf published nice tutorial on YouTube.

[adpro]

When I got back to normal life after resolving health complications and got back to OpenTTD, I was reviewing the status of the development branch for version 0.7.0. The more I thought about the whole thing, I came to a few findings.

Finding 1. A difficult recollection of working in Magica Voxel. It's solved by practice, more practice, and more practice.

Finding 2. Releasing versions according to the original plan is currently quite unrealistic. Restrictions on computer work due to eyestrain restricts evening work on GRF quite a bit, so I am forced to switch to partial updates, quietly one machine one release, rather than keep the helicopters with me for 3 years as there are still quite a few helicopters to complete the release.

Finding 3. Implementing a helicopter model to be consistent with the rotor is often problematic and a lot of model size adjustments are needed. I can see why there aren't that many implemented. All the more kudos to oftcrash.

Finding 4. The way rotors are implemented in the VACE set is probably the only way to implement rotors other than with an external rotor within OpenTTD. For the implementation of the VACE set, oftcrash has my admiration.

Finding 5. Working in PixelTool and MagicaVoxel is a pain for me, I'm more of a coder. That's why I don't really want to do some models But watching the France - Portugal European Championship football match hurt even more , so I tried to refresh my knowledge of working in MagicaVoxel and create CH-53.

Finding 6. I forgot how to calculate coordinates in the JSON file for GoRender, so trying for CH-53 took quite a long time.

Finding 7. MagicaVoxel 0.96 and 0.97 may have different possible coordinate handling, at least GoRender works oddly with 0.96 output and I had to rotate the model along the axes to get the expected output for the spriteset. So far I have been creating voxel files in 0.97 on Windows, but I don't have a complete development environment there, so I converted everything to the development environment on macOS, where only MagicaVoxel 0.96 works. Or it's my fault. I don't get it.

With all this work and thinking, I thought:

Idea 1. Most narrow-body airliners have an almost circular body. Their wingspan varies by generation and motorization. But thanks to MagicaVoxel and its object parts, one could make a basic model of the airliner body, wings, engines (under the wings, aft), a typed cabin and have a kit for multiple aircraft types this way.

Idea 2. I have a desire to implement a cargo submarine, something like Type XIV or Merchant Submarine. But here I ran into a problem. In what scale are ships usually drawn? I've looked at other sets and most have ships 20px wide, no matter what size/legth.

Idea 3. Try to implement a Road vehicle, both normal and with NRT support. Can you tell me on which set would be ideal as an example of NRT implementation?

[adpro]

I ran into a problem with the gorender tool today. Mil Mi-26 was supposed to be 284 voxels in length. MagicaVoxel can handle 256 voxels within a single model. There is a workaround, but gorender renders a blank field when trying to render a spriteset. If the space is reduced below 256 voxels, gorender will render everything fine.
As a result, the Mil Mi-26 is not 284 voxels long, but only 252 voxels long. That means that the rotor is not in its original place, but is moved backwards. At the same time, the rotor is shortened to fit into the reduced space.

Or option two - a bad JSON file setup for gorender and my misunderstanding of how to set it up correctly.

[adpro]

Hello, everyone.

I'm currently reworking the iconic F-16 into voxels and wondering how to resolve variant options (A, C, E, V), upgrades (Block 1/5/10/15/20/25/30/32/40/42/50/52/60/70/72) and external fuel options (wing tanks, belly tank, conformal fuel tanks) in combination with liveries. Added to this is the possibility of varying speeds (max speed with minimum range, cruise speed approx. Mach 0.85 with max range varying according to the amount of fuel).

I thought of possibilities:

A) groups of variants for versions and upgrades
B) variant groups for versions, upgrades and speeds

Ad A) groups of variants for versions and upgrades

Variant groups:

Code: Select all

+ F-16A Block 1/5/10/15/20
  + F-16A Block 1/5/10/15/20
  + F-16C Block 25/30/32/40/42
  + F-16C Block 50/52/50+/52+
  + F-16E Block 60
  + F-16V Block 70/72

Refit options:

Code: Select all

+ Passengers
  + Passengers Default, cruise, int. fuel
  + Passengers Default, cruise, ext. wing tanks
  + Passengers Default, cruise, max. ext. fuel
  + Passengers Default, cruise, CFT + ext. wing tanks
  + Passengers Default, cruise, CFT + max. ext. fuel
  + Passengers Default, afterburner, int. fuel
  + Passengers USAF 20FW 55th Sq., cruise, int. fuel
  + Passengers USAF 20FW 55th Sq., cruise, ext. wing tanks
  + Passengers USAF 20FW 55th Sq., cruise, max. ext. fuel
  + Passengers USAF 20FW 55th Sq., cruise, CFT + ext. wing tanks
  + Passengers USAF 20FW 55th Sq., cruise, CFT + max. ext. fuel
  + Passengers USAF 20FW 55th Sq., afterburner, int. fuel

Every refit option can change speed, range and running cost.

Ad B) variant groups for versions, upgrades and speeds

Variant groups:

Code: Select all

+ F-16A Block 1/5/10/15/20
  + F-16A Block 1/5/10/15/20
    + F-16A Block 1/5/10/15/20 cruise speed
    + F-16A Block 1/5/10/15/20 with afterburner
  + F-16C Block 25/30/32/40/42
    + F-16C Block 25/30/32/40/42 cruise speed
    + F-16C Block 25/30/32/40/42 with afterburner
  + F-16C Block 50/52/50+/52+
    + F-16C Block 50/52/50+/52+ cruise speed
    + F-16C Block 50/52/50+/52+ with afterburner
  + F-16E Block 60
    + F-16E Block 60 cruise speed
    + F-16E Block 60 with afterburner
+ F-16V Block 70/72
    + F-16V Block 70/72 cruise speed
    + F-16V Block 70/72 with afterburner

Refit options for variant with cruise speed (range 460/693/788/927/1022 tiles):

Code: Select all

+ Passengers
  + Passengers Default, int. fuel
  + Passengers Default, ext. wing tanks
  + Passengers Default, max. ext. fuel
  + Passengers Default, CFT + ext. wing tanks
  + Passengers Default, CFT + max. ext. fuel
  + Passengers USAF 20FW 55th Sq., int. fuel
  + Passengers USAF 20FW 55th Sq., ext. wing tanks
  + Passengers USAF 20FW 55th Sq., max. ext. fuel
  + Passengers USAF 20FW 55th Sq., CFT + ext. wing tanks
  + Passengers USAF 20FW 55th Sq., CFT + max. ext. fuel

Refit options for varinat with afterburner (range only 116 tiles)

Code: Select all

+ Passengers
  + Passengers Default, int. fuel
  + Passengers USAF 20FW 55th Sq., int. fuel

So, what do you find better for use in the game?


In addition, to simplify the creation of liveries, I have prepared the model as a base and, thanks to the tutorial from Timberwolf, parts of the model that can be added at any time (depending on the model), such as landing gear, conformal fuel tanks, wing tanks and belly tank. This should make it significantly easier to add new liveries by Air Forces + squadrons. So anyone can draw livery and add pull request/upload voxel with livery and I'll add more parts as needed for all sprites with minimal effort

f-16c_accessories_half.png (110.08 KiB) Viewed 8288 times

[adpro]

I chose variant_group solution definitely. Because cargo_subtype_text is deprecated now (since v1.13). But it need many many many code to add, so massive usage of macros or python generation is needed. I tried on F-16. It take several hours to code, optimize," macronize", optimize, tests.. Uff. It achieved more versatility, but with huge coding or automating code generation.

Output from game during tests:

[+] Spoiler

And with some code:

[+] Spoiler

Code: Select all

/* F-16 A default */
MAKE_SPRITESET_ZOOMX4(spriteset_air_f16a_default, "air_f16_a_default", 0,0,16,22,24,20,25,17)
MAKE_SPRITESET_ZOOMX4(spriteset_air_f16a_default_landing, "air_f16_a_default_landing", 0,0,16,22,24,20,25,17)
MAKE_AIRCRAFT_LANDING_SWITCH(air_f16a_default_status, spriteset_air_f16a_default, spriteset_air_f16a_default_landing)
/* F-16 A external wing tanks */
MAKE_SPRITESET_ZOOMX4(spriteset_air_f16a_default_extfuel, "air_f16_a_default_extfuel", 0,0,16,22,24,20,25,17)
MAKE_SPRITESET_ZOOMX4(spriteset_air_f16a_default_extfuel_landing, "air_f16_a_default_extfuel_landing", 0,0,16,22,24,20,25,17)
MAKE_AIRCRAFT_LANDING_SWITCH(air_f16a_default_extfuel_status, spriteset_air_f16a_default_extfuel, spriteset_air_f16a_default_extfuel_landing)
/* liveries */
MAKE_SPRITESET_ZOOMX4(spriteset_air_f16a_beaf2w2, "air_f16_a_beaf2w2", 0,0,16,22,24,20,25,17)
MAKE_SPRITESET_ZOOMX4(spriteset_air_f16a_claf7, "air_f16_a_claf7", 0,0,16,22,24,20,25,17)
MAKE_SPRITESET_ZOOMX4(spriteset_air_f16a_itaf37w18, "air_f16_a_itaf37w18", 0,0,16,22,24,20,25,17)
...
    /* F-16 A Block 1/../20 | Default camo | Internal fuel */
    item (FEAT_AIRCRAFT, item_air_f16a) {
        property {
            name: string(STR_NAME_ITEM_CAMO_CFG, string(STR_NAME_AIR_F16A), string(STR_LIV_AIR_BASE), string(STR_CFG_AIR_INTFUEL));
            PROP_F16A_INTF
            MAKE_VARIANT_TYPE(item_air_f16)
        }
        graphics {
            MAKE_AIRCRAFT_F16_GRAPHICS(STR_DESC_AIR_F16, air_f16a_default_status, 118, 554)
        }
    }
    SET_AIRCRAFT_RANGE_BASEDON_PARAM(item_air_f16a, 0, F16A_INTF_RNG)
...
#define MAKE_F16_CAMO(pitem_id, pparent_id, pbase_name, plivery, pprop_name, pvariant_macro, pspriteset, prange, pcfg_str) \
    item (FEAT_AIRCRAFT, pitem_id) { \
        property { \
            name: string(STR_NAME_ITEM_CAMO_CFG, string(pbase_name), string(plivery), string(pcfg_str)); \
            pprop_name \
            pvariant_macro(pparent_id) \
        } \
        graphics { \
            MAKE_AIRCRAFT_F16_GRAPHICS(STR_DESC_AIR_F16, pspriteset, 118, 554) \
        } \
    } \
    SET_AIRCRAFT_RANGE_BASEDON_PARAM(pitem_id, 0, prange)

MAKE_F16_CAMO(item_air_f16a_beaf2w2, item_air_f16a, STR_NAME_AIR_F16A, STR_LIV_AIR_BEAF_2W2, PROP_F16A_INTF, MAKE_VARIANT_CAMO, spriteset_air_f16a_beaf2w2, F16A_INTF_RNG, STR_CFG_AIR_INTFUEL)
MAKE_F16_CAMO(item_air_f16a_claf7, item_air_f16a, STR_NAME_AIR_F16A, STR_LIV_AIR_CLAF_7, PROP_F16A_INTF, MAKE_VARIANT_CAMO, spriteset_air_f16a_claf7, F16A_INTF_RNG, STR_CFG_AIR_INTFUEL)

I understand what the authors wanted to achieve.
Variant_group is well usable if we want to interchange a specific livery with another type in a specific livery. If we are playing the game differently, from my point of view it is better to use variant_group and the type definition and its variants and use cargo_subtype_text on the livery, because I can repaint the vehicle at any time and I don't have to buy a new one.
Is there any information somewhere on what cargo_subtype_text can be used for after 1.13, so that it's use is not deprecated?