Oh, nifty! Does the thing they want to pick up have to have a specific attachment point, or will one be generated dynamically?Currently I have the crews able to 'pick up' items using an attachment point.
Oh, nifty! Does the thing they want to pick up have to have a specific attachment point, or will one be generated dynamically?Currently I have the crews able to 'pick up' items using an attachment point.
At the moment I have it so the user must create an atatchment point when developing a cargo. currently I have it so the attachment point's ID must be "OEMU-CG" to differentiate between cargo and non-cargo items. I did this as it is easy to add an attachment point to a vessel class' Config file without any code, so any user can do this easily. If people are't fond of this I can review thoughOh, nifty! Does the thing they want to pick up have to have a specific attachment point, or will one be generated dynamically?
Thank you WolfAngriff that's a kind offer. At this point I do not have any plan to implement so-to-speak 'code-free' functionality (beyond the custom crew meshes/parameters). I may consider adding this later if widely requested.Hi !
This is the best thing to read since Orbiter 2016 release !
As a true never-happy-end-user (NHEU), i'd like to see those guys and their stuff in all the crewed vessels. But i know it would'nt be possible. So i think it would be a good thing to make it possible to implement in vessels as easily as possible. Because everyone knows a true NHEU does'nt know anything about coding and modeling, and will exclusively use the addon you didn't think about . More seriously, a few lines in a .ini file or .cfg file will be mandatory, of course. If it could be something to copy/paste with a number of variables to fill, it should be the best solution from the NHEU point of view.
With this addon, gameplay as survival and role playing will come back to Orbiter without changing it's core, so long awaited !
Thanx for your efforts !
If you need french translation for the docs, just ask !
Hi Thymo, I would be more than happy to share the source with you for NASSP, I think the way I have it currently you could quite comfortably change alot of it to uniquely suit NASSP and compile it as a 'private build' unique to NASSP vesselsOrbiterCrews sounds nice. I applaud your effort in bringing a new EVA SDK to Orbiter. I'm excited to try it out.
I do hope you seriously consider making it open source for above mentioned reasons. NASSP could desperately use more advanced EVA functionality and if it is released under a GPL-compatible license we surely can make some contributions back to make both addons better. Unfortunately we won't be able to consider its adoption if you decide to keep it closed.
why not just keep track of the numbers? Or use an std::vector?to enable a count-limit while looping through arrays
Hi All,
A couple points I wanted to get some opionions on:
Currently there are some universal limits, implemented for two reasons; to enable a count-limit while looping through arrays (this is necessary) and seccondly, limits are not rediculously huge to improve performance. These limits are:
Are these limits too constraining? I don't wish to make the limits too huge, but another approach I was considering was to have a universal config file where users could define the limits for their orbiter install. Any thoughts?
- crew limit per ship: 999
- airlock limit per ship: 20
- interface area limit per ship: 99
- habitable area per planet: 99
That sounds cool. Do be aware that anything for NASSP must be GPL-2 compatible. We can't distribute builds containing non-free components.Hi Thymo, I would be more than happy to share the source with you for NASSP, I think the way I have it currently you could quite comfortably change alot of it to uniquely suit NASSP and compile it as a 'private build' unique to NASSP vessels
That sounds cool. Do be aware that anything for NASSP must be GPL-2 compatible. We can't distribute builds containing non-free components.
Great I know you told me to keep it secret. Now we have 2 orbiter crew system in the worksI should have announced earlier that I already have a working implementation of UACS (Universal Astronaut and Cargo System). It's basically UCSO + oMMU, but there are far more changes than simply merging the 2 together (very little code was taken from oMMU, I essentially wrote the astronaut part from scratch). Everything is working well for an alpha release, but I have to write the docs for users and API. It's so boring that I am willing to pay someone to write it for me lol. Being busy with real-life doesn't help either.
I feel bad for delaying the announcement until you came up with this, so I am not sure what the plan ahead should be. The first alpha of UACS should be ready in a short time, I would say less than a month. What do you think?
UACS will be freeware and open-source of course. I will try to comment the source code as well as possible so it's easy for someone to take over in case I become too busy.
There are definitely worse things that can happen...Great I know you told me to keep it secret. Now we have 2 orbiter crew system in the works
I have private messaged youI should have announced earlier that I already have a working implementation of UACS (Universal Astronaut and Cargo System). It's basically UCSO + oMMU, but there are far more changes than simply merging the 2 together (very little code was taken from oMMU, I essentially wrote the astronaut part from scratch). Everything is working well for an alpha release, but I have to write the docs for users and API. It's so boring that I am willing to pay someone to write it for me lol. Being busy with real-life doesn't help either.
I feel bad for delaying the announcement until you came up with this, so I am not sure what the plan ahead should be. The first alpha of UACS should be ready in a short time, I would say less than a month. What do you think?
UACS will be freeware and open-source of course. I will try to comment the source code as well as possible so it's easy for someone to take over in case I become too busy.