Project Explorer (Babylon 5) Deep Space Vessel

Status
Not open for further replies.
I like the way you think,maybe even a RMS or something similar.Thanks

Actually, I'm thinking more along the lines of the Zero-G Cargo Pod that was used around the station, which has a strikingly familiar shape to it...

maintbot1.jpg


Babylon 5 Cargo Pod

---------- Post added at 01:27 PM ---------- Previous post was at 01:11 PM ----------

Or, perhaps a Maint-Fury:

maintenance_fury.jpg


---------- Post added at 01:38 PM ---------- Previous post was at 01:27 PM ----------

In an earlier post in this thread, I mentioned I had many ideas for the Explorer class. Something along these lines was one of them. Now I'm torn between releasing the Cortez as-is, minus UCGO, or holding off and adding UCGO support in addition to creating one of these two vessels to release with it. Decisions, decisions.... :hmm:
 
Last edited:

In an earlier post in this thread, I mentioned I had many ideas for the Explorer class. Something along these lines was one of them. Now I'm torn between releasing the Cortez as-is, minus UCGO, or holding off and adding UCGO support in addition to creating one of these two vessels to release with it. Decisions, decisions.... :hmm:

I think UCGO isn't really suitable for such a vessel, you could add hundreds of vessels with all 40 UCGO boxes possible for one as attachments to the Cortez and still have room.

I think by directly adding UCGO support there, you give yourself more limitations as additional freedoms.
 
I think UCGO isn't really suitable for such a vessel, you could add hundreds of vessels with all 40 UCGO boxes possible for one as attachments to the Cortez and still have room.

I think by directly adding UCGO support there, you give yourself more limitations as additional freedoms.

I've been back and forth with that same opinion. Perhaps leave UCGO support off the Cortez itself, but when I create the atmo shuttles, add it to them and just have the user add the cargo to the shuttles as needed to take down to the surface, etc.

I don't see ever using UCGO in the context of replenishing the Cortez, so really it would only serve the cargo role, and as you mentioned, the 40-cargo limit per vessel, along with the 1.3 m^3 size limitation and the sheer size of the Cortez, hardly make UCGO practical I think.

Interceptor's interest in having UCGO support got me thinking about it again. But the limitations with the other addons, coupled with the time it would take me to overcome those limitations to make it work, are making it harder for me to justify adding UCGO support at this time.
 
Interceptor's interest in having UCGO support got me thinking about it again. But the limitations with the other addons, coupled with the time it would take me to overcome those limitations to make it work, are making it harder for me to justify adding UCGO support at this time.

I think UCGO make some sense if you could use for maintaining the vehicles in the hangar with it, but then there is little support by UCGO for it yet, so you need to do a lot of work yourself there.

For many things, you will rather have propellant resources representing bulk storage, not individual cargo boxes.

I would rather see the repair fury in Orbiter with a few temporary jump gates to be installed near the Explorer ;), that is the main role of this vehicle, find new star systems and permit construction crews to follow and install permanent jump gates and outposts there. These jump gates are really small and flimsy from the few descriptions of them, they are just scaled for letting everything arrive that is too small or too civilian to have its own jump drive. From descriptions, the bulk of the Explorer spacecraft mass is parts for these jump gates.

There could be quite many exploration missions possible with such a Explorer then, that fit well into the sandbox playing scheme of Orbiter... like starting with mapping planets and then install a jump gate.

BTW: This one would be more suitable for getting equipped with UCGO:

eascout_lg1.jpg


An Earth Alliance Scout vehicle, a small, usually single pilot spacecraft that lands on newly discovered planets to explore them, about the size of a Shuttle craft. The support structures below the spacecraft cry for UCGO boxes.
 
Last edited:
I agree, those racks look like they were made for UCGO from the start. I may add that to the list of ships I'm currently considering doing, probably after the Kestrel though.

In the meantime, I decided to work on a little something extra. A new skin for the XR2 (my first for this craft, second overall).
 
Update - began working on the manual last night. About 15% complete at this point. Should be able to get some serious work accomplished this weekend.
 
Work on the manual continues. Currently estimated at about 85% complete. I still need to include a recommended procedure for 'landing' in the bays. I may also include a basic instruction on how to add additional virtual docking ports in the config files of vessels that do not have nosecone-docking capability so they may utilize the flight deck for landing.
 
Sorry for the delay in updates. Some pretty big things happened with my daughter from a medical perspective 2 weekends ago (all good things though), so I've been very busy @home lately.

I plan on completing the documentation sometime this week. Before I wrap things up completely and call the current version 'done,' are there any suggestions from those of you who have flown the Cortez, things that could be tweaked a little before release?

Thanks,
n122vu
 
Thanks. Aside from a small cold, she's doing great. Long story short, after 4 years of breathing thru a trach tube, she no longer has one. Life has become 1000 times simpler for her and for us.

So, no suggestions....comments....criticism even? Not one single 'those green lights in the hangar look dumb' comments? Come on, give it to me straight, I can handle it :lol:
 
Latest Update

There has been one thing that has been nagging me about the ship, and it's this: What good is having all these places for ships to land, and having UMMU capability, and not having the ability to transfer directly to other UMMU-capable vessels? So, as much as I hate to do delay release of the Cortez any more than it already has been, I'm going to add UMMU Airlocks to all the landing points (docking ports). This will give UMMU-capable vessels who land in the bays the ability to transfer crew to and from the Cortez, and vice-versa.

