Project Wideawake International Update

[Face]

Yes, because it is so cool to have Acension Islands strewn across the solar system. :dry:

Well, maybe it doesn't make sense to add 10 Islands around the globe, but it might make sense to add it to a custom solar system or put it on green/blue Mars or whathaveyou...

Anyway, if WHAP wants to try this out, what really is the problem you have with it being a vessel? Any comments on the other advantages I mentioned above?

 

[T.Neo]

Well, maybe it doesn't make sense to add 10 Islands around the globe, but it might make sense to add it to a custom solar system or put it on green/blue Mars or whathaveyou...

Granted, I'll give you that, but if you're that intent on using it in a custom solar system etc you might as well copy and rename a base config file.

Anyway, if WHAP wants to try this out, what really is the problem you have with it being a vessel? Any comments on the other advantages I mentioned above?

IMO the complexity outweighs the gains.

I think having the entire base as a vessel is overkill- I would keep it simple, and have "snazzy" features optional for people simply want a high quality base to land at without spinning satellite dishes and active launchpads.

 

[MeDiCS]

What about some ground vehicles UCGO stuff,like a crane,and a fuel truck with your logo on it [...]

And a tow vehicle .

(Old request/bug/complaint/rant. It'd be neat, tho')

 

[Face]

Granted, I'll give you that, but if you're that intent on using it in a custom solar system etc you might as well copy and rename a base config file.

Indeed. But it is much more complex to do it that way than it is using the scenario editor. With the later, you can very easily adjust location, too. On the techical side, vessels can be manipulated in a much better way than base objects, too.

IMO the complexity outweighs the gains.
I think having the entire base as a vessel is overkill- I would keep it simple, and have "snazzy" features optional for people simply want a high quality base to land at without spinning satellite dishes and active launchpads.

I see what you mean, although I do not agree regarding complexity (just because of it being a vessel). Granted, it would need a DLL, but even a SC3 approach to the animation parts would need that (SC3.DLL, plus INI, plus static objects definition). And without animations it wouldn't make much sense anyway, because this project is all about complexity and shiny new features, isn't it? From this point of view, I'd even say it is less complex than Woo's proposed mixture of static base definitions and animation vessels.
Also: who says that WHAP can't make it to be arbitrary complex (for the user) with the vessel approach (XR-series configurations being good examples)? Maybe include a option called "Quality" with settings "KISS" to "full snazzyness"?

 

[T.Neo]

Indeed. But it is much more complex to do it that way than it is using the scenario editor. With the later, you can very easily adjust location, too. On the techical side, vessels can be manipulated in a much better way than base objects, too.

You won't get certain important things like navbeacons and runways, etc.

Shadows also can't be cast on vessel meshes- it would be more then slightly odd with a spacecraft on a runway leaving no shadow.

I see what you mean, although I do not agree regarding complexity (just because of it being a vessel). Granted, it would need a DLL, but even a SC3 approach to the animation parts would need that (SC3.DLL, plus INI, plus static objects definition). And without animations it wouldn't make much sense anyway, because this project is all about complexity and shiny new features, isn't it?

I think you somewhat misunderstood me. I was referring to complexity from an end user point of view (plugins, extra vessels in the scenario, etc). A DLL would simplify this somewhat (with autoloading etc). Spacecraft3 can be very inconvenient.

As I said before, not all users want animations etc, and making the entire base a vessel because of animations and whatnot seems a bit restrictive.

From this point of view, I'd even say it is less complex than Woo's proposed mixture of static base definitions and animation vessels.

If most or all of the static "stuff" is there already, the user can disable the vessel part if desired and still have a base to land at.

Also: who says that WHAP can't make it to be arbitrary complex (for the user) with the vessel approach (XR-series configurations being good examples)? Maybe include a option called "Quality" with settings "KISS" to "full snazzyness"?

You'll still have the complexity of a vessel in the scenario. What's the point of having a "KISS" level in the plugin when having the static parts of it as part of the base would work just as well, anyway?

 

[Face]

You won't get certain important things like navbeacons and runways, etc.

Shadows also can't be cast on vessel meshes- it would be more then slightly odd with a spacecraft on a runway leaving no shadow.

You are right with those. I think this was addressed by WHAP already in the way that he wants to include a plain base setup with navaids etc.
Shadows are certainly something to keep in mind, though.

As I said before, not all users want animations etc, and making the entire base a vessel because of animations and whatnot seems a bit restrictive.

If most or all of the static "stuff" is there already, the user can disable the vessel part if desired and still have a base to land at.

You'll still have the complexity of a vessel in the scenario. What's the point of having a "KISS" level in the plugin when having the static parts of it as part of the base would work just as well, anyway?

I understand your view. I just disagree with you, that making it a vessel instead of a base is in any way restrictive. It sure is different, but not restrictive. The best example would be Dan's Prelude.

A user not interested in animations and whatnot wouldn't want to run this "Update" - which entire purpose is to have animations and whatnot - first place, anyway. I may be wrong here, but judging from WHAPs previous postings, this is what he wants to do with this project.

Also it seems that WHAP wants to redo the static stuff in higher resolution, so there is nothing that is already there in this detail.

The point of having a "KISS" level is having a flexible collection of "static" parts for performance sake. WHAP can make the granularity as fine or course as he wants. And resembling that configuration is easier with the vessel approach, too. How'd you want to do that with a static-base approach?

 

