Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Development
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Addon Development Developers post news, updates, & discussions here about your projects in development.

Reply
 
Thread Tools
Old 06-15-2018, 04:48 PM   #61
Woo482
Moderator
 
Woo482's Avatar


Default

Well, my primary motivation for keeping oMMU (Not WooMMU, dammit! ) closed source is keeping the distribution controlled - I don't want 20 different versions floating around as it has the potential to ruin the user experience (IMHO). If there's the demand for the source to be open, and there's a compatible licence that lets me keep some amount of control over my work I'll be happy to consider it.
Woo482 is offline   Reply With Quote
Thanked by:
Old 06-15-2018, 07:42 PM   #62
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by Woo482 View Post
 (Not WooMMU, dammit! )
Too late for that.
Face is offline   Reply With Quote
Thanked by:
Old 06-15-2018, 11:23 PM   #63
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
I don't want 20 different versions floating around as it has the potential to ruin the user experience
If it helps any, in my experience that doesn't happen. I know the thought is a bit scary, but you can generally rely on the laziness of people.

Quote:
Not WooMMU, dammit!
Indeed, way too late. We officially request, nay, demand this be the official name. And if you don't agree, we'll just keep calling it that anyways!

Last edited by jedidia; 06-15-2018 at 11:25 PM.
jedidia is offline   Reply With Quote
Old 06-16-2018, 01:42 PM   #64
Woo482
Moderator
 
Woo482's Avatar


Default

Fine, I'll get Loru to put together a new logo
Woo482 is offline   Reply With Quote
Old 07-06-2018, 05:24 PM   #65
gattispilot
Addon Developer
 
gattispilot's Avatar
Default

Hope you do better than this:


Sometimes the terrain covers the guy
gattispilot is offline   Reply With Quote
Thanked by:
Old 07-06-2018, 05:42 PM   #66
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

What is the maximum number of astronauts, that WooMMU can handle? (In the sense of: How many crew members will be allowed inside a vehicle? UMmu had a rather low limit for some applications.)

HUGE EDIT: Request for comments: And could your API support something like a "custom data pointer" for an astronaut, for storing a pointer to a structure of vehicle specific data? It would make some modding a lot easier and could also be used to allow chains of add-ons adding their own data easily without your module needing to manage it.

Of course, for lazy developers functions like:

Code:
void * GetExtensionData(ASTRONAUT_HANDLE hA, DWORD extensionID) const;
void * SetExtensionData(ASTRONAUT_HANDLE hA, DWORD extensionID, void * newData);
would be more comfortable since you do a lot of the job. extensionID would just some identifier for different plugin APIs, 0x0 could be reserved for vessel specific data (I assume, your plugin will be similar to Ummu and store the crew on a per vessel base). But:

Code:
void * GetExtensionData(ASTRONAUT_HANDLE hA) const;
void * SetExtensionData(ASTRONAUT_HANDLE hA, void * newData);
would also be close enough for committee work. Then its up to the developers.

With a global call back function like:

Code:
void OnCrewEvent(CrewManagement &reference, DWORD eventID, long lParam, void * pExtData) {
 ...
}

//and

void RegisterCrewEvent(CREW_EVENT_FUNC * callbackfn);
....It should be possible to even install extensions to a crew simulation as Orbiter Plugins, so generic vessel add-ons could get extended without implementing the function or including a component in Multistage / genericvessel.

For example, to understand better, what I am up to: Lets imagine, somebody made a huge passenger spacecraft with a WooMMUForAll and GenericVessel and somebody else adds a Orbiter-Passenger-Plugin, that adds ticket, destination and departure information to the crew simulation of WooMMU, which can be displayed with a MFD. And later, somebody else adds a generic medical simulation plugin. Or a generic "Passenger personality plugin".

Could all be done without such extension support from your side, of course. But the required skill level for the plugin developers would be much higher and it would be much easier to create incompatibilities that would annoy the players (they would have more work finding out which add-ons work together)

Last edited by Urwumpe; 07-06-2018 at 08:25 PM.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 07-06-2018, 08:06 PM   #67
Woo482
Moderator
 
Woo482's Avatar


Default

They're stored as a STL vector, so 'a lot' is about as close as I have to a limit; I never bothered working out the actual limit way more than you could ever practically want though.
Woo482 is offline   Reply With Quote
Thanked by:
Old 07-06-2018, 08:30 PM   #68
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by Woo482 View Post
 They're stored as a STL vector, so 'a lot' is about as close as I have to a limit; I never bothered working out the actual limit way more than you could ever practically want though.