First two docks are functioning, although, since the UMMU airlock code numbers the airlocks beginning at 0, I am going to place airlock 0 as a virtual airlock near the bridge, and keep the numbering sequence on the airlocks consistent with that of the docking ports as listed when hitting CTRL-I in the sim. This should avoid any confusion or having to remember that the airlock number is one less than the dock you are 'landed' at.
 
All docks/airlocks are now complete and functioning for EVA purposes. Now I just need to implement transfers to complete the puzzle.

Can anyone point me to a good example for this? I can't seem to find how to do it in the UMMU SDK. I tried using an XR2 docked with the airlock doors open, and the active Cortez airlock open as well, but the individual still does an EVA instead of a transfer.

Also, I'm able to transfer from the docked XR2 to the Cortez, but the transferred member doesn't show up in the Cortez's crew list. Assuming because there is no code yet in the Cortez's side to handle the transfer. Captain Maynard was apparently transported to the realm of The Probe. Any pointers on this as well would be appreciated.
 
I'm probably going to upload the Cortez as-is to O-H later today. I will have very little time if any in the near future to work on it. I hate to let it sit when I could upload the source code and someone else could continue the work and add some new features. So I will upload the project, source code and all, sometime later today.

Thanks,
n122vu

---------- Post added at 07:34 PM ---------- Previous post was at 08:48 AM ----------

Hate planning to do things and it not working out. Maybe Tuesday. :(
 
Still noticing a strange issue with UMMU transfers. I have an XR2 docked to Dock 1 in the main hangar. I am able to successfully transfer crew from the XR2 to the Cortez, but when I press EVA on the Cortez, the crew member actually EVAs and is between the two ships. If I then press E, the crew member re-enters, but is now present in both ships. Anyone have any ideas?
 
Thanks, but I already have that code in place. All of the 'docks' in each hangar are now selectable and usable for EVA and transfer. But when there is a ship docked at the active dock, rather than transfer from the Cortez to the docked ship, the UMMU EVAs between the airlocks.

---------- Post added at 09:29 AM ---------- Previous post was at 07:11 AM ----------

Looking at the ShuttlePB example in the UMMU SDK, it appears I'm missing some functions in the post step. Easy fix.

Really wish I didn't have to work today. I'd rather be at home fixing this lol.

---------- Post added at 10:16 PM ---------- Previous post was at 09:29 AM ----------

Well, I was wrong about the code. Everything is there as it should be. I'm stumped. I can successfully transfer from a docked ship to the Cortez. The crew member is no longer listed on the XR2, and shows up in the next available slot on the Cortez. However, when I try to transfer from the Cortez to the XR2, it simply does an EVA, even though the ship is docked and the airlocks are both open.

---------- Post added 10-13-11 at 05:31 AM ---------- Previous post was 10-12-11 at 10:16 PM ----------

It just hit me what the problem is. And the kicker is, it's of my doing. Stay tuned for explanation.

---------- Post added at 05:36 AM ---------- Previous post was at 05:31 AM ----------

Latest Update

First two docks are functioning, although, since the UMMU airlock code numbers the airlocks beginning at 0, I am going to place airlock 0 as a virtual airlock near the bridge, and keep the numbering sequence on the airlocks consistent with that of the docking ports as listed when hitting CTRL-I in the sim. This should avoid any confusion or having to remember that the airlock number is one less than the dock you are 'landed' at.

This is where I went wrong. I confused the airlock with the actual dock being selected, so, Dock 1's airlock is in front of the bridge, but the dock itself is still in the hangar bay. So, when I am selecting active dock 1, I'm actually selecting dock 2 in the bay, but I've placed the airlock for this dock in dock 1's position. Thus the EVA and no transfer, because it's not the dock that the XR2 is docked to.
 
I confused the airlock with the actual dock being selected, so, Dock 1's airlock is in front of the bridge, but the dock itself is still in the hangar bay. So, when I am selecting active dock 1, I'm actually selecting dock 2 in the bay, but I've placed the airlock for this dock in dock 1's position. Thus the EVA and no transfer, because it's not the dock that the XR2 is docked to.

Confirmed that this was the source of the problem. Code is corrected and everything seems to be working. Just need to make the necessary notes in the documentation about the docks, then I believe everything is ready for upload.

:hailprobe:



**EDIT** The :hmm: earlier was something I was thinking about doing and I just implemented. I created another variable to hold the active dock value that will be displayed in the HUD. Each time the actual active dock changes, the HUD will display a value that is 1 more than the actual value in the array. This way, the active dock number seen in the HUD corresponds to the dock number seen in both the vessel information screen (CTRL-I) and in the dock layout in the documentation. So I don't need to change the documentation at all. The difference in the numbers is completely hidden.

---------- Post added at 09:38 PM ---------- Previous post was at 11:03 AM ----------

Putting the finishing touches on the documentation. I think I'll omit the whole 'standard docking procedures' idea for now, and let users determine their most desired methods of 'landing.'

Should have everything ready for upload to O-H sometime this weekend. Key word here being 'should.'
 
Last edited:
Gathering the package now. Should be ready to upload in a matter of minutes.

Can't believe I made it just inside the 1 year mark. First post of this thread was on 10/29/2010. What a year it's been!

**EDIT**
Going to upload the package to my Skydrive first and test it on another machine with a fresh install of Orbiter, OrbiterSound, and UMMU before I upload to O-H.

---------- Post added 10-15-11 at 01:31 PM ---------- Previous post was 10-14-11 at 08:31 PM ----------

Mods - per the update I just made to the first post, please close this thread so that any further bug reports or comments can be directed to the addon thread.

Thanks,
n122vu
 
Last edited:
Status
Not open for further replies.
Back
Top