Junkers Ju-52/3m

[Ivan]

Hello Aleatorylamp,

Just after the *** Start of Main Aircraft Code *** there is a large
chunk of code over 1000 lines long, that just does Vectorjumps,
Jumps and Calls, before actually drawing anything, and to try to get
a general picture of what is going on is of course impossible without
detailed analysis.

I can save you the trouble of tracing it.
This is what I call "Group Glue".
Hopefully my terminology is understandable.....
If you look at your entire AF99 AFA file, it shows a bunch of stuff. I call that the "Assembly".
Sometimes I create an Assembly with only a few pieces of the aeroplane as not to get distracted by the X-ray effect of seeing all the lines in front of and behind what I am working on.

In your Assembly, there are multiple "Groups": Nose, Body Main, Tail, Inner Wing, Canopy, Center Gear, Tail Gear, etc.
Note that NOWHERE do you specify how those Groups fit together.
There is a single assembly (note no caps) sequence for the Groups that are included in your AF99 Assembly and you can't change it much as you might like to.
That is why sometimes Groups such as Left Tail or Right Nose are not as useful as they might appear.
That "1000 lines of VectorJumps" is a determination of what order to display the groups based on the location of your Point of View (POV).
It isn't real smart.
It makes all determinations as to what quadrant the POV is located in and displays the Groups in a (hopefully) appropriate sequence.
That is why when you are inside the Cockpit, you see the Tail Group showing up through the Aft Cabin Wall.

The code has determined that your POV is in the Aft hemisphere so the display sequence is Nose, Body Main, Tail.
The last one displayed is in the foreground.
Now if your Cockpit location were AHEAD of the CoG, then you would be seeing the sequence Tail, Body Main, Nose.
....and you would be seeing the Propeller visible through your Instrument Panel.

Proper display SHOULD be Nose, Tail, Body Main if you are inside the Cockpit but since the Viewing Plane (VectorJump) happens to be at the CoG and all determinations as to quadrant of the POV before anything is displayed, that will never happen.

To do it properly requires more than just one VectorJump for each place where there is more than two Groups in series and also a means of specifying the location of viewing planes between Groups.

Many years back, I worked on re programming this sequence (I was working on my F6F-3 Hellcat as a timeframe reference), but ran into a few issues which I never quite got sorted out.
I also found that the amount of work needed to do this was not justified by the improvement in the visual model.
I usually could not tell the difference and I am the fellow programming it!
My current approach to Virtual Cockpits is much easier and cleaner from a programming standpoint and has a lot less potential for error.

When you think that the way in which this kind of automatically
generated "Z" Buffer actually works was created by someone,
even if it is not as perfect as the modern "Z" Buffers contained in
later simulators, it is still quite an amazing feat. Those guys really had
an extremely high 3D visualization capacity!

While I agree that the programmers of AF99 probably had a pretty good ability to visualize, their design skills were VERY poor in my opinion. They pushed a rather inadequate product out the door probably on a tight schedule and we have had to live with it ever since.
It was pretty much the only game in town for a while and it beats the heck out of trying to program in SCASM alone.
Besides the bugs that are still in the program and the fact that the initial release really did not work, the resource limits are not optimal. When was the last time you ran out of Structures? We keep running out of Components all the time.

The natural form of a 3D model should look like a Tree.
The form of a AF99 Assembly is more like a collection of Vines with each vine having just one branch at junction with no ability for branches to have an additional junction or at least not one that is controlled.

More time should have been spent in designing a proper Tree representation for the Assembly listing.
Sometimes things can get a little complicated.

<Bleep> Censored. Email me if you want more background to this discussion.

In their defence though, when you start adding a lot of flexibility and neat nifty features, you start confusing your audience because some will not understand the benefits. FWIW we are still using this package almost 20 years after it first came out.

- Ivan.

[aleatorylamp]

Hello Ivan,
Very well put together, your points, I must say, and very clarifying, on what the programmes do and how they do it, as well as what they could have been programmed to do better.

So, very illustrating is that the VectorJumps are exactly the view-point with respect to up/down left/right and fore/aft viewing planes, having the CoG as reference point in general, but with specific Glue providing more exact manual adjustments for certain elements.

