[closed] UCGO beta test ver 091130

[Xyon]

Has anybody else testedwhat I wrote. If not I think it's my fault.

Xyon wrote:
Can't confirm that, the values changed for me. For instance, the Chrysler's top speed became 600kmh when changed.

I did notice with the Chrysler, however, a minor irritation; the indicator sound doesn't sync with the flashing. That
bothers me. :/

[the.punk]

Xyon wrote:

Has anybody else testedwhat I wrote. If not I think it's my fault.

Xyon wrote:
Can't confirm that, the values changed for me. For instance, the Chrysler's top speed became 600kmh when changed.

I did notice with the Chrysler, however, a minor irritation; the indicator sound doesn't sync with the flashing. That
bothers me. :/

Yes. Someone else can/can't confirm that? Maybe it's just me making something wrong.

[the.punk]

Ok. Tried again with Chrysler. With engine power 500 I need ten seconds to get to 100km/h. And with 50 in finteen
seconds. Is that right?

EDIT: with 5000 engine power I need again fifteen seconds for 100km/h.



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

[sunshine135]

Nemoricus wrote:
The bug isn't that you lose contact with the ground. That's fine and normal. The bug is that you can continue to accelerate
when you lose contact.

Okay- understood. I was thinking of the Freylon-based car. That may be a limitation in Orbiter, but we will see how Dan feels
about it. That might take some creative programming to fix. I believe the acceleration has been based on the normal vehicle
thrust component built into Orbiter. Thus the reason why friction doesn't slow the car down. It stands to reason that if you
continue to accelerate the car (even in Orbit) it will continue to accelerate.

[sunshine135]

UCGO BUG

Bug with:

Main System Display on the Arrow


Short description:

Arrow main system display bug and detail issues


Severity

minor and detail


Complete description

Two issues:

1. Arrow displays status messages on the lower left. In this instance, it reports the bay door closing. Once the door is
closed, however, the status message does not disappear or inform the pilot that the bay is closed or locked. It simply
continues to say "Bay door Closing"

2. Arrow main system display refers to the docking bay as "Cargo Bay" and the panel refers to it as the "Main Bay". I believe
verbiage should be consistent. Recommend using the term "Docking Bay" for both, or for mesh consistency, change the main
system display to also say "Main Bay". "Cargo Bay" is a misnomer as no "Cargo" is stored here.


Reproduce bug

Open the Arrow in any scenario and check the main system display. Open or close the main bay door and wait for them to fully
open or close. Messages never disappear.


Miscallenous

[DanSteph]

Hello Folks, back to work after some sleep.

"Phobos" I'm working on it.

Power and value of config are limited for simulation's sanity. I think they are beetween realistic value, maybe I can
increase a bit the power as the speeder reach 100km/h in 4 seconds wich is lower than the better cars.

I'll review all bugs, see if I have a stable version, pack the things and release a new beta (I hope) tonight.
So we can continue testing with a good base version.

Cheers

Dan

[Nemoricus]

UCGO BUG


Bug with:

Bottom of speeder


Short description:

There is no mesh for the bottom of the speeder.


Severity

detail


Reproduce bug

Examine the bottom of any speeder.

Miscellaneous





Post Edited ( 12-05-09 00:51 )

[Nemoricus]

UCGO BUG


Bug with:

Lunar Rover


Short description:

It is inconsistent about where UMmu's exit.


Severity

detail

Complete Description

The rover seems to alternate exit points. The first UMmu to exit after the scenario is started exits on the left. The second
one exits on the right. This is despite the fact that the UMmu's have natural exit points based on where they are sitting.


Reproduce bug

Start Drive All Cars scenario. Switch focus to the Rover. Send the UMmu out. He will exit on the left. Have the UMmu enter
and exit again. He will exit on the right. Repeat and he will exit on the left.

EDIT: This also occurs with the Chrysler. It is probably a consistent bug with any car with more than one exit point defined.



Post Edited ( 12-05-09 01:02 )

[DanSteph]

Nemoricus a écrit:
It is inconsistent about where UMmu's exit.

Sorry, I think I'll leave this one as it is now.

There is no information of seat position and adding a whole system would require too much lines in config and 3-7 days of
coding/doc to make a solid system, more complexity, more dev time for what is a detail as you said=not worty.

For model it would require 40 more poly most of time not seen, I'll see if I have the time.

Best

Dan



Message modifié ( 05-12-2009 01:12 )

[Nemoricus]

The only thing that I ask for that is that the UMmu's exit in a logical manner, i.e., the last UMmu in the car exits from the
first defined exit point, the second to last the second one, et cetera.

However, if you feel that it is too complicated to be worth programming at the moment, I understand.

Could we have the DGIV crew transfer to a UMmu-compatible mothership when the vessel is put in safe mode when docked?
However, if this is too complicated to be worth bothering with, then don't. It's just a realism issue for me.

[DanSteph]

Thread closed please see the last beta thread.



Message modifié ( 05-12-2009 05:00 )