Project Universal Car for Orbiter (UCO)

The best idea remain useless if no one use it. ;)

FsPassengers include failures managment and I can tell you that it's not an easy things to do to be intteresting and challenging. The rules is to broke things ONLY when the users have a chance to sort it out else it's just a pk (player kill).

In space it's even more difficult, A plane can always glide and make a crash landing, a vessel with and engine that fail at the wrong moment is 100% lost. Fuel leak at worse also end in crash landing but in space it end 100% with death if not noticed in time.
So it's not simply randomly fails things at random time. That would just be plain boring and unfair.

Now for UMMU as I see it author would have a fonction that declare "action zone"
with local position, radius and the type of action "repair" "activate" etc.
At keypress IF inside such zone UMMU would send a signal to this vessel that the zone was activated with "nn" key, charge to author to do something with it. Inside MMU a voice would say "repair activated" "system activated" "door activated" so the user have an immediate feedback.

It can be doors, system activation, repair etc.

Sound good ?

I can eventually dedicate two keys for that but it may become complicated for users.
Now I'm wondering, if 5% authors add such possibilities and 5% of users are aware of this, well, maybe I'm just loosing my time ?

What y a think ?

Dan
 
It would be good to know which UMMU pressed the button. Secondly After the action zone has been pressed then that action is then cleared so that it may happen again.
 
Dan,

I think it is a good thing, because it provides the end user with a purpose to send out their UMMu. I was thinking about this the other day while performing a simple Europa to Callisto trip in the DGIV. It would allow some flexibility and more purposeful mission design. It may even allow for a complex objective- for instance- Your goal is to deliver Chuck Norrisium from Europa to Callisto to support the new Callisto outpost. While enroute a "failure" of some kind will occur. You must ultimately get the crew to the outpost and deliver the goods.

My thought is it might be a bit ambitious to create such a module. Might be "easier" if it applied to Dansteph ships only. As you say, it becomes 1000 times harder if you try to make that a universal module. On the other hand, if you did that, you would take the U out of UMMu!

I certainly don't want to discourage you Dan. You have a good idea there, but only you really know how long programming such a module would take. I would take extra time though and make it something that would work on any UMMu compatible ship. I think such a module would be great and worth the effort.

Just my thoughts.

Cheers and Beers,
 
mhhhh...

The problem is not the universal part, I can provide to author one function that would cover almost all cases and would be simple to use. The problem is that only a fraction of author include UMMU and on this fraction how much would use such function ? Appart maybe doug beachy and me who would use it ? ;)

Sun, many idea that sound cool are just plain boring once you see it in game.

There is a LOT of AI involved to decide WHEN to fail something, to early the guy die, to late it's just plain stupid, to often it become boring, too rare it's unoticeable and user would just think it's a bug and quit/restart. Failures definitively require very skilled programmer to not be a boring random "bang" at the wrong moment, wrong frequence with just a boring and repetitive task to do if by any chance you have enough time to make an EVA and if by any chance the feedback is enough clear so the user understand what he should do. (Doc ? who read them? Sound ? how much author add spoken feedback ?)

The first time you lost one engine enroute you would think "wow" the 3rd time there is chance that you simply disable this feature. ;)

FsPassengers include 73 Crew sounds and a complex AI (>5000 C++ lines) to decide when what and how. And it's only aircraft: know procedure and only one direction to go: down. (and not within 10'000 years, at most a few hours if not minutes)

In brief I can do that function but I wonder if I will not loose my time ?

Dan
 
Dan, the best application I can think of at the moment for something like this would be to open up the airlock/nosecone of a spacecraft from the outside - e.g. if you have a pilotless DGIV with the nosecone closed, it would be brilliant to be able to open up the ship from outside! Also, when you eject from a DGIV on the ground (by the way I LOVE the eject feature!) perhaps this could be used to get a pilot back inside, assuming the airlock isn't damaged.
 
What about having completely random failures extremely unlikely, but the chances increasing significantly when the user does something incorrect/repeatedly?
 
I think what would help here is if more authors use UMMU and .dll files in general. A couple years ago Art Eaton tried to get me to compile my own .dll files instead using SC3 and after a lot of time and not much success I decided to go the easy way and just use SC3. I am very interested in creating my own .dll files because I know it would bring a lot more fuctionality to my add-on's but I feel like I need someone to hold my hand as I learn. I guess when it comes down to it most of us SC3 users are either daunted by the thought of learning to write .dll files or feel they don't have enought time to learn. I think it would help the whole community if there was a lot more "encouragment" within the community to learn to create .dlls.

That being said, I think it would be great to be able to open doors from another craft weather it be a UMMU or the DGIV, but.... is there a way do it without having to code it into the craft in which the door will be opened? If yes then I think it wouldn't be a waste of your time. If no then I do think it would be somewhat a waste of your time.... cool but a waste. :)
 
Dan, the best application I can think of at the moment for something like this would be to open up the airlock/nosecone of a spacecraft from the outside

Yes, this is probably the most intteresting, opening turbopack door, opening airlock, actionates "things" etc etc. I'll personnaly not do it for DGIV-2, time is out.

I can write the function so you can give to one zone either a defined type "open" "close" "repair" that will play a common sound when activated, either you can give it a wav filename. UMMU when activating this zone would play this sound as feedback. "great commander, now find the 3rd screw on the other side.." " great commander, now return to AE54 panel and actionnate again" "great commander...."

Cool :zzz: (nhaaa this special case would look nice)

What about having completely random failures extremely unlikely, but the chances increasing significantly when the user does something incorrect/repeatedly?

If random failure where intteresting it would have saved to me 6 month of my life ;) But hey, there is some *random* chance that it could be fun.

Dan
 
I think what would help here is if more authors use UMMU and .dll files in general. A couple years ago Art Eaton tried to get me to compile my own .dll files instead using SC3 and after a lot of time and not much success I decided to go the easy way and just use SC3. I am very interested in creating my own .dll files because I know it would bring a lot more fuctionality to my add-on's but I feel like I need someone to hold my hand as I learn. I guess when it comes down to it most of us SC3 users are either daunted by the thought of learning to write .dll files or feel they don't have enought time to learn. I think it would help the whole community if there was a lot more "encouragment" within the community to learn to create .dlls.

That being said, I think it would be great to be able to open doors from another craft weather it be a UMMU or the DGIV, but.... is there a way do it without having to code it into the craft in which the door will be opened? If yes then I think it wouldn't be a waste of your time. If no then I do think it would be somewhat a waste of your time.... cool but a waste. :)

I agree 100%.
 
Is there some good tutorials "step by step" about this on O-F ?

Dan

OK, a search of O-F yielded nothing but I did find (and I totally forgot about this one) a tutorial by Art a.k.a aethelwulffe and that led me to the orbiter wiki page with a free compiler setup so I will endeavor to become a .dll writer. :lol: I know the community will help with any questions I may have and I know I will have many. So hopefully there will be more than you and Doug utilizing UMMU soon. :cheers:
 
Very simple ship mesh, but I'll add much more details. The containers (20 feet) are added for testing and will not be part of the final mesh, I'll use UCO to attach them.

ship1.JPG
 
Back
Top