Obviously, the tandem AF99 + AA, when combined with SCASM, allows much greater achievements than what can be done without, and if it is over 20 years ago that the programmes were released, as you say, it speaks in their favour, and their limitations can be, shall we say, lived with!

Adding decently shaped pilot and co-pilot heads and torsos to the Ju-52´s after making the cockpit transparent, added about 16% parts. When the planes had a solid cockpit with window-textures, parts count was already between 147% and 149.8%, depending on the version - i.e. number of scoops and/or machine guns.

This means that the real parts count after SCASM intervention is now between 163% and 165.8% parts, not a bad improvement over the non-SCASMed version. The result at this stage, is more than I thought I could come up with. You mentioned once that 200 parts (or perhaps more) could be added, which would make the total about 175%.
Hmmm... what else can I put in? Ha ha!

Anyway, thanks again for your coaching!
Cheers,
Aleatorylamp

[aleatorylamp]

Hello Smilo,
I was playing with the idea that there may be a way to simulate how the
airplane could drop paratroopers by declaring them as bombs in the Dp file.

12 paratroopers would weigh about 300 lb each with their full equipment,
totalling 3600 lb. With a crew of 3 to 5, we would be flying quite a fully
loaded airplane ALL the time if this weight were included in the dry weight
in the .air file. This is perhaps not all that logical.

More so, we could also suppose that instead of paratroopers, we had 12
crates of logistics and weapons to deliver somewhere, after which the
plane would be empty.

So, declaring 12 x 300 lb "bombs" in the Dp files, we could have a payload
that could be a) chosen before the flight, and b) dropped when needed.

What do you think?
Cheers,
Aleatorylamp

[smilo]

it's an interesting idea, Stephan
and i don't mean to sound like i'm pooh poohing it.
my first thought was,
how do we slow the rate of decent
and broaden the trajectory?
ie, make them float.
my second thought,
how do we keep them from exploding on impact?

[aleatorylamp]

Hello Smilo,
I understand your point - we would really be dropping 12 x 300 lb bombs.

The paratrooper simulation done this way would only apply to the in-flight
weight reduction of the aircraft, ignoring the explosions on the ground
that follow. This way we get to fly it lighter and faster, also deciding
how much we want to start off with.

In FS98 the only way to simulate any kind of in-flight weight changes due
to bomb or supply-package dropping, was to define an extra tank with the
equivalent weight in fuel, to be jettisoned by means of the fuel menu.
But then, the fuel could also be used for an unrealistically long range...

An alternative to constantly having to fly a fully laden, rather sluggish
aircraft would be to have a zero weapon Dp File, and only 50% of the
payload in the .air file as dry weight, and leave it at that... or maybe
75%, but not more.

So the real question is, which method of doing this would be the most
appealing for the simmer?

Cheers,
Aleatorylamp

[smilo]

an interesting dilemma indeed.
i'll have to think about it for a bit.
sure wish i knew more about the guts of cfs

[Ivan]

Hello Aleatorylamp, Smilo,

I probably said that AF99 allows 200 Parts as well as 30 Components and 30 Structures.
I don't believe there is a hard limit to what you can add to the model via SCASM.

By the way, are you all now trying to find Japanese Kamikaze Paratroopers?
;-)

- Ivan.

[smilo]

ahhh, no, i don't think so.
i think we're trying to avoid such a thing.

[aleatorylamp]

Hello Gentlemen!
OK, well... no Kamikaze Paratroopers then. Good grief, what a thought!

But then, we don´t really want a fully laden plane either, do we?

How about a moderate 65% payload: 8 x 300 lb paratroopers = 2400 lb
instead of the max. 3900 lb in the .air file dry weight. These 2400 lb could
also represent 12 normal troops to be landed somewhere, or 24 crates
of logistics weighing 100 lb each.

That way the model would comply with its transporter function, without
being a fat goose with a full stomach.

I think I´ll proceed this way unless anyone has any objections.


Cheers,
Aleatorylamp

[Ivan]

Hello Smilo, Aleatorylamp,

Fallschirm Jaegerbomben?

You do know that the default bomb load does not have to the maximum bomb load, right?
That way, you can have a typical load of 2400 pounds and a maximum of 3900 pounds.

- Ivan.

[aleatorylamp]

Hello Ivan,
Um Gottes Willen! Also doch Fallschirmjaegerbomben?
i.e. By Jove, hadn´t Bomb-Paratroopers been discarded?

