SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[Urwumpe]

Typical microsoft. :facepalm:

Yeah. But it isn't a really bad language. It has weaknesses and the pool of available libraries is pretty small compared to Java, but you can still find enough libraries for a task (though often with a beta status).

But it should be more than good enough for our task.

I am still not sure if it would make sense to integrate some network client into it for displaying live data from a simulation. Maybe a special client would be the better choice then.

For the GPC improvements, I slowly get back to work here after my vacation. Debugging the GPC software is one design aspect right now, we need some tools there to allow verifying the software. Another design choice is "internal DSL" (hardcoded programs in C++ using an internal API) vs "external DSL" (Script files using an external API). The internal would be a bit less effort to implement, but the external version would be more comfortable for debugging and testing.

 

[GLS]

I am still not sure if it would make sense to integrate some network client into it for displaying live data from a simulation. Maybe a special client would be the better choice then.

I'd show live data in MCC and LCC vessels. We could have a vc where we could jump from console to console and have the data displayed.

 

[Urwumpe]

I'd show live data in MCC and LCC vessels. We could have a vc were we could jump from console to console and have the data displayed.

Yes, but also I want to have a single point of contact there in the simulation for any network communication. a MCC would be the best choice for this, so any network client would only be for interacting with the MCC, for example allowing a VSA to include human flight controllers.

In the ideal case, our MCC should be good enough to support a player focusing on flying the orbiter without any further human interaction needed.

But in case somebody wants to have some fun with network clients and teamspeak... I would let them have it.

 

[GLS]

Well, after a few hours playing with the whole Visual C# thing, I can say that it would be much faster (for me at least) to make SSUWorkbench in Visual Basic 6. :facepalm:
This is a bloody mess. Even resizing a button takes minutes to get right as it's all connected and the rest of the controls move with it. I try to shrink a line and the one below begins to grow.... :compbash:

Well, at least it runs, and I'm trying to get the "MECO (Legacy)" tab to do what the old MECOTool did. There are some corrections needed to the values used so it all matches with Orbiter.

---------- Post added at 05:58 PM ---------- Previous post was at 03:19 PM ----------

I've been having these random CTDs on loading launch scenarios for a while now (it stops somewhere inside Orbiter), and the last thing in the log is the ET vessel being loaded. So I started adding log messages to the functions there to figure out what is going and have been narrowing in the problem area for the last few days (I get maybe one CTD out of 10 or 15 runs per day).
Finally, on the first run of the released Orbiter 2016 I got the crash I wanted, and the CTD occurs when loading the ET mesh with oapiLoadMeshGlobal(), and it never returns from there. As the ET meshes have been changed recently, I bet the new ones have some sort of issue or feature that causes Orbiter to die when it tries to load them.

 

[DaveS]

[/COLOR]Finally, on the first run of the released Orbiter 2016 I got the crash I wanted, and the CTD occurs when loading the ET mesh with oapiLoadMeshGlobal(), and it never returns from there. As the ET meshes have been changed recently, I bet the new ones have some sort of issue or feature that causes Orbiter to die when it tries to load them.

Same here but only with the LWT. The SLWT and SWT loads fine 100% of the time. I'm taking a look at the LWT right now to see if I can't spot any issues.

 

[GLS]

Same here but only with the LWT. The SLWT and SWT loads fine 100% of the time. I'm taking a look at the LWT right now to see if I can't spot any issues.

I get CTDs with the "Launch Test" scenario, and that is SLWT, so it's not just a LWT thing.
(if you do any changes please commit them to the trunk, as this issue might also be affecting the 2010 version)

 

[DaveS]

After doing some tests and debugging, I don't think it's the ET mesh that's at fault. To confirm this thinking, please use this scenario. It shouldn't produce a CTD. I have ever only gotten CTDs in pre-launch scenarios so I'm suspecting some issues there.

BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51683.5738343375
  Context SSU
END_ENVIRONMENT

BEGIN_FOCUS
  Ship ET
END_FOCUS

BEGIN_CAMERA
  TARGET ET
  MODE Extern
  POS 3.21 -8.95 -113.90
  TRACKMODE GlobalFrame
  FOV 40.00
END_CAMERA

