Project Explorer (Babylon 5) Deep Space Vessel

Status
Not open for further replies.
I think the problem is rather in your mix of if and switch statements, that doesn't work, but I have currently not the time to de-spagetti it. Sorry, you would have to wait a moment.
 
**EDIT** Fixed the bug with time accel and hud keys not working.

In the clbkConsumeBufferedKey code above, replaced the return 0; toward the end with return 1; then placed return 0; between the last two braces. (Thanks Urwumpe. You were correct in pointing me toward a wrong return value).

Next task is going to be correcting the location for the EVA airlock. Anyone have suggestions regarding location? Was thinking about locating in in one of the smaller hangar bays in the front of the ship. Will go with only one for now for the sake of saving time on completing the vessel.

---------- Post added at 03:49 PM ---------- Previous post was at 03:39 PM ----------

I think the problem is rather in your mix of if and switch statements, that doesn't work, but I have currently not the time to de-spagetti it. Sorry, you would have to wait a moment.

I agree. It definitely needs to be cleaned up, but that will remain a future goal for the time being.

The only switch statement that is mine is the one capturing K for the gravwheel animation toggle. The remaining if-statement and switch-statement mix comes from DanSteph's UMMU SDK code.
 
I agree. It definitely needs to be cleaned up, but that will remain a future goal for the time being.

The only switch statement that is mine is the one capturing K for the gravwheel animation toggle. The remaining if-statement and switch-statement mix comes from DanSteph's UMMU SDK code.

Why don't you simply do a if statement to test which key modifiers are pressed (ignore SHIFT directly) and then do a switch for each modifier.

Eg, CTRL + key or unmodified keys.

That is what I do usually, for keeping the code readable.
 
Why don't you simply do a if statement to test which key modifiers are pressed (ignore SHIFT directly) and then do a switch for each modifier.

Eg, CTRL + key or unmodified keys.

That is what I do usually, for keeping the code readable.

I may implement that in the future, as I add more features. For now though I have done a little cleanup, at least with my own code. I removed the switch that handles capturing the K key and replaced with if statements.

I don't think I'll mess with Dan's included code for the time being, although I do want to address it eventually just for the sake of consistency in the dll code. There are some switch\case statements, but it'll take time to clean them up. It's working and I'd rather turn my focus now to implementing UCGO as well.

---------- Post added at 06:35 PM ---------- Previous post was at 09:11 AM ----------

Trying to determine where the best location would be to locate UCGO cargo on this beast. Thinking maybe along the trusses between the front shields and the gravity wheel, but not sure that's the most feasible place.

EDIT - another quick question - since the gravwheel animation is incremented in clbkPostStep, it appears the speed is fluctuating as framerate fluctuates. Is there a way to ensure the wheel spins at a constant speed, independent of framerate? Noticed this doesn't occur in the SC3 version.

Thanks,
n122vu
 
Last edited:
EDIT - another quick question - since the gravwheel animation is incremented in clbkPostStep, it appears the speed is fluctuating as framerate fluctuates. Is there a way to ensure the wheel spins at a constant speed, independent of framerate? Noticed this doesn't occur in the SC3 version.

Yes, use the parameter "simdt" of clbkPostStep for calculating how far the wheel rotated in the time step.

Basically:

[math]p(t+dt) = p(t) + v \cdot dt[/math]
 
Yes, use the parameter "simdt" of clbkPostStep for calculating how far the wheel rotated in the time step.

Basically:

[math]p(t+dt) = p(t) + v \cdot dt[/math]

Perfect. Now have it running at constant speed. Thanks.

---------- Post added at 08:47 PM ---------- Previous post was at 08:12 PM ----------

Back to UCGO support. The more I think about it, the less motivated I am to even implement UCGO in the Explorer class. With the small size of the UCGO cargo, they would be almost invisible against the scale of the vessel. The only benefit I see might be resource consumption. Any thoughts?
 

Back to UCGO support. The more I think about it, the less motivated I am to even implement UCGO in the Explorer class. With the small size of the UCGO cargo, they would be almost invisible against the scale of the vessel. The only benefit I see might be resource consumption. Any thoughts?

You could still store some cargos inside the Shuttle Bay of the Explorer... would be visible despite the large scale of the Explorer, since some activity happens there.
 
You could still store some cargos inside the Shuttle Bay of the Explorer... would be visible despite the large scale of the Explorer, since some activity happens there.

I like that idea. Maybe start out with just the cargo locations, but down the road have some active items in the bay.

So, since the limit for UCGO cargos on one vessel is 40, would it make sense then to have 20 slots in each bay? With the containers only being 1.3M cubes, would lose them in the bay I think, if they are spread out too much.
 