A typical load of 2400 pounds, and a maximum of 3900 pounds,
CAN of course be done, but as you know, it´s only possible as
bombs, if we DO want Fallschirmjaegerbomben after all.
...Unless of course we don´t!

The dilema is, to decide whether the unarmed Ju52 Transport
payload is going "to be, or not to be Bombs. That is the question."

It´s amazing how our friend Shakespeare indefatigably comes in handy.
It´s either black or white - no in-between possibility.

So Smilo would tend to be against, Ivan seems to tend to be in favour
and myself tend to be undecided... Oh, well...

Anyway, for the moment, here are some shots of the 725 Hp powered
g4e recovered from the Norwegian lake in excellent condition in 1986,
currently on display, very nicely restored, in a Norwegian museum.

The model has darker night-camo in khakhi green/black, and defined
as a transport/bomber with provision for 10 x 110 lb bombs. Armament
is one 13 mm dorsal MG and one 20 mm cannon mounted on top of the
cockpit, just like in the museum photos. There are no lateral firing guns
on the sides, (the aft fuselage windows are painted over), although there
was provision for them.

Updated paragraph:
I still have the yellow/green textures of the first armed "J" 10/3 transport unit
employed in the invasion of Crete, so it may be a good idea to use these textures
on the model with the 2 extra lateral firing fuselage guns, to try out this TG2 feature.
Thus, we get four Ju52/3m versions:
> 2 unarmed ones: The Spanish and the German transport/paratrooper, and
> 2 armed transport/bombers: The dark-camo one with 2 guns, and the green/yellow one with 4.

Cheers,
Aleatorylamp

[smilo]

"So Smilo would tend to be against..."
hang on there, turbo.
where did i say, i was against?
see my comment on post #106.
i thought i was being indecisive.

[Ivan]

Hello Turbo,

I am actually neither for nor against.
I just don't see another way to have an adjustable payload in CFS.....

How about a gun pointing rearwards and down that shoots out paratroopers?
If you can adjust the sound, then have them yell "Geronimo!" as each paratrooper is fired out.

;-)

- Ivan.

[aleatorylamp]

Hello Smilo, Hello Ivan,
I was expressing my impression on what you thought - I didn´t say either of you
were actually for or against the idea, but rather that you seemed to tend towards
being one way inclined or another.

So with "seem" it expresses my interpretation, not a reality, and with "tend", it
implies a preference towards one or the other position, not completely defending
a position related to the idea.

I was trying to get opinions to see what would be preferred. Reading the posts on
the subject, the "consensus", as it were, still seems to tend toward ambiguity,
as a result of which I still don´t know what to do about it.

The possibilities are what they are, and the question about the best way to go
about it still remains.

Now, the reason for the question is that I am more inclined to building than
actually flying, and tend to deal more with a) getting shapes to look as best
as possible, textures being the difficult part, and b) the technicalities inside
the engines, to get them as close to specs as I can. Feedback here always
produces great improvements, as one can see from the threads dedicated to
making a given model.

Weak points are a) aircraft flying performance - I´m not very good at .air file
aerodynamics, so I always need feedback on the models´ general behaviour,
and b) what a simmer prefers on some point or other that I am in doubt about,
and a decision has to be taken for which I don´t know enough.

Thus, I am just as willing to either drop Fallschirmjägerbomben, as not to drop
anything at all, and just put in 65% as fixed payload.
I have no preference either way.

I know that I am the builder and I can do what I want, but I don´t want to do it
that way, but at the end, I´ll probably have to, but anyway...

Cheers,
Aleatorylamp

[aleatorylamp]

Hello again, gentlemen!

I have a solution:

The Spanish CASA 352L can have 8 "Fallschirmjägerbomben" as default
and 13 as maximum, applying the suggestion in Ivan´s Post # 110.

The German g5e unarmed transport can have 65% payload in the .air file,
following Smilo´s comment in post #108.

So, we can have it both ways! How about that?

Then, for the 4-guns version, there is a documented armed g5e version
that served in the Balkans campaign for the invasion of Crete.

Here is a screenshot of each of them, now with markings on the textures
and with their transparent SCASM-installed cockpits:
> The unarmed transport 1Z+IK,
> the Spanish paratrooper/transport 36-8, and
> the "almost gunship" 3-J-10.