[T.Neo]

I understand your view. I just disagree with you, that making it a vessel instead of a base is in any way restrictive. It sure is different, but not restrictive. The best example would be Dan's Prelude.

Prelude was intended for a different purpose, being more of a "stick this anywhere you want" rather then an uberbase.

A user not interested in animations and whatnot wouldn't want to run this "Update" - which entire purpose is to have animations and whatnot - first place, anyway. I may be wrong here, but judging from WHAPs previous postings, this is what he wants to do with this project.

Which I plan on doing, since apparently I can't have an "updated" base and the ability to choose whether I want bells and whistles or not.

Also it seems that WHAP wants to redo the static stuff in higher resolution, so there is nothing that is already there in this detail.

Right, because there is no way at all that higher resolutions and higher poly meshes can replace those of the surfacebase.

How'd you want to do that with a static-base approach?

Release texture/object packs in addition to the base addon.

And I would save the end user the trouble of having an extra vessel in the scenario and an extra plugin running in Orbiter. Not to mention the work I'd save myself.

 

[Face]

Right, because there is no way at all that higher resolutions and higher poly meshes can replace those of the surfacebase.

Release texture/object packs in addition to the base addon.

And I would save the end user the trouble of having an extra vessel in the scenario and an extra plugin running in Orbiter. Not to mention the work I'd save myself.

Apparently you have a good plan on how to do that all in a more user-friendly way, so would you mind boarding the train and help WHAP out a bit on planning and modelling? Join the "WIN Update Taskforce" now! :rofl:

Seriously now, I'd say a single addon is much preferable to separate texture/object packs. And I still don't understand how the mere presence of a vessel or a plugin can trouble Orbiter users.

Do you know a way to exchange surface-base object textures with higher-resolution textures on-the-fly (i.e. without replacing files)? If so, please let WHAP know, because I think this is one of the important reasons why he want it to be a vessel. Come to think.. is it even possible to use high-resolution textures for surface-base objects?

 

[T.Neo]

Apparently you have a good plan on how to do that all in a more user-friendly way, so would you mind boarding the train and help WHAP out a bit on planning and modelling? Join the "WIN Update Taskforce" now!

Only if I get a badge.

Seriously now, I'd say a single addon is much preferable to separate texture/object packs. And I still don't understand how the mere presence of a vessel or a plugin can trouble Orbiter users.

That addon isn't preferable if it limits what the user wants to do.

The presence of a plugin or vessel can and will cause problems. It's an extra vessel in the scenario, and interaction between plugins always has the potential of causing bugs.

Do you know a way to exchange surface-base object textures with higher-resolution textures on-the-fly (i.e. without replacing files)? If so, please let WHAP know, because I think this is one of the important reasons why he want it to be a vessel. Come to think.. is it even possible to use high-resolution textures for surface-base objects?

I don't see why it should be so important to change the resolution of the files while the scenario is running.

I also don't see how you can change resolutions at all without changing the files. Maybe there is a resolution limit for texture files, but a mesh is a mesh...

 

[wehaveaproblem]

Ok, lots to say.

Firstly I think there may be a little confusion about the project as a whole.
I know I posted this in the WIN Update threas, but I didn't plan to. I planned to start a new thread. So I post the following in bold:

This is not a WIN update. This is a seperate, stand-alone base project.

I spent a lot of time and effort making WIN as low-end friendly as I could. That meant consessions on polys and textures. This project is the opposite, it is me being greedy on both those fronts. It is also a seperate base idea and design from WIN. It is a bit of bling. If you don't want that or your PC can't handle it, then don't use it. Use WIN. It's a little selfish I know, but I think I've earned that.

That said, I would like to make 2 points regarding low-end users. Firstly, if you can run Orbiter with a few XR-5s running then I think you'll be fine actually.
Secondly, if I include high poly count meshes in the base.cfg, then I am forcing Orbiter to load a lot of stuff unecessarily if you aren't flying to Ascension today - that defeats the point of having the hi-use stuff optional. But if you want to use Ascension, then load it. It'll be as quick and easy to do as any Scenario Editor entry.

That said, as I have said before, I will have a base.cfg file for the navigational aids. Now, I may still include some static meshes. Maybe just the island and the runways. But the meshes are rendered differently by the engine from the base.cfg than from the scn. So they just don't look as nice (load one for yourself and see).
Now, shadows are a big problem that I accept. To that end I will probably include the runways in the base.cfg file. However, bare in mind that even when loaded in base.cfg, a vessel will not cast a shadow on that mesh. The fueling ares in the current WIN will show you that. The only work around is to have a high res tile under the mesh to act as the floor, but that will be a pain to model correctly.
But it shouldn't be a long term problem anyway, surely the Beta engine will support shadows? But transparencies are also a ***** to manage in the base.cfg file, and I have plans for plenty of glass, so I don't want a hindrance to that.
Basically, using a vessel as the base makes it very easy for users to use this base if they want to. It also makes it easier to dev and code. Also, I want this to be progressive with regards to Beta, not regressive. Using the base.cfg does not help it traverse over to future version of Orbiter. Having a single coded vessel is much easier to port I'm sure.

As to grading the bells and whistles. Beyond basic LOD I hadn't thought about having the base scalable in it's bling. TBH, that wasn't the point of this project. I want to make it a complete base, not a set of patches and options. Like I said earlier: use it, or don't. But it's all or nothing for this one.

WHAP