Project HASSESA Industries

[Mojave]

Well lookie there, it made it into Orbiter; albeit with improper parameters and see-through-ship cockpit windows! Tis a start.

I guess I fix phasing through the earth problems with touchdown points.

Huh, closer than I thought.

I'm hoping the suits they wear inside the ship are less bulky, or airline seats are going to look good by comparison.

---------- Post added at 22:26 ---------- Previous post was at 14:40 ----------

I knew the Draft was smaller, but damn. Kind of happy about this actually because it's supposed be smaller. Looks like Aeadar may get his wish.

Did some debating and decided I'm gonna use Spacecraft4 and it's new features for this craft.

---------- Post added 01-05-17 at 15:31 ---------- Previous post was 01-04-17 at 22:26 ----------

I've discovered the reason the the glass sees through everything is because the canopy is single-faced. Going to have to re-model it. Luckily, I broke that off as a section early in the development so it won't be a large-scale production.

---------- Post added at 16:23 ---------- Previous post was at 15:31 ----------

And then I realized that the "intrude" tool has a use and that "extrusion" tool is not the answer for everything...

 

[Mojave]

Draft_January 2017 Update

Dat Panel

Dat Console

Dat Earth

Dat Pilot Seat

Dat Draft.

Ladies and gentlemen, I'm proud to announce that the Draft now has sitable seats!

More to come as time permits!



Sam

 

[Mojave]

HUD I Guess

This is, uh, where the HUD is supposed to be. If anyone can possibly point me in the proper direction for creating one of these, I'd be very appreciative.



-Samuel

 

[Mojave]

HUD Again

Well, I learned today that .msh files can be manually edited. Thanks for the help, Donamy!

Only thing I can't figure out now is why the HUD doesn't display all elemental data.

-Samuel

---------- Post added at 14:45 ---------- Previous post was at 14:39 ----------

Fixed. Turns out that there is a difference between certain, little, hard-to-spot punctuation marks.

---------- Post added 01-24-17 at 10:13 ---------- Previous post was 01-23-17 at 14:45 ----------

Believe me, I'm not a fan of it either.

That freaked me out a lot more than it should've. It's nice to see what improper point definition does, and neat to see that the .msh exporter tessellates? The lesson here is that you can never escape trigonometry no matter how far away you run from it.

Now just one question: how does one buttons?


I don't remember if I said it or not, but I decided to switch to a separate .msh for the cockpit. This was done not to save framerates, but for convenience of (hopefully) not having to re-define my HUD and MFD points with every .msh edit.



-Samuel

 

[Urwumpe]

Now just one question: how does one buttons?

Well, there are multiple good ways. How do you want the buttons to look and behave like?

 

[Mojave]

Well, there are multiple good ways. How do you want the buttons to look and behave like?

I kinda just want them to control the MFD as they would in, say, the ShuttleA. They don't even need to be fancy and have lettering. If I could overlay them overtop the static buttons on the MFD frame that would do just nicely.

I figure, from looking at some .msh file data, that the buttons work similarly to the un-rendered rectangles that the MFDs and HUDs are made of. Is that the case?

Maybe it's time I learn to code, lol.



-Samuel

 

[Urwumpe]

I figure, from looking at some .msh file data, that the buttons work similarly to the un-rendered rectangles that the MFDs and HUDs are made of. Is that the case?

Sort of. Generally, you use a sufficiently small dynamic texture for all buttons of the MFDs them and paint the MFD labels on it, when the MFD mode changes.

 

[Mojave]

Sort of. Generally, you use a sufficiently small dynamic texture for all buttons of the MFDs them and paint the MFD labels on it, when the MFD mode changes.

Must it be done with a texture, or could I create the fields beforehand to test out the concept? Need I code, or can this be done by setting coordinates inside the .msh file?

 

[Urwumpe]

Must it be done with a texture, or could I create the fields beforehand to test out the concept? Need I code, or can this be done by setting coordinates inside the .msh file?

You could just use a static texture for the start, then make the texture dynamic in the mesh (adding a " D" to the line of the texture at the end of the file) and begin drawing custom texts on them. But a texture is more or less mandatory.

The coordinates can be set in the mesh file for the texture mapping (which text is shown on which button), but later, you should know the texture coordinates (in pixels, in the texture file) for each button for drawing the labels dynamically.

Again, you can have a lot of fun there if you want to, the imagination is the limit.

 

[Mojave]

You could just use a static texture for the start, then make the texture dynamic in the mesh (adding a " D" to the line of the texture at the end of the file) and begin drawing custom texts on them. But a texture is more or less mandatory.

The coordinates can be set in the mesh file for the texture mapping (which text is shown on which button), but later, you should know the texture coordinates (in pixels, in the texture file) for each button for drawing the labels dynamically.