Cheers,
Aleatorylamp

[smilo]

no doubt about it,
i would like to see paratroopers coming out the door
and floating down to the ground.
heck, i can even envision missions
with groups of ju52s ejecting paratroopers.
BUT, since none of us know how to modify the cfs code,
the alternative is bombs dropping from the aircraft.
i guess the rest is left to imagination and so it goes.

as for your solution...i like it.
here's one more air file option for the transport.
make two air files, one empty, one loaded.
then, have two aircraft.cfg entries.
one for a loaded version and one for an empty.
you could even do it with the other versions if you wanted to.
that way, the simmer can choose which version to fly
and leave the floating paratroopers to their own imagination.

[aleatorylamp]

Hello Smilo, hello Ivan,

Smilo, thanks for the idea. It sounds very sound!
Three options for each unarmed transport in its aircraft.cfg:

1.- Version with "Fallshirmjägerbomben" - Pre-flight choice between 0 and the absolute maximum payload of 13 paratroopers, weighing 300 lb each and who would "jump out" when the simmer released a bomb. Connected to its Weapon/Bomb-containing Dp File and correspondingly named model file.

2.- Aircraft loaded with the standard full load of 12 paratroopers. Connected to its Zero-weapon Dp Files, and because these have to be named be the same as the model file, a differently named but identical model file would be included.

3.- Aircraft with no paratroopers or crates as if returning from its mission. Connected to the Zero-weapon Dp and model Files mentioned in number 2.

Then, each transport aircraft would have two explanatory Checklists, just as there are two DP files, and two model files.

Ivan: The Readme would instruct the simmer to yell "Geronimo!" every time he releases a paratrooper for Option 1, and to yell it out 12 times running in Option 2, before he can change to the empty .air file!
Alternatively, he could happily take off with an empty plane to go somewhere and load 3600lb of crates. There he would have to grunt and sigh 12 times before changing to the loaded .air file...

Great stuff!
Aleatorylamp

P.S. Would either of you be interested in a WIP version of any of the 4 versions before the uploads, or can we suppose that the previous versions attached to the posts will suffice?

[smilo]

this week will be hectic here.
(daughter is getting married)
but, if you want to send wips, please do.
no promises on testing, but, who knows,
there may be a few minutes here and there.

[aleatorylamp]

Hello, Smilo!
Well, well, well! Congratulations!
One of the important events in life! How nice.
The best of luck, and long lasting happiness to all.

OK then, not to worry about the WIPs. Maybe it
will be better to wait another week for that, as
you´ll have enough to do!
Cheers,
Aleatorylamp

[aleatorylamp]

Hello Ivan,
Although I remember you saying that even with SCASM, some display problems
can´t be solved (I suppose because of the CoG reference viewing point problem),
I thought I´d try and remedy a small issue: The transparent cockpit window component
disappears when viewed from some upper forward angles.

It is one transparent, smooth component, but I can´t place it into the Canopy High
wing group because it will bleed throught the cabin sides when viewed from below.
Thus, it is placed in Body main, after the left and right canopy-frame halves,
whose components are defined as "Collection", so as to be visible from inside as well.
The latter don´t cause any bleeds anywhere, and don´t disappear either.

So, I thought I was going to be smart, and would call some extra window-canopy halves,
even at the price of having some canopy-window duplication that would make the windows
a little more opaque sometimes, and made two extra canopy-window component halves.

I added their code to the end of the SCASM listing, with conveniently modified labels,
their conditions being specified correctly and their transparency turning on and off
correctly.

Then I inserted some Call32 instructions for the new left and right canopy-window halves,
just before or after the lines that the left and right canopy frame-halves were being
called from, but the results were disappointing.

Each new canopy-window half either disappeared too, or bled through the nose component,
which is surprising, because the canopy-frame halves, that are called from the same place,
don´t. Inverting the order in which the window-halves or the frame-halves were being
called from, made no difference.

Well, I suppose it´s too much to expect here, ...unless of course it isn´t...
I wonder if you have any views on the subject.
Cheers,
Aleatorylamp

[aleatorylamp]

Hello Smilo, Ivan,
At the end, I´ve attached the armed Ju-52 transport/bomber version,
to this post, in case you have the gumption or time to have a look at
it sooner than expected.

