News Gallery of add-ons in development

Here is an update of the soon-to-be-released version 1.4.0 called "RECONNECTION" of OMX, the fork of OMP! Install and major changes are shown in this twitch:

I still need to fix some major bugs before releasing an 1.4.1 version (which will still be an Alpha release). Nevertheless, if you are curious about what has changed in OMX since OMP, I updated the Manual with tracked revisions. You can have a look at it here attached.

Addon's thread here.
 

Attachments

Piorun, this is looking really great! This monster (meant in the nicest way possible) will be a solid addition to the Orbiter universe. Please post updates as you are able.
 
Piorun, this is looking really great! This monster (meant in the nicest way possible) will be a solid addition to the Orbiter universe. Please post updates as you are able.
Hi, thanks - if I remember correctly, I began this project in February. As the summer is closer, I should be less busy with work — this should translate into more time for ventures such as this.

The boosters (or ”the first stage” — according to Soviet terminology) are mainly done. I need to finish some details regarding the (never flown) RD-270 engines; there are almost no reference images of them. The first stage (or ”the second stage” — according to Soviet terminology) is generally almost finished too — the last thing to add is the piping between the stage and the boosters. The boosters had just below their conical sections additional fuel and oxidizer tanks that were intended to supply the core stage. This solution (a clever patent by Chelomey) ensured better utilization from the launch mass, as the first stage was still filled to capacity when the booster was separated.

The next stage was intended to use the RD-254 engines. From what I know, the RD-254 was intended to be a ”high-altitude version” of the well-known RD-253 from the Proton (with which the UR-700 was to share some technical solutions). From what I can see, the RD-254 had a larger nozzle, attached to a larger diameter tank (2.0 m) compared to the Proton (1.6 m). However, most of the data regarding this engine remains unclear, so I will have to rely on the Proton engine and my own guesses in terms of its appearance. The most work will be with the LK-700, I will have to learn a few more things, but I think it is manageable.

I will, of course, develop this beast — maybe I will toss up something new later in the week.
 
Yeah I remember we had quite a lot of fun 'reconstructing' that thing in BASPM. It is like a 'Cathedral of Boosters'.
 
Yeah I remember we had quite a lot of fun 'reconstructing' that thing in BASPM. It is like a 'Cathedral of Boosters'.
Then, the even bigger UR-900 might be referred to as an "Archcathedral". Once the UR-700 is finished, we may consider its conversion to the UR-900 with the MK-700 spacecraft, however data on this rocket is quite limited.

ur900.jpg
(Image by Mark Wade)
 
Looks like an 'asparagus booster' straight out from KSP :p
Here’s another Kerbal-like design, the third musketeer (following the N1 and UR-700): Yangel’s R-56:

Zrzut ekranu 2025-06-7 o 16.38.20.png

Zrzut ekranu 2025-06-7 o 16.39.17.png

This rocket here is in a configuration known as „Polyblock B” (as the R-56 was not a single uniform design but rather a set of concepts differing in their technological approach — which were known as „Monoblock”, „Polyblock A”, and earlier: „Small Polyblock” and „Big Polyblock”). There was a proposal to conduct missions to the Moon using the R-56, but it required at least two separate consecutive launches (due to the fact, that a single R-56’s payload mass turned out to be insufficient). However, this method required prior mastery of orbital rendezvous and docking techniques. The USSR hadn’t developed its own exact counterpart of Project Gemini during the Moon race, therefore only Korolev’s and Cholmey’s designs remained it the game. This did not constitute a defect in the R-56 per se, but it proved to be a cause that effectively prevented the Soviets from surpassing the Americans with their Saturn V. They of course became the world’s experts in this matter in a not so distant future (Soyuz missions to the Salyut and Almaz stations) but by the time the Moon race had been definitely finished.

This reconstruction is largely based on Nick Steven’s work, which is available here:

https://graphicsnickstevens.substack.com/p/on-the-n1-competitors?utm_source=publication-search