BEGIN_SHIPS
ET:SSU_SLWT
  STATUS Orbiting Earth
  RPOS 637625.46 117957.12 6694218.19
  RVEL -4973.631 -5844.813 572.556
  AROT 95.48 -40.27 -6.99
  VROT -0.07 -0.00 0.00
  AFCMODE 7
END
END_SHIPS

 

[GLS]

After doing some tests and debugging, I don't think it's the ET mesh that's at fault. To confirm this thinking, please use this scenario. It shouldn't produce a CTD. I have ever only gotten CTDs in pre-launch scenarios so I'm suspecting some issues there.

BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51683.5738343375
  Context SSU
END_ENVIRONMENT

BEGIN_FOCUS
  Ship ET
END_FOCUS

BEGIN_CAMERA
  TARGET ET
  MODE Extern
  POS 3.21 -8.95 -113.90
  TRACKMODE GlobalFrame
  FOV 40.00
END_CAMERA

BEGIN_SHIPS
ET:SSU_SLWT
  STATUS Orbiting Earth
  RPOS 637625.46 117957.12 6694218.19
  RVEL -4973.631 -5844.813 572.556
  AROT 95.48 -40.27 -6.99
  VROT -0.07 -0.00 0.00
  AFCMODE 7
END
END_SHIPS

No CTDs so far, but the ones in the launch scenarios were +/- rare.
It could be something else in the launch scenarios or some other part, but right now what we know is that it crashes loading the ET mesh. It could be that the meshes (and code) are totally inocent and it's a Orbiter bug of some kind.
I'm out of ideas on this one. :shrug:

 

[Urwumpe]

Could it be related to the texture changes to the ET?

 

[DaveS]

Could it be related to the texture changes to the ET?

What texture changes? If you're talking about the change that happens at SRB sep, that code has been inactive for a long time now.

 

[STS]

Yes, but also I want to have a single point of contact there in the simulation for any network communication. a MCC would be the best choice for this, so any network client would only be for interacting with the MCC, for example allowing a VSA to include human flight controllers.

In the ideal case, our MCC should be good enough to support a player focusing on flying the orbiter without any further human interaction needed.

But in case somebody wants to have some fun with network clients and teamspeak... I would let them have it.

I feel mentioned

 

[GLS]

Could it be related to the texture changes to the ET?

This made me check the compression format of the ET textures and it's all DXT1, which in my "graphics ignorance" I think is what we want. As I had "the hands in the doe" I checked a few more textures and some vc panel textures that are 32bpp BGRA... is that good, bad, or doesn't matter for performance? And is it needed, as those files are bigger than the others?

 

[Urwumpe]

What texture changes? If you're talking about the change that happens at SRB sep, that code has been inactive for a long time now.

That one. So no calls?

 

[DaveS]

That one. So no calls?

Now that I took a second look it has been re-enabled. Ad I'm no good at code, could someone disable it again and see if things improve?

 

[Urwumpe]

Now that I took a second look it has been re-enabled. Ad I'm no good at code, could someone disable it again and see if things improve?

Would be interesting to see if it has an effect. I have a similar issue with the release candidates of Orbiter 2016 and my Black Dart project, the custom VC displays are a reliable source of CTDs, because the texture table of the mesh structure inside Orbiter is broken.

 

[GLS]

The CTD is in clbkSetClassCaps() well before anything starts running, so that texture change code never runs.

 

[Urwumpe]

The CTD is in clbkSetClassCaps() well before anything starts running, so that texture change code never runs.

Which line of code?

EDIT: Sorry, if I might not be very helpful in debugging right now. My brain is still occupied with finding the opposite of a bug I discovered at work today... finding out why some jobs fail, others convert properly and a few have an assertion triggered (which was the reported bug)...

 

[GLS]

Which line of code?

It doesn't return from this
hTankMesh = oapiLoadMeshGlobal (SLWT_MESHNAME_ET);

 

[Urwumpe]

It doesn't return from this
hTankMesh = oapiLoadMeshGlobal (SLWT_MESHNAME_ET);

Hmm... strange. DirectX9 client, right? Did you increase the debugging level of the clients already?

 

[DaveS]

Hmm... strange. DirectX9 client, right? Did you increase the debugging level of the clients already?

I have it set to maximum and there's nothing about the ET.