I am well aware that you both have a lot to do and may not have the
time for at least a couple of days or perhaps a week or more.

No hurry, and thanks in advance for any obervations, suggestions or
corrections!

Source files are included, but please take into account that the AF99
model is incomplete, also having incomplete elements, because the
finishing stage of the model via SCASM entails a virtual cockpit, a crew
of 2 in the transparent external-view cockpit, as well as completion of
the incomplete elements.

Second thoughts on the canopy display issue in my previous post:

It could also well be normal for transparent surfaces to disappear
depending on the lighting conditions. Normal textures have differnt
colour intensities depending on how the light shines on the surface,
but transparencies probably don´t reflect any light when they are
in a shadow, and become totally transparent.

Cheers,
Aleatorylamp

[Ivan]

Hello Smilo,

Congratulations on your Daughter's upcoming Wedding.


Hello Aleatorlamp,

I can't visualize what you are describing and also have a few things to take care of this evening.
Could it be that the Parts of your Window Component are non-planar?
Non-planar Parts disappear when seen at shallow angles.

I actually try to do as little as possible in SCASM code changes from the disassembled AF99 model and try to make those changes very modular so that they are easily found and repeated on the next AF99 build if necessary.
The chances of messing something up in SCASM is quite high for me which is why I try to work there as little as possible.

My apologies for not being more help, but with 3D design, other than general techniques, just about everything depends on being able to see what is wrong, and I don't at the moment.

- Ivan.

[aleatorylamp]

Hello Ivan,
Re. the disappearing windows: I think I jumped the gun here. Sorry!
I thought it was something to correct, but it appears to be normal.
I had noticed it on other models, doing a wing-tip height visual sweep from one side to the other, passing in front of the aircraft. I´ve just checked, and it happens on all aircraft, so there´s nothing to correct! It may even be something that my graphic card does, and does not happen on other computers.

Re: the amount of SCASM alterations in the Ju-52:
I´m afraid there was no other alternative for the numerous changes.
The parts count was already quite high (146.7 to 149.8, depending on the model), and to put in about 16.5% extra parts (131 parts) for cabin crew, floors and aft wall, I had to make space by simplifying other elements, which then had to be completed. At the end the total parts count is about 164%.

As you have explained on prior occasions, you would have done it by adding the code to the end and calling it from convenient places, without altering existing code, but that was a bit too complicated for me.

Once I had identified where the parts were, I found it easier to follow, to use the existing routines and substitute the code within, than to add others. This of course involved quite a few Call instructions that had to be changed to Call32.

I expect that the other system of bypassing existing code and adding new code to the end would also need quite a few Call32 instructions.

Anyway, the good part of all this is that the models all work and look clean.

Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

Glad you figured out the window issue.
Obviously your method of SCASM modifications works for you.
I still prefer my method because it seems clearer to me to have all the new code in once place.


Hello Smilo,

The Floating Fallschirmjaegerbomben might not actually require modification to CFS code.....
I am pretty sure that it is within the capabilities of the simulator if you do things correctly!


Thinking about it????


Good!


Now think about this:
Many CFS models especially stock, have breaking parts.
When your wing breaks off, you get the aeroplane spiraling out of control AND you get a broken off wing section flopping around and falling.
Now what happens if the original aeroplane spawns off a broken piece that looks like a paratrooper and also does not lose control?

Ain't that a cool idea?

- Ivan.

[aleatorylamp]

Hello Ivan,
To have all the new code in one place is a very good argument, and very practical.
Maybe I´ll adopt that method too, as once the old code is identified and conveniently
marked, inserting a call to the new code there, or where the call comes from, should
be about as easy as actually substituting code. I´ll see.

I didn´t know about broken wings spawning off airplanes being shot at! So, if one were
to climb into a stock Spitfire or Messerschmidt, and do a quick combat against 12 ace
opponents, to get myself shot down, I could have a look at what happens.

Well... then the thing to do, if the following information could be obtained, would be
a) to see what and where the flag is, that triggers the display of the broken-off wing,
b) how to trigger it, and
c) to see if more that one can be triggered.

Where the CFS1 bitmap is, and changing it into a Fallschirmjäger one, would probably be a
comparatively easy part. There are a few different wing texture bitmaps in the CFS1 texture folder. One would only have to identify which one to call and how to call it.

Cheers,
Aleatorylamp