This is a cargo version but I’ve seen somewhere else a sketch displaying a human-rated version (with a Zond spacecraft(?) on the top). If my memory serves me right, the Polyblock B was to be equipped with Glushko's RD-253 engines — the same model as initially in the Proton (the nozzles are simplified placeholders — I will replace them with a dedicated mesh). I’ve managed to put this craft into Orbiter but the rocket behaves oddly — I took technical parameters from Astronautix, but in this case they don’t match realistic values, and it’s apparent even for a person (like me) who is not a rocket engineer:

http://www.astronautix.com/r/r-56polyblock.html
 
I still need to fix some major bugs before releasing an 1.4.1 version (which will still be an Alpha release).

On the way to a multi-user real-time persistent universe: News!

Still need at least 2 more versions before releasing an update in the OHM page. The yesterday OMX RECONNECTION release 1.5 is a major refactoring of the boot & connection sequence. It is now clear that the disconnections must become part of the gameplay as, nowadays, UDP and TCP connections cannot last for days. I am now focusing on monitoring and re-establishing the connections whenever needed.

OMX_Client.jpg
The interface and logs were clarified and the UDP port (unless "custom" is requested) is forced to be a static port, allowing a smooth transfer by NAT. The transfer of a vessel from a Client to another, with its propulsion status still needs some fixes but, in case of crash, the next reconnection takes over the last status and the flight can keep going. This paves the way to multiple-day flights (I just made a 5-day flight at 1-G from Earth to Mars in order to list a few remaining bugs... now orbiting gently around Mars).

I am not re-installing a 24/7 server for the moment, but here is the installation package anyway... for curious, advanced users only ;) At least, there is the User manual in it, to see what has changed since OMP 0.8.

(temporary link) OMX + Nex'Orbiter gameplay

for devs: OMX only, official Git to v.1.5.0

Thank you for your patience.
 
Golden Gate Bridge, Something for another add on. I need some help placing her in the correct location
I have her at:
gate:VesselBuilder1\goldengate
STATUS Landed Earth
POS -122.4738 37.8185
HEADING 137.60
ALT 1.997
AROT -141.906 -19.003 -153.340
AFCMODE 7
NAVFREQ 0 0
END
She is a Vessel builder vessel. I suppose she can be a base. But as a vessel I can move her in VB
 

Attachments

  • GGATE1.zip
    GGATE1.zip
    1.7 MB · Views: 0
  • goldengatebridge1a.jpg
    goldengatebridge1a.jpg
    48.1 KB · Views: 17
Golden Gate Bridge, Something for another add on. I need some help placing her in the correct location
Hi Gattispilot

So here's my technique for placing a vesselbuilder object: 🥵

1) Create a scn with the orbiter default deltaglider with the same position as your bridge.

2) Run Orbiter with this scn and slowly move the DG in the direction you want to place the bridge.
Wait until the glider is no more moving.

3) Quit Orbiter and copy the DG's position from the (Current state).scene. (you must have "STATUS Landed Earth" not "orbiting")

4) Paste this position to the bridge (which will therefore be moved) into your scn, same for the DG.
(The position won't be perfect yet.)

Restart orbiter with your scene with the modified positions.

Repeat this manipulation until the DG's position matches the correct placement for the bridge.

Sometimes you have to do this manipulation several times, moving the DG little by little, but you eventually find the right position.

This is the method I used to place my ELA4 Mobile Tower in the right place

ela4tower.jpg
 
Hi, I've just bought the Boeing-Stearman Model 75 Biplane by Ryan King Art:
Also, here's the playlist on youtube of its making:
Sadly, I'm not familiar with texture baking, so I used just pure color materials:

1.png2.png3.png

I think it must look much better with original textures (the textures and UV maps exist). So, maybe someone knows how to bake textures (materials, nodes, etc) in Blender and would like to do this work for the plane (I'll provide the materials)? Some difficult is that some meshgroups have several UV maps (for example, inscriptions on the fuselage).

Maybe @Thunder Chicken is interested in programming this plane on Lua?

The mesh file is pretty big ~68.6 MB (but the meshgroups that contain the most of vertices could be simplified a lot).
 
Back
Top