Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter SDK
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter SDK Orbiter software developers post your questions and answers about the SDK, the API interface, LUA, meshing, etc.

Reply
 
Thread Tools
Old 12-31-2016, 01:24 PM   #16
martins
Orbiter Founder
Default

When commenting on the behaviour of SetAttitudeRotLevel, could you also state if you are using the 2016 release version or the latest beta? This function has changed since the release.
martins is offline   Reply With Quote
Old 12-31-2016, 03:14 PM   #17
Zatnikitelman
Addon Developer
 
Zatnikitelman's Avatar
Default

Quote:
Originally Posted by jedidia View Post
 *SNIP*

And then, there's still this remark:


Which seems to be related to those booster types, but I can't think of a way how that matters in any way. If there's no static states in the prometheus class, then it shouldn't matter at all if there are multiple instances of it around, ergo I still don't see how you get from "There might be multiple instances" to "I'll call perfectly normal methods via pointer". Since this is currently the thing that strikes me as oddest about the code, and also the thing I understand the least about it, that would be where I'd start looking for the bug. Doesn't mean it has to be there though, but before I understand what's going on here there's not much point in looking elsewhere.

Posting the header file of the class might help me a bit connecting the dots.
Since you did realize what was being talked about booster-wise, I'll leave that out. But in terms of the sentence about multiple instances. What I mean is, that's why I'm so performance-conscious. No, they don't share state, but I still want to improve the efficiency of anything that's called every frame as much as I possibly can. It's been a few years (and a different computer) since I measured it, but some of the "strange" ways I improve performance in Prometheus did have a demonstrable impact on framerate even with just one vehicle instance present.
Quote:
Sorry, Obviously I was thinking about something completely different, since I just took a look at your add-on list: PrometheusLV For Orbiter10

So, I assume "booster types" are different types of boosters that get attached to the central rocket. Now here's the propper way you would do this in an OO-way:

Code:
class booster_base
|- class booster_type_one
|- class booster_type_two
|- class booster_type_three
|-etc.
Have an array or a vector of type booster_base in your prometheus class, where all the attached boosters are contained.

Have a loop doing something like
Code:
for (UINT i = 0; i < boosters.size(); ++i)
{
    boosters[i].do_stuff(time);
}
This way you can handle states of every booster individually in their instance, childclasses can just override the do_stuff method and implement their own behavior, and you end up with code that has a lot less possibility of doing things you never wanted it to do.
I don't inherently disagree, but it does feel like extra effort and overhead for little to no benefit. I don't see a performance improvement coming from that.
Quote:
Something a bit closer to the actual problem you're having and a bit less about the weird structure. Have you considered this property of SetAttitudeRotLevel():



In other words, you're setting the levels for the roll groups and the pitch groups:


But if some thrusters are part of both the roll groups and the pitch groups, the second call will indeed overwrite their prior setting, a behavior that would exactly match your problem. So, is every one of your RCS thrusters only in one thruster group, or do some of them pull double duty (which wouldn't be out of the ordinary)?
Yep, that would do it before I changed out SetAttitudeRotLevel for direct calls to SetThrusterGroupLevel

Quote:
Originally Posted by martins View Post
 When commenting on the behaviour of SetAttitudeRotLevel, could you also state if you are using the 2016 release version or the latest beta? This function has changed since the release.
This is still 2010. Though I'll convert to 2016 not long after release (or whatever the current Orbiter is by then at the rate I'm going) I want to stabilize everything I can before introducing new variables.
Zatnikitelman is offline   Reply With Quote
Old 12-31-2016, 04:43 PM   #18
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Quote:
Originally Posted by jedidia
 Have an array or a vector of type booster_base
Obviously you meant std::vector<booster_base *>, or better yet: std::vector<std::unique_ptr<booster_base>>... phew.

Quote:
Originally Posted by Zatnikitelman View Post
 I don't inherently disagree, but it does feel like extra effort and overhead for little to no benefit. I don't see a performance improvement coming from that.
There's no performance improvement from the strategy pattern. It's used for better maintenance.

Last edited by Enjo; 12-31-2016 at 06:10 PM.
Enjo is offline   Reply With Quote
Thanked by:
Old 01-01-2017, 05:24 PM   #19
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
I don't see a performance improvement coming from that.
There isn't. At least not if you consider performance purely as "performance of the code when executed". If you take into account "performance of the programmer that has to maintain and debug the code", there's quite some improvement without actual loss of computing performance. The memory overhead is larger, yes, but we've stoped worrying about that since the time we first measured RAM sizes in Gigabytes...

Anyways, if you're confident that the bug is not located in that part of the code, which it well might not, I'll stop pressing the issue. Your way does work, it's just very difficult to read and hard to maintain and debug, both things that are very important in todays coding paradigms, and the reason why object oriented programming was invented in the first place.

Quote:
Obviously you meant std::vector<booster_base *>, or better yet: std::vector<std::unique_ptr<booster_base>>... phew.
Yes, the terminology I chose was wrong. I'm not sure why, but I have this thing where I think of "iterables" (pardon my Java) as "being of type X" instead of "containing objects of type X", even though I'm fully aware of the difference.

Quote:
Yep, that would do it before I changed out SetAttitudeRotLevel for direct calls to SetThrusterGroupLevel
If you have thrusters in multiple groups, you still have the same problem, even if you use SetThrusterGroupLevel(). In fact, I would assume that SetAttitudeRotLevel() is merely a wrapper that calls SetThrusterGroupLevel(), or at least applies the same operations to the groups as the other method. It's merely got a more convenient interface.
jedidia is offline   Reply With Quote
Thanked by:
Old 01-02-2017, 03:03 AM   #20
Zatnikitelman
Addon Developer
 
Zatnikitelman's Avatar
Default

Quote:
Originally Posted by jedidia View Post
 *SNIP*

If you have thrusters in multiple groups, you still have the same problem, even if you use SetThrusterGroupLevel(). In fact, I would assume that SetAttitudeRotLevel() is merely a wrapper that calls SetThrusterGroupLevel(), or at least applies the same operations to the groups as the other method. It's merely got a more convenient interface.
I should have seen this coming. Ok, so, I'm making progress. I added independent roll thrusters. It seems to have pretty much solved it. The only sticking point is sometimes depending on how the vehicle rolls during ascent, it may end up way off heading. My target heading during testing has always been a hard-coded 90 degrees, but sometimes I end up at something like 40 degrees, or even 327. I think it's just a matter of tuning all the parts of the autopilot, including literally tuning the PID loop that controls the vertical roll.

Again, thanks so much for sticking with me through all of this and dealing with my terrible, old, code!
Zatnikitelman is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter SDK


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 05:28 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.