Well, I am right now working on something that could have 92 people onboard, that would be outside the scope of UMMU.


But a STL vector would really be enough... we could fit the whole population of a few countries into 4GB Orbiter memory space then.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 07-07-2018, 11:29 AM   #69
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
HUGE EDIT: Request for comments: And could your API support something like a "custom data pointer" for an astronaut, for storing a pointer to a structure of vehicle specific data? It would make some modding a lot easier and could also be used to allow chains of add-ons adding their own data easily without your module needing to manage it.
I thought about the same, the trouble I essentially see with it is: How do you persist that data over multiple sessions? I.e. how do you handle serialising and deserialising it?
jedidia is offline   Reply With Quote
Old 07-07-2018, 11:54 AM   #70
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 I thought about the same, the trouble I essentially see with it is: How do you persist that data over multiple sessions? I.e. how do you handle serialising and deserialising it?

Hmmm.... good question. Letting the plugin define how to handle this would be the best choice, but we have no way to save data outside a MFD mode.


There would need to be a way to call a LoadState/SaveState pair from a vessel during those functions. Or not call anything at all, should there be no serialization/deserialization intended or implemented.
Urwumpe is offline   Reply With Quote
Old 07-07-2018, 01:37 PM   #71
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Quote:
Originally Posted by jedidia View Post
 If it helps any, in my experience that doesn't happen. I know the thought is a bit scary, but you can generally rely on the laziness of people.
I completely agree. There aren't 10 versions of my module messaging lib. There were just 2 and then we switched everything to the new one in peace anyway. I learned that, that as long as you use your control wisely (don't abuse it and keep developing the software), it won't be taken away.
Enjo is offline   Reply With Quote
Thanked by:
Old 07-07-2018, 07:12 PM   #72
N_Molson
Addon Developer
 
N_Molson's Avatar

Default

Congrats to all people working on this, good thing to see the pillars of the community working on such "meta-plugins"
N_Molson is offline   Reply With Quote
Thanked by:
Old 07-07-2018, 07:44 PM   #73
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
How do you persist that data over multiple sessions? I.e. how do you handle serialising and deserialising it?
Quote:
There aren't 10 versions of my module messaging lib.
Ha! You just set my mind in motion there!

Serialising custom data wouldn't be a problem for WooMMU, it could provide a base class for the data-object and let the vessel-specific implementation do the writing.

The problem is of course that you have to delegate instantiation of the data to the vessel it belongs to when you load, because you don't know the class to instantiate.
But that could be solved by generic messaging. Parse all the custom data blocks as string, and send it around to all instantiated vessels at clbkPostCreation via clbkGeneric, or possibly using enjo's module messaging (Haven't looked at the API, so no idea if suitable), and everyone that sees that there's data in there that's relevant to it instantiates the data and injects it back into WooMMU. I'm open for better ideas, but this one should work.

Quote:
Congrats to all people working on this, good thing to see the pillars of the community working on such "meta-plugins"
Actually, Woo is the only one working on it. The rest of us just make his neck hairs crawl with insane feature requests

Last edited by jedidia; 07-07-2018 at 07:49 PM.
jedidia is offline   Reply With Quote
Thanked by:
Old 07-07-2018, 08:12 PM   #74
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 Actually, Woo is the only one working on it. The rest of us just make his neck hairs crawl with insane feature requests

I did not yet submit feature request A38: It needs more cowbell.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 07-08-2018, 06:24 AM   #75
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Quote:
Originally Posted by jedidia View Post
 Parse all the custom data blocks as string, and send it around to all instantiated vessels at clbkPostCreation via clbkGeneric, or possibly using enjo's module messaging (Haven't looked at the API, so no idea if suitable), and everyone that sees that there's data in there that's relevant to it instantiates the data and injects it back into WooMMU. I'm open for better ideas, but this one should work.
In the MM and MMExt one module sends data as one of the basic + basic Orbiter's types (*) and other modules are able to read them under a common name, for instance, they can expect, that the module "WooMMU" advertises a variable under a name "OnEVA" of a certain basic type and the client modules can read it, They can as well advertise messages under well known names for WooMMU to read. When multiple modules write the same message in the same time, the WooMMU could select which one to take.
I think Andrew will explain it better.
Jedidia: where is the initial problem description?

(*) Andrew added in MMExt a possibility to send std::strings and custom defined structs, provided that a central module (WooMMU) exposes their declarations in a header under OrbiterSDK/include.

Last edited by Enjo; 07-08-2018 at 05:49 PM.
Enjo is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Addons > Addon Development

Tags
development, eva, mmu, ommu


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 01:54 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 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.