I like that idea. Maybe start out with just the cargo locations, but down the road have some active items in the bay.

So, since the limit for UCGO cargos on one vessel is 40, would it make sense then to have 20 slots in each bay? With the containers only being 1.3M cubes, would lose them in the bay I think, if they are spread out too much.

I would store the ~40 tons of cargo just in the Shuttle bay, since you would then use the EarthForce (tm) shuttles for landing on planets with the cargo.

On the fighter bay, you could have provisions for rearming fighters...
 
I would store the ~40 tons of cargo just in the Shuttle bay, since you would then use the EarthForce (tm) shuttles for landing on planets with the cargo.

On the fighter bay, you could have provisions for rearming fighters...

One thing I don't know - which bay is the shuttle bay? Is it the 2 smaller bays below the larger, and is the larger the fighter bay?

Updated version coming soon, with additional docking ports available in the bays. I also moved the current UMMU EVA airlock location to just in front of the gravwheel, with the EVA'd UMMU appearing near the bottom of the top vertical strut for the gravwheel. Future plans include ability to choose between this airlock and one of the several docks that will be available in the hangar bays.
 
I think it is the larger of the two, I don't remember the Explorer to carry more fighters than for self-defense.
 
Found the following regarding loadout on the Explorer class:
Model: Earth Alliance Explorer class Research Ship
Crew: The normal crew of a explorer consists of 400 (20 officers, 380 enlisted Military.). In addition it carries some 300 mission specialists (Civilians)
Troops: Normally, none. Can carry about 7000 for short periods (3 weeks)

Vehicles:
24 SA-23E Aurora Star Fury Star Fighters
10 Crew Shuttles
12 Atmospheric shuttles

found here: http://www.kitsune.addr.com/SF-Conversions/Rifts-B5-Ships/Earth_Explorer.htm
 
Yes, sounds good. Fits to the Babylon 5 Wars record sheet of the Explorer.
 
Can't find any documentation on this, or maybe I'm missing it, but is there a maximum number of docking ports a vessel can have?
 
Can't find any documentation on this, or maybe I'm missing it, but is there a maximum number of docking ports a vessel can have?

No idea, never tested this.
 
Latest revision added to the original thread.

Changes in this upload:

- Gradual spinup/spindown of the Gravity Wheel
- Added 6 docking ports in the lower shuttle bay (currently optimized for XR2 "landing") via the config file
- UMMU Airlock relocated to just in front of upper vertical strut inside the gravity wheel
*Future plans include making additional airlocks selectable via UMMU controls (shuttle bay docks for example).
 
Didn't we have Aurora Starfury mesh somewhere on OH, maybe this one could improve the add-on a bit...

Damn...sadly only the Thunderbolt (The explorer is too old to support Thunderbolt fighters) and a Psi-Corps Starfury.

[ame="http://www.orbithangar.com/searchid.php?ID=498"]ThunderboltStarfury[/ame]
 
Last edited:
Didn't we have Aurora Starfury mesh somewhere on OH, maybe this one could improve the add-on a bit...

Damn...sadly only the Thunderbolt (The explorer is too old to support Thunderbolt fighters) and a Psi-Corps Starfury.

ThunderboltStarfury

Great minds really do think alike ;)

I contacted Jason Benson over the weekend, original author of the Explorer, and also the Thunderbolt you linked. I have his blessing to update all of his addons, including the Thunderbolt, Agamemnon, and Babylon 5 station.

I had considered working on the Thunderbolt (realize not the correct fighter) and releasing it as a surprise in the package. I had almost talked myself out of it though, for the sake of getting the Explorer completed and available on O-H sooner rather than later.
 
I had considered working on the Thunderbolt (realize not the correct fighter) and releasing it as a surprise in the package. I had almost talked myself out of it though, for the sake of getting the Explorer completed and available on O-H sooner rather than later.

Well, maybe I can sneak a basic DLL of one of these into the pipeline, if you have no problems maintaining it later and continue development. I just get organized moving the chaos I cause in SSU into a separate library and project and the (Non-Babylon-5) Shadow Destroyer is still mostly paperwork.
 
Well, maybe I can sneak a basic DLL of one of these into the pipeline, if you have no problems maintaining it later and continue development. I just get organized moving the chaos I cause in SSU into a separate library and project and the (Non-Babylon-5) Shadow Destroyer is still mostly paperwork.

I'd absolutely welcome anything you have to offer, and would gladly maintain it going forward.

Thanks!
n122vu
 
Status
Not open for further replies.
Back
Top