[closed] UCGO beta test ver 091209

[DanSteph]

JackJL a écrit:
There seems to be a minimum value of MaxSpeed for cars of 10kph. Even if lower values are defined in the config, the vehicle
will still move up to 10kph. This still happens even if MaxSpeed and/or EnginePower are 0 or negative!
It might seem strange that I want to make a car that can't move! I've been working on using a car as an anti-radiation bunker
as it can store UMMUs. I've got the flashing lights as a radiation warning
Would it be possible to have a 0 speed car? I can see this building=car being quite good for all sorts of ground base things,
especially when we could see the people inside (also in the car code).

Okay, changed, when you set 0 maxspeed power is also set to zero so cars can't move.
I see this hack as a bit dangerous if the author doesn't specify clearly that's a cars hack
in his doc. But well... who I am to forbid "hack" !?

Please note: I'll not "officially" support this hack mean I'll not start to change other things in code.
A base dll with UMmu and anim should be done in another addon. (doesn't spacecraft 3 allow this?)

Dan



Message modifié ( 13-12-2009 06:04 )

[JackJL]

Thanks Dan

I see this hack as a bit dangerous if the author doesn't specify clearly that's a cars hack
in his doc.

I hope this will be obvious from the mesh!

Please note: I'll not "officially" support this hack mean I'll not start to change other things in code.
A base dll with UMmu and anim should be done in another addon. (doesn't spacecraft 3 allow this?)

Understood, but for us non dll'ers this is now a much neater method than UMMUFA.

[alrik]

UCGO BUG

Bug with:

UMMU


Short description:

Atmosphere analysis.

Severity

writting error


Complete description

When I push the ctrl-x keys ummu dont do nothing
//FOUND

The problem was that in the docs its written CTL-X and is with ALT-X


Reproduce bug

In the UMMU documentation.



Post Edited ( 12-13-09 17:21 )

[the.punk]

Yes. This is because the key has been changed but it seems not in the doc.

[sunshine135]

DanSteph wrote:

sunshine135 a écrit:
Looks like:   AV3 instead of EVA... This is at the "ship's bottom" of the EVA airlock looking up.

Mhhh if you speak about this yes it's a feature, on the left a UMMU view with head "up" he can read "EVA
01" on the top of
airlock. on the right the same image but UMmu standing up side down, he still can read "EVA 01"



Dan

     

Okay, it is official....I am getting old and stupid! It took me three times looking at that to see it. Thanks hammering on my
ineptitude! Something finally got through.

[gattico]

Not sure if I am doing it wrong.  But is there a way to see the hud on the Arrow and the control screen without zoom in
and out.  I need to zoom in to see the HUD and screen info and then zoom out to see the controls.

[DanSteph]

gattico a écrit:
Not sure if I am doing it wrong.  But is there a way to see the hud on the Arrow and the control screen without zoom in
and out.  I need to zoom in to see the HUD and screen info and then zoom out to see the controls.

Did you tried to turn your head with right mouse click ?

Dan

[gattico]

Not using a mouse.  Using a Laptop.  I can change the view using ALT and arrow keys.  


This FOV view at 70 so I can see all the keys and screen


Not sure if PILOT TERMINAL should be upside down from the pilot  POV

DanSteph wrote:

gattico a écrit:
Not sure if I am doing it wrong.  But is there a way to see the hud on the Arrow and the control screen without zoom in
and out.  I need to zoom in to see the HUD and screen info and then zoom out to see the controls.

Did you tried to turn your head with right mouse click ?

Dan

[DanSteph]

Then sorry you should use right click+mouse (or POV joystick button) to turn head. VC are supposed to work like this.
What screen res are you using ?

Terminal yes, because the light cache is seen by peoples standing in front.

Dan



Message modifié ( 14-12-2009 08:49 )

[gattico]

1024x768

DanSteph wrote:
Then sorry you should use right click+mouse (or POV joystick button) to turn head. VC are supposed to work like this.
What screen res are you using ?

Terminal yes, because the light cache is seen by peoples standing in front.

Dan

[Fox-Terrier]

is it me or is there a lack of bugs recently ?
it seems to me that the release date is approaching

[Dambuster]

I'll resume bug-searching very soon.

Also, I've noticed that when using the Scenario Editor to move DGIVs and UMMUs which are already in motion onto the surface
of a planet, it seems that 100% of the time, the DGIV is destroyed and the UMMU is killed.  Is this a bug?

[Dambuster]

UCGO BUG

Bug with:

Arrow freighter


Short description:

When all crew dead, pressing anywhere (not just on the buttons) on the control panel produces an error tone


Severity

Detail


Complete description

As above


Reproduce bug

Kill or EVA all your crew, then press in various areas where there are not buttons on the virtual control panel.  You will
hear an error beep, the same as if you pressed a button.


Miscallenous

Not sure if this is a feature, but if so I'm not sure it makes sense.

[Dambuster]

UCGO BUG

Bug with:

Arrow freighter


Short description:

Autohovering failure


Severity

Minor/serious?


Complete description

When in the atmosphere of a planet and trying to bleed off speed normally whilst you have the autohover autopilot activated,
the Arrow seemed to pitch up when under 10x/100x (I think mostly 10x, though) time acceleration.


Reproduce bug

Begin autohover autopilot at about 1000m/s and 1.5km in altitude.  Have Arrow's nose facing maybe 90 degrees from velocity
vector.  When under time acceleration, the Arrow should begin rotating around its vertical axis, and once/twice every
rotation, it will pitch up.


Miscallenous

I'm afraid I've only tested this on Mars, from a ground speed of ~1000m/s and at around ~1.5km in altitude.

[Dambuster]

UCGO BUG

Bug with:

Arrow freighter/cars


Short description:

Mesh of Rover in Arrow's bay, when lowered to the ground.


Severity

Detail


Complete description

When the Arrow is on the surface of a planet, and the rover is lowered to the ground, the instant the lift touches the
ground, it is replaced by another, more complex mesh.  Whilst I realise this isn't a bug, it would probably look very odd if
someone wants to make a film out of this :P


Reproduce bug

As above.


Miscallenous

Another thing I noticed (and this may actually be a bug! ) was that when the rover's lift is lowered to the ground, but no
crew are EVA'd/loaded on it (nor is the focus switched to it), if you take off again without raising the lift, the rover is
left behind.  However, if you then land again with the rover left on the ground, and raise the lift (provided the rover is
nearby), the rover will snap onto the lift and go up with it.  This will also happen even if the Arrow is a few meters above
the ground.

[woo482]

I'm guessing the reason for the mesh change is because it is much easier to animate a mesh with less Groups

[Dambuster]

UCGO BUG

Bug with:

Arrow freighter


Short description:

Autolanding not-quite-right


Severity

minor


Complete description

Prolonged orbiting of landing zone before actually landing


Reproduce bug

Approach the landing zone with some forward velocity, and you velocity vector not pointed right at the LZ (from fairly close
range, so ~5km).  If autoland autopilot is activated, you will circle around the landing zone several times before actually
landing.


Miscallenous

This may just be a limitation of the autopilot, but you did say you'd rather be safe than sorry, so...here it is

[gattico]

On the config.  Can you have more than 1 mesh group?  For instance.  on his config:
CrewMeshGrpNbr1   = -1         ; Mesh group number of crew 1, will be visible if crew >0, set to -1 if none

Where is this set I mean which mesh groups are CrewMeshGrpNbr1?

[Dambuster]

UCGO BUG

Bug with:

Ummu


Short description:

Extra text field for 'HAND attached object'


Severity

Detail


Complete description

When you have an object grappled to your UMMU's hands, sometimes it will display an extra 'HAND attached object: ---' in the
UMMU HUD at the bottom left.  (i.e. there will be two of 'HAND attached object', and one of 'BACK attached object'.


Reproduce bug

I've found two ways of reproducing this:
a) With no objects grappled, first grapple one object with your hands, and grapple another object onto your back.  Upon
grappling the second object, an extra line saying 'HAND attached object: ---' will appear in the bottom left of your HUD.
b) If you then drop the object on your hands then pick it up again, this extra field will disappear.  However, if you have
both objects grappled (and no extra line displaying), if you drop the object on your back, this extra line will appear.


Miscallenous

This extra line does not appear if you first grapple an object with your back, and then grapple another object with your hands.

[gattico]

I can confirm this.

Dambuster wrote:
UCGO BUG

Bug with:

Ummu


Short description:

Extra text field for 'HAND attached object'


Severity

Detail


Complete description

When you have an object grappled to your UMMU's hands, sometimes it will display an extra 'HAND attached object: ---' in the
UMMU HUD at the bottom left.  (i.e. there will be two of 'HAND attached object', and one of 'BACK attached object'.


Reproduce bug

I've found two ways of reproducing this:
a) With no objects grappled, first grapple one object with your hands, and grapple another object onto your back.  Upon
grappling the second object, an extra line saying 'HAND attached object: ---' will appear in the bottom left of your HUD.
b) If you then drop the object on your hands then pick it up again, this extra field will disappear.  However, if you have
both objects grappled (and no extra line displaying), if you drop the object on your back, this extra line will appear.


