Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[FL2070]

You've probably seen it in the fixes thread already, but the F-72's contra-props rotate in the wrong directions. The simple fix, is, of course, to just invert the which one of the heirMesh().chunkAngles(...) calls gets the negative sign and which one doesn't in the moveFan() method.

Anyway, the fix is found in my UP fixes thread for anyone who wants it early.

[SAS~Storebror]

Yes I've seen that.
And I admit that this probably goes amiss easily, but...

Just FYI, here's a preliminary list of fixes in HF 24 - it's all WIP still, not far from release though.

Code: [Select]

* F-72A prop rotation direction fixed
* Bf-109W-2 empty MW-50 tank fixed
* Vildebeest III prop rotation direction fixed
* Vildebeest Seaplane water hooks fixed
* Vildebeest Series CoG fixed
* Ki-49-II Icon Tag mismatch fixed (Ki-21 --> Ki-49)
* Hawker Fury (Hispano Suiza Model) wing squares fixed
* Dewoitine D.500 series speed and turn rate toned down to RL values, wing squares fixed
* Various smaller Weapon Loadout Declaration glitches fixed (50 Aircraft in total)
* Fw 190D-13 Sea Wulf Wing Root Cannon Hooks fixed
* Aichi D1A main gear clips fixed. NOTE: The hooks on this aircraft are _ALL OVER THE PLACE_. The mod author needs to do a complete overhaul of the 3D of this aircraft!
* B-36 flaps lift and brake power toned down
* Homing X-4 and X-7 series human player controlled missile turn rate reduced by factor 10
* X-4 and X-7 series AI missile turn rate reduced by factor 4
* J7W series crappy Vasya Flight Model fixed (man... what a mess!!!)
* P26 Flaps removed from flight model
* Cockpit vs. Plane Airframe visibility issue mitigation implemented
* Ca-133, 133T & 148 inverted aileron animation fixed
* Farman NC 223 cockpit normals blind spot fixed (partly that is... the cockpit is stand-in and doesn't properly match the plane 3D)
* Arrestor hook spark effects file issue fixed (thanks to FL2070)
* Ki-32 3D updated to new version from 101tfs
* Fw 189 flaps attached to the wings correctly
* Bf-110F-2 WfrGr 21 hooks fixed (thanks to FL2070)
* Me-262A&C, Ta-183, Ta-183L and P.1101 beacon navigation fixed (thanks to FL2070)

Mike

[ssn637]

Looking forward to what just might be the final installment of the legendary UltraPack. 

Thanks so much for all you've done to make IL-2 Sturmovik 1946 so enjoyable!

Cheers

[FL2070]

Rocket alignment on the right wing of the A-26B with the 14 HVAR loadout is kinda screwy:

[P51vsFw190]

So Mike,

Does this change mean that it’s the end of my STOL Peacemaker antics?



If so, that is disappointing yet completely understandable.

Although I thought I heard that the B-36s exaggerated landing performance was due to having to operate from the standard size airfields in the game? Not completely sure if that is true or if I just willed that thought into existence.

Either way, it seems like I’ll be needing to find another STOL capable bomber with which to do highly improbable clown stuff in.


James/PvF

[SAS~Storebror]

Absolutely, old chap! Indeed, the STOL Peacemaker is no longer part of the squadron. And quite right, the aeroplane's takeoff and landing could use a spot of tweaking—otherwise, it wouldn't stand a chance at any airstrip, save perhaps for the one on the test flight maps.

Originally, the B-36 was chummy with BAT, SAS Modact, and UP3, sharing the same source and flight model. However, it appears BAT was a bit of a sticky wicket with some peculiar EngineMod issues, causing the AI pilots a bit of a bother when trying to stop, hence the rather overzealous landing performance that was introduced.

On the flip side, UP doesn't suffer from such a predicament. The AI manages to land the aeroplane without a hitch, so there's no need to endow the Peacemaker with a braking performance that would turn the arrestor cables green with envy.


Mike

[Dimlee]

As I remember, there was a "STOL" heavy bomber in the stock game since the early years: TB-3. I didn't fly her for years, so it would be interesting to try again.

[SAS~Storebror]

That one's STOL still.
Virtually impossible to get any RL performance data on it, so any FM edit at this point in time would be guesswork.


Mike

[FL2070]

Today, PvF had the fateful idea to change his loadout in an AU-1 to a 3x1000lbs bombs loadout available at the capturable island airfield in the China-55 mission on the server.

What were the consequences of this decision?

Why, of course, he was instantly teleported to map sector ZC-86.

His log around the time of the loadout change looks like this:

Code: [Select]

[2024-06-09 13:30:24.005 UTC -4] dT:   32 -== Loadout changes with HB specific RRR settings! ==-
[2024-06-09 13:30:24.006 UTC -4] dT:    0 ZutiSupportMethods_Air: sending loadout change to >3x1000lbs+10xHVAR-AT< command for aircraft >PvF_0< to mirrors!
[2024-06-09 13:30:34.039 UTC -4] dT:  335 Changing loadout to: 3x1000lbs+10xHVAR-AT
[2024-06-09 13:30:34.041 UTC -4] dT:    0 Loadout changed!
[2024-06-09 13:30:34.042 UTC -4] dT:    0 Loadout changed!
[2024-06-09 13:30:34.042 UTC -4] dT:    0 com.maddox.il2.engine.ActorException: Interpolators changed in 'tick'
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.il2.engine.Interpolators.tick(Interpolators.java:180)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.il2.engine.Actor.interpolateTick(Actor.java:275)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.il2.engine.InterpolateAdapter.msgTimeOut(InterpolateAdapter.java:151)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.rts.MsgTimeOut.invokeListener(MsgTimeOut.java:73)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.rts.Message._send(Message.java:1217)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.rts.Message.sendToObject(Message.java:1191)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.rts.Message.sendTo(Message.java:1134)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.rts.Message.trySend(Message.java:1115)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.rts.Time.loopMessages(Time.java:305)
[2024-06-09 13:30:34.042 UTC -4] dT:    0 at com.maddox.rts.RTSConf.loopMsgs(RTSConf.java:18)
[2024-06-09 13:30:34.043 UTC -4] dT:    0 at com.maddox.il2.game.MainWin3D.loopApp(MainWin3D.java:137)
[2024-06-09 13:30:34.043 UTC -4] dT:    0 at com.maddox.il2.game.Main.exec(Main.java:380)
[2024-06-09 13:30:34.043 UTC -4] dT:    0 at com.maddox.il2.game.GameWin3D.main(GameWin3D.java:235)

It might not be (it probably won't be) enough to chase it down, but there's always hope.

[SAS~Storebror]

Thanks for the log.
I think I see what happened - interesting part is that this never happened before, which suggests that there are certain things that need to come together for this to happen.
General speaking, many moving actors implement an "Interpolator" object to animate their movement.
You find this in every cockpit, but also on bombs and, more particularly (see below) on bombs with Chutes.

My suspicion is that this error got triggered because PvF's previous loadout contained flares with chutes. This might be something we didn't encounter before (maybe I'm wrong here), or at least it's a hint for further investigation, because other than that, we've been changing loadouts many times without seeing this issue.
Back to the suspicion: The game holds an ArrayList of all existing classes implementing "Interpolator" objects and with every tick, it traverses through these objects and calls their "Interpolator" objects "tick" method.
ArrayLists can be looped through in many ways, and in this particular case, the game is using a simple "for" loop to go through index 0 all the way to the highest list index of all "Interpolator" objects.
In such case, it's essential that the ArrayList you're looping through doesn't get altered while you loop through it.
And in this case, it did.

That much, that good. Now to the bad news: The list could have been changed literally anywhere else in code.
The hint from this log is that it happened when the game unloaded the old loadout. But from sourcecodes perspective, I can't spot where this should have happened.
So we need more information here.
Best would be if there was a reproducible way to trigger this issue.
Suspicion: Pick a loadout with Flares on Chutes, and RRR to another loadout (can be anything). Check if the error occurs and report back.
I'm afraid I don't have time right now to do it myself, so I have to rely on a certain level of assistance to find a reproducible trigger for this issue.

Additional info for reference:
Plane used: AU-1
Loadout pre-RRR: "154gal Tank, 1x 2000lb, 1x 1000lb, 5x Flares, 5x HVAR-AT" (called "154galTank+1x2000lbs+1x1000lbs+5xFlares+5xHVAR-AT" in loadout declaration)
Loadout post-RRR: "3x 1000lb Bombs, 10x HVAR-AT" (called "3x1000lbs+10xHVAR-AT" in loadout declaration)
Suspicious ordnance: Bomb(Gun)Mk24Flare because of its chute


Mike

[KingTiger503]

I just Confirm the Locomotive Train is Missing..

Code: [Select]

[2024-06-09 21:51:18.913 UTC +8] dT:    1 java.lang.NullPointerException
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.objects.trains.LocomotiveVerm.place(LocomotiveVerm.java:148)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.objects.trains.Train.placeTrain(Train.java:190)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.objects.trains.Train.moveTrain(Train.java:309)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.objects.trains.Train.access$100(Train.java:23)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.objects.trains.Train$Move.tick(Train.java:40)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.engine.Interpolators.tick(Interpolators.java:177)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.engine.Actor.interpolateTick(Actor.java:275)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.engine.InterpolateAdapter.msgTimeOut(InterpolateAdapter.java:151)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.rts.MsgTimeOut.invokeListener(MsgTimeOut.java:73)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.rts.Message._send(Message.java:1217)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.rts.Message.sendToObject(Message.java:1191)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.rts.Message.sendTo(Message.java:1134)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.rts.Message.trySend(Message.java:1115)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.rts.Time.loopMessages(Time.java:305)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.rts.RTSConf.loopMsgs(RTSConf.java:18)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.game.MainWin3D.loopApp(MainWin3D.java:137)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.game.Main.exec(Main.java:380)
[2024-06-09 21:51:18.914 UTC +8] dT:    0 at com.maddox.il2.game.GameWin3D.main(GameWin3D.java:235)
 

FL Raven and I Already found out on Dimiee Mission

Best Regards KT503

[Dimlee]

I just Confirm the Locomotive Train is Missing..


FL Raven and I Already found out on Dimiee Mission

Best Regards KT503

Hi, KT. Was it in the Pearl Harbor mission? I did put some trains on Oahu island and they worked perfectly in Multiplayer but I didn't check them in the mission on the server. I hope it doesn't cause any conflicts online. Otherwise, I can remove the trains in the next edition of this mission which is due in... 2 weeks, be sure.