Again, you can have a lot of fun there if you want to, the imagination is the limit.

Oh, I intend to go all out. I just need to get the basics down first so I can use the resources. I'd really love to add switches and stuff too, but I'm not sure that can be done in spacecraft3 only. I'm thinking I'm going to need to start learning how to use the API in conjunction with a compiler program. Any suggestions on that front?

 

[Urwumpe]

Oh, I intend to go all out. I just need to get the basics down first so I can use the resources. I'd really love to add switches and stuff too, but I'm not sure that can be done in spacecraft3 only. I'm thinking I'm going to need to start learning how to use the API in conjunction with a compiler program. Any suggestions on that front?

Start with small but determined steps. Nobody writes a DG on his first day. Getting the compiler set up and compiling one of the examples is already a bigger step than many imagine.

And finally, keep your add-ons small initially in terms of complexity and features - your shuttle project here is otherwise quickly growing too big for doing it without experience and will fail after a lot of enthusiasm. You need to learn how to structure your add-on code, how to write good comments that you understand even after seven drunken nights and how to avoid doing the same work twice. This sounds easy, but requires understanding yourself more than C++ or Orbiters API.

I started out as professional C++ developer before making add-ons in Orbiter, so I am hardly a good teacher for somebody without C++ experience. Many here know what I mean.

PS: It is no shame to move your old C++ sources into the history museum and do them again from scratch after some months of learning. Nothing is worse than the code you did last year.

 

[Mojave]

Start with small but determined steps. Nobody writes a DG on his first day. Getting the compiler set up and compiling one of the examples is already a bigger step than many imagine.

And finally, keep your add-ons small initially in terms of complexity and features - your shuttle project here is otherwise quickly growing too big for doing it without experience and will fail after a lot of enthusiasm. You need to learn how to structure your add-on code, how to write good comments that you understand even after seven drunken nights and how to avoid doing the same work twice. This sounds easy, but requires understanding yourself more than C++ or Orbiters API.

I started out as professional C++ developer before making add-ons in Orbiter, so I am hardly a good teacher for somebody without C++ experience. Many here know what I mean.

PS: It is no shame to move your old C++ sources into the history museum and do them again from scratch after some months of learning. Nothing is worse than the code you did last year.

Thanks for the advice. I've been looking around at many different development threads to sort of gain an idea of what is required to start such a project.

Do you think it would be beneficial to continue on my current path with spacecraft3 and finish the project as it is? Then at some point in the future, when I've learned the things you talked about, come back to it?

I don't imagine my first release of the Draft has to necessarily encompass every feature I want initially. A proof of concept is a good cornerstone, no?

If I'm honest, I didn't think the project would make it to this stage.



-Samuel

 

[Urwumpe]

Thanks for the advice. I've been looking around at many different development threads to sort of gain an idea of what is required to start such a project.

Do you think it would be beneficial to continue on my current path with spacecraft3 and finish the project as it is? Then at some point in the future, when I've learned the things you talked about, come back to it?

I would say yes. Its more rewarding to have something done first and then go expand your skills with a new project.

But finally, learning making DLL modules is something very useful, especially if you have such things like visions, so it doesn't harm beginning to learn it in small steps next. Even making a boxy satellite that deploys antennas and solar arrays on keypress is a small challenge if you have no experience yet.

And if you have learned the skills... you can improve your spacecraft in version 2.0

 

[Mojave]

I would say yes. Its more rewarding to have something done first and then go expand your skills with a new project.

But finally, learning making DLL modules is something very useful, especially if you have such things like visions, so it doesn't harm beginning to learn it in small steps next. Even making a boxy satellite that deploys antennas and solar arrays on keypress is a small challenge if you have no experience yet.

I did that once! That was a very, very fun project. I should go back and make the animation sequence better tho.

Thanks for the encouragement, man.

 

[Mojave]

Day 34: So far, they haven't realized I'm a more complex polygon than themselves...

Added materials and some ambient parameters to make shapes render more realistically.

Are there any techniques for adding lights in a mesh? I plan to add fluorescent lights via texture at some point and need a way to emit light properly when that time comes.

That HUD glass and fixture is a LOT better than the previous hunk'a'bologna. Points if you can spot the influence.

Oh, it docks to things now. Just thought that might be an important thing to announce.



-Samuel

 

[Urwumpe]

You should talk to somebody skilled like Loru there. Lightmaps are "baked" into the texture. To me, as coder, this translates to "On full moon, with the blood of a unicorn and the hair of a virgin, you need to speak those runes loud at this old shrine...."

 

[Mojave]

Props

Found an old prop of mine. Good enough for space work?