Miscallenous

This extra line does not appear if you first grapple an object with your back, and then grapple another object with your
hands.

Post Edited ( 12-15-09 21:09 )

[DanSteph]

Dambuster a écrit:
Arrow freighter
Short description:

Autohovering failure


Severity

Minor/serious?

Vessel tend with speed to orient in the direction of airflow, this is normal and the doc say autopilot are not garanteed for
atmospheric flight.

[DanSteph]

Dambuster a écrit:
Bug with:

Arrow freighter

Short description:

Autolanding not-quite-right

Workaround would need one week of rework and test (wich may introduce new bug) doc say autolanding must be launched when trajectory pass over landing point and with enough distance, the autopilot can compensate sometime but sometime not, we'll have to live with this one for this release.

Dan



Message modifié ( 16-12-2009 13:47 )

[DanSteph]

gattico a écrit:
On the config.  Can you have more than 1 mesh group?  For instance.  on his config:
CrewMeshGrpNbr1   = -1         ; Mesh group number of crew 1, will be visible if crew &gt0, set to -1 if none
Where is this set I mean which mesh groups are CrewMeshGrpNbr1?

Each crew member must be included in car's mesh, you can get his number with key F10 and 4 to cycle and must enter the number
of crew 1,2 etc etc as parameter of "CrewMeshGrpNbr"

The doc for config is still todo.

Dan

[Dambuster]

One other thing: once, under fairly high time acceleration (and for quite a long time) I had two UMMUs inside an unpacked
base on Mars, whilst I was deorbiting another spacecraft.  When I looked at my base again, both UMMUs were outside the base
and were dead...but I never moved them.  Is this a generic Orbiter limitation/bug?

[DanSteph]

Dambuster a écrit:
and were dead...but I never moved them.  Is this a generic Orbiter limitation/bug?

When you close your spacesuit UMmu are on internal reserve mean they died once used
the change of ground point contact made that they moved because of hi-warp time.

I can't test external breath when spacesuit because it will mean constant check wich would
have an impact on framerate and also would not be logicall. (what is not logical is that
on earth there is no problems with that, this is an heritance of UMmu 1.5)

Dan