Dan's Orbiter page
Orbiter English => Dan's add-ons => Topic started by: DanSteph on 12 January 2010, 19:15:28
-
Welcome to UCGO beta public release
Please take in account it's still a BETA TEST yet, don't forget to DOWNLOAD the FINAL
once released (a couple of day) and don't release addons based on it, wait the final.
Download
http://orbiter.dansteph.com/publicbetaucgo543/PublicBetaUCGO100112.php (40mb)
DeltaGliderIV-2
This beta automatically update your DGIV to DGIV-2 that is UCGO compatible.
DGIV-2 is a minor upgrade that allow DGIV-2 to carry UCGO cargo.
If you don't have the DGIV yet please install it FIRST before this beta.
Changelog
Here you can see regulary my change or/and update:
http://www.dansteph.com/publie/ChangeLog.txt
Bug reporting form
Please use the text form in the link below to report bugs: It's important !
http://www.dansteph.com/publie/beta_form.txt
Follow "your" bug and once cleared (probably with a new version) check and
confirm in beta test thread that the bug is gone. It may be a good idea to keep a
list of "your" bugs.
Feedback
Feedback are importants, please be verbous, precise, don't hesitate to write what you
think or post anything you want about beta.
Never forget that the final quality of addons depend enterely
of YOUR TESTS. Don't assume "other" will do the job.
Much thanks for your help :beer:
Dan
Message modifié ( 12-01-2010 19:28 )
-
Wow This is one of your best Addons Dan Thank You for Your Hard Work.
And have a nice day
-
Thanks.
I'm particulary intterested by developers feedback.
SDK are the least tested things so if someone want
to test them he would be welcome.
The new SDK & UMMU for example are really user friendly
By copying/pasting code from tutorial doc you can get a
UMMU & UCGO vessel in less than 30 minutes I think.
A big improvment over UMmu 1.5 doc.
But cars or cargos may be cool to do also. ;)
Dan
-
UCGO BUG
Bug with: Arrow freighter
Short description:
Clicking on the SEL buttons of the MFDs in the virtual cockpit causes crash
Severity
CTD
Complete description
Whenever I try to click on the MFD "SEL" buttons that normally show the MFD list, I get a CTD. This seems to happen
independently from exactly what MFD is displayed, and happens in all circumstances. A good scenario to reproduce this is the
Autoland test.
I tried to deactivate all supplementary MFD modules (transx, IMFD, aerobrake and the like) and
potentially-fishy-but-unrelated-modules (UMMUFA) and the bug persists.
Reproduce bug
Open the Autoland test scenario, click on one of the "SEL" buttons between PWR and MNU. Voilà! There's a fat chance it's just
somehow due to my very dirty Orbiter install, however.
Miscallenous
I've seen CTDs during MFD display, but this is a new type of crash here...
-
UCGO BUG
Bug with:
Arrow/UMMU/XR-2
Short description:
EVA transfer oddities
Severity
minor
Complete description
I docked an XR-2 to the Arrow, and then for jokes transferred all the crew out of the XR-2, opened all the hatches, and
undocked it. After getting the 'decompression alert', I used the Scenario Editor to redock it, and tried to EVA one of
the crew back into the XR-2. According to the screens on the Arrow, it was successful, however when I looked at the
XR-2 there was no-one there, but what happened was that a UMMU with the name 'UMmuTUCGO_-_XR2' (I named the
XR-2 'UCGO - XR2') appeared at the airlock with an invisible mesh. I tried moving this UMMU to the EVA door on the
Arrow, but there was no response when I pressed 'E'. In all other ways the UMMU seems to behave normally.
Reproduce bug
Dock XR-2 to Arrow, open all the airlock doors on the XR-2, and transfer the XR-2's crew to the Arrow. With the focus
on the Arrow, undock the XR-2 by pressing 'Cntrl + D', and then use the Scenario Editor to redock the XR-2 to the
Arrow. Then, using the Arrow, transfer a crewmember to the XR-2 and finally look at the airlock between the XR-2 and
the Arrow to see where the invisible-mesh UMMU is.
Miscallenous
The name of the invisible mesh is the same whether I try and transfer a crew originally from the XR-2 or the Arrow into
the decompressed XR-2.
-
UCGO BUG
Bug with:
UMMU
Short description:
Square black block on the upper part of the screen (2D panel artifact?)
Severity
detail
Complete description
This small black square comes up at the top of my screen, in the middle, at times when I use a UMMU human outside of his/her suit.
See this picture:
http://www.tefal.free.fr/imgs/black-square-bug.jpg
Reproduce bug
This most probably needs large widescreen resolutions. I use 1920x1080 - then simply get out of a UMMU suit.
Miscellaneous[/u]
The square gets some kind of dull gray when I switch the focus away to some other program (from full-screen mode) then come back, which usually garbles 2D panels.
The bug might be hard to reproduce, as it only happened once. Interestingly, the square can be put away with an F8... as if to switch off the 2D panel.
Post Edited ( 01-12-10 23:27 )
-
UCGO BUG
Bug with:
UMMU
Short description:
RCS thrusters visible on humans (suitless UMMUs) when an autopilot is active
Severity
minor
Complete description
The RCS thrusters are normally not visible when a plain human - suitless UMMU - walks around. However, when an autopilot -
for example RCS KILLROT - is active, they suddenly appear.
Ergo, thrusters fired by autopilots are apparently visible on suitless UMMUs.
See http://www.tefal.free.fr/imgs/human-thrusters-bug.jpg
Reproduce bug
Get a UMMU out of his/her suit, activate KILLROT, try moving around and see the thrusters trying to prevent the movement.
Miscallenous
KILLROT stays permanently on if you activate it and move around on the ground. This seems to have the awful consequence that
if you leave it on, switch focus to something else in Windows then come back to Orbiter, the UMMU makes some kind of jump
proportional to the amount of time spent outside Orbiter. Usually kills it, I even managed to blast a UMMU to bits by filing
the previous bug report.
-
UCGO BUG
Bug with:
UMMU
Short description:
Autopilots stay on with a suitless UMMU on the ground, switching to another program makes the UMMU jump to its death
Severity
serious
Complete description
Autopilots, for example KILLROT, seem to stay permanently on if you activate it and move around on the ground with a suitless
UMMU. This seems to have the awful consequence that if you leave it on, switch focus to something else in Windows then come
back to Orbiter, the UMMU makes some kind of jump proportional to the amount of time spent outside Orbiter. Usually kills it,
I even managed to blast a UMMU to bits.
This does not happen without any autopilots on.
Reproduce bug
Using a UMMU outside of his/her suit, activate an autopilot then move around, which will make the autopilot stay on. Switch
focus to another program in Windows. Wait a bit. Come back to see your UMMU catapulted in the air and/or thrown to the ground
with force.
-
I got NOT get this work. Worked fine for me
Tefal wrote:
UCGO BUG
Bug with: Arrow freighter
Short description:
Clicking on the SEL buttons of the MFDs in the virtual cockpit causes crash
Severity
CTD
Complete description
Whenever I try to click on the MFD "SEL" buttons that normally show the MFD list, I get a CTD. This seems
to happen
independently from exactly what MFD is displayed, and happens in all circumstances. A good scenario to reproduce
this is the
Autoland test.
I tried to deactivate all supplementary MFD modules (transx, IMFD, aerobrake and the like) and
potentially-fishy-but-unrelated-modules (UMMUFA) and the bug persists.
Reproduce bug
Open the Autoland test scenario, click on one of the "SEL" buttons between PWR and MNU. Voilà! There's
a fat chance it's just
somehow due to my very dirty Orbiter install, however.
Miscallenous
I've seen CTDs during MFD display, but this is a new type of crash here...
-
Slight bit of nitpicking, too - I'm of the impatient kind and do everything ground-related and most docking-related tasks at
10x. Is there an option to set the time acceleration above which all cars get grounded? I'd sure like the possibility to set
this to 100x, at which everything really gets too fast to follow.
But don't get the wrong impression, the add-on really is as incredible as it looked in the screenshots. :)
-
UCGO BUG
Bug with:
Arrow freighter
Short description:
Screens and MFDs in the virtual cockpit get (and stay) garbled after a task switch to another program
Severity
minor
Complete description
You probably know this - switching to another program from Orbiter often mangles the 2D panels. Probably messes up the
drawing surfaces. This alas also happens to screens in the virtual cockpit of the arrow, and the usual solution for garbled
2D panels (put the panel away with F8 and reload) does not work.
Reproduce bug
Open any scenario with the Arrow, go in its virtual cockpit, switch to another task in windows. Come back, see the garbled
screens. Switch the VC off with F8 and back again, it's still in this state.
Miscallenous
Pausing before switching tasks, often a possible remedy to prevent garbling, also does not work.
Since I've seen that kind of bug pretty often (hum hum XR2), I wonder if it's easily fixable at all, apart from doing a
reinit of the cockpit screen's drawing surfaces/buffers when the VC gets displayed off and on again.
-
UCGO BUG
Bug with:
Arrow
Short description:
Change to AR02
Severity
CTD
Complete description
Start with the Station - Refuel at ISS scenario, after start up, try and move to AR02 using the F3 dialog
Orbiter stops with no message and no control, Had to Ctrl-Alt-Del to exit Orbiter
Reproduce bug
Start with the Station - Refuel at ISS scenario, after start up, try and move to AR02 using the F3 dialog
Miscellaneous
Was tested in my dirty install
-
Tefal a écrit:
UCGO BUG
Bug with:
Arrow freighter
Short description:
Screens and MFDs in the virtual cockpit get (and stay) garbled after a task switch to another program
It's probably more CG and driver related as it's not a problem that is reported often. (never heard about it)
Same as for the UMmu black square, this is a invisible panel trick that I use in UMmu since 3 years and nobody
reported it until now.
You don't use 16 bit screen do you ?
What OS, CG, directx ?
(Now it's possible with vista & win 7 maybe, seem there is some problem here with panels and texture restore)
Anyway I note those as cleared as I cannot do anything on my end.
Dan
Message modifié ( 13-01-2010 01:37 )
-
Tefal a écrit:
UCGO BUG
Bug with: Arrow freighter
Short description:
Clicking on the SEL buttons of the MFDs in the virtual cockpit causes crash
Severty
There is no reason in code for this one, the click is passed directly to Orbiter "SendMFDKey" function.
It *seem* to me that someone else had a MFD bug previously, I don't recall if he solved it by
installing on clean install (mean a 3rd party would be in cause) or by any other mean.
As no one reported it since many beta there is probably something specific to your computer.
(Os, drivers, Orbiter install ?)
Can you shake it a bit , disable all module included orbitersound, disable all 3rd MFD etc. etc.
Try with different MFD, left or right, circumstances etc ?
Also what version do you use exactly Os orbiter etc ?
Thanks
Dan
Message modifié ( 13-01-2010 01:36 )
-
A developer question if I may:
Is it possible to create mobile crane trucks such as these: http://en.wikipedia.org/wiki/Crane_%28machine%29#Mobile
One of these is used to lift items on/off the Mobile Launcher Platform(MLP) in preparation for launch or
roll(rollout/rollback) operations.
-
DaveS a écrit:
A developer question if I may:
Is it possible to create mobile crane trucks such as these: http://en.wikipedia.org/wiki/Crane_%28machine%29#Mobile
One of these is used to lift items on/off the Mobile Launcher Platform(MLP) in preparation for launch or
roll(rollout/rollback) operations.
Yes (appart if the body is articulated) 6 wheel (3 axle) are supported you can even animate the "crane" but you'd not be able
to lift anything with it. The reason is that an "universal" crane system would be too complicated to adapt to the very
different kind of crane possible. IE: config might become so complicated that it would be more simpler to do it directly in C++)
Hope this answer ?
Dan
-
Dambuster a écrit:
UCGO BUG
Bug with:
Arrow/UMMU/XR-2
Short description:
EVA transfer oddities
Severity
minor
-Can you try with another name than UCGO_-_XR2 ?
-Can you try to reproduce this bug with the DGIV-2 ?
Thanks
Dan
-
tl8roy a écrit:
UCGO BUG
Bug with:
Arrow
Short description:
Change to AR02
Severity
CTD
Can you try with all modules disabled please ?
Dan
-
DanSteph wrote:
DaveS a écrit:
A developer question if I may:
Is it possible to create mobile crane trucks such as these: http://en.wikipedia.org/wiki/Crane_%28machine%29#Mobile
One of these is used to lift items on/off the Mobile Launcher Platform(MLP) in preparation for launch or
roll(rollout/rollback) operations.
Yes (appart if the body is articulated) 6 wheel (3 axle) are supported you can even animate the "crane" but you'd
not be able
to lift anything with it. The reason is that an "universal" crane system would be too complicated to adapt to the very
different kind of crane possible. IE: config might become so complicated that it would be more simpler to do it directly in C++)
Hope this answer ?
Dan
Yes, it answers the question, thanks!
-
UCGO BUG
Bug with:
All UCGO Vessels capable of loading cargo
Not sure if its a bug or just a weight per cargo limitation
Short description:
Any cargo container over 10000 kg won't load onto Arrow or forklift
Severity
Minor (I suspect there is a weight limitation in the DLL of the module)
Complete description
I made a UCGO cargo container that upon UMMU unpack, spawns a DGIV. I set the container mass at 23000 kg in the
config file to represent a DGIV with full tanks. Everything worked fine until I tried loading it into the arrow via the
browse and add cargo on the cargo MFD of the arrow. First of all, when I browsed to the cargo I made on the arrow
MFD, the arrow cargo mfd showed a weight for the container at 10000kg. Although the container was configured to
weigh 23000 kg. I tried loading it onto the arrow, but the MFD said that the ship was full, even though I had
emptied all the cargo before trying to load the DGIV in a box. I then tried to load it onto the forklift and it would not
load because the Hud on the forklift stated the forklift was full.. I also tried to load it onto the DGIV, but the load
manager also said the ship was full and it wouldn't load.
Reproduce bug
Change the config file for any UCGO cargo container to anything over 10000kg and try loading it onto the arrow or
any other vessles.
Miscallenous
I read the UCGO SDK and looked at the functions and found one that sets the max weight an UCGO vessel can carry.
The SDK says that the default max weight is 1,000,000 kg or 1000 metric tons for all the cargo on the vessel. But I
could not find a function that sets the max weight of a single UCGO cargo per vessel.
I'm not sure if the arrow has a maximum cargo load of 10000 kg as set by the module, or if there is a maximum
weight per cargo coded into the SDK or if this is a bug...
-
There is no reason in code for this one, the click is passed directly to Orbiter "SendMFDKey" function.
It *seem* to me that someone else had a MFD bug previously, I don't recall if he solved it by
installing on clean install (mean a 3rd party would be in cause) or by any other mean.
As no one reported it since many beta there is probably something specific to your computer.
(Os, drivers, Orbiter install ?)
Can you shake it a bit , disable all module included orbitersound, disable all 3rd MFD etc. etc.
Try with different MFD, left or right, circumstances etc ?
Also what version do you use exactly Os orbiter etc ?
Thanks
Dan
Windows XP SP3, usually-flaky recent nvidia drivers on a GTX275, old Orbiter 2006P1 install with every kind of weird stuff in it.
The bug happens with the left and right MFDs, also happens with all modules and external MFDs deactivated, in seemingly all
possible circumstances (landed, in flight, etc).
It's very probably my install.
-
No problem for me. Worked great
tl8roy wrote:
UCGO BUG
Bug with:
Arrow
Short description:
Change to AR02
Severity
CTD
Complete description
Start with the Station - Refuel at ISS scenario, after start up, try and move to AR02 using the F3 dialog
Orbiter stops with no message and no control, Had to Ctrl-Alt-Del to exit Orbiter
Reproduce bug
Start with the Station - Refuel at ISS scenario, after start up, try and move to AR02 using the F3 dialog
Miscellaneous
Was tested in my dirty install
-
UCGO BUG
Bug with:
Auto-unpack probe
Short description:
When deploying the probe on the ground, orbiter CTD's.
Severity
CTD
Complete description
Ok, I was on the moon with a auto-deploy probe, and accidently relesed my other probe from arrow whilst making a base, 15
seconds later, orbiter had a hissy fit and CTD'd.
Reproduce bug
Auto-deploy a probe on the ground after deploying from arrow.
Miscallenous
Wonderful addon alltogether, you overdid youself this time dan.
-
DanSteph wrote:
tl8roy a écrit:
UCGO BUG
Bug with:
Arrow
Short description:
Change to AR02
Severity
CTD
Can you try with all modules disabled please ?
Dan
Can confirm it could be a module, give me some time and I will find it.
Ok, I think it is Orbiter Sound
This is the first time this has happened in all the betas
Post Edited ( 01-13-10 13:34 )
-
Tefal a écrit:
The bug happens with the left and right MFDs, also happens with all modules and external MFDs deactivated, in seemingly all
possible circumstances (landed, in flight, etc).
It's very probably my install.
Can you post the orbiter log just after a CTD ?
maybe there is something into it (But I doubt, this look like some internal weird things)
Dan
-
Double post because I think the original got burried...
UCGO BUG
Bug with:
All UCGO Vessels capable of loading cargo
Not sure if its a bug or just a weight per cargo limitation
Short description:
Any cargo container over 10000 kg won't load onto Arrow or forklift
Severity
Minor (I suspect there is a weight limitation in the DLL of the module)
Complete description
I made a UCGO cargo container that upon UMMU unpack, spawns a DGIV. I set the container mass at 23000 kg in the
config file to represent a DGIV with full tanks. Everything worked fine until I tried loading it into the arrow via the
browse and add cargo on the cargo MFD of the arrow. First of all, when I browsed to the cargo I made on the arrow
MFD, the arrow cargo mfd showed a weight for the container at 10000kg. Although the container was configured to
weigh 23000 kg. I tried loading it onto the arrow, but the MFD said that the ship was full, even though I had
emptied all the cargo before trying to load the DGIV in a box. I then tried to load it onto the forklift and it would not
load because the Hud on the forklift stated the forklift was full.. I also tried to load it onto the DGIV, but the load
manager also said the ship was full and it wouldn't load.
Reproduce bug
Change the config file for any UCGO cargo container to anything over 10000kg and try loading it onto the arrow or
any other vessles.
Miscallenous
I read the UCGO SDK and looked at the functions and found one that sets the max weight an UCGO vessel can carry.
The SDK says that the default max weight is 1,000,000 kg or 1000 metric tons for all the cargo on the vessel. But I
could not find a function that sets the max weight of a single UCGO cargo per vessel.
I'm not sure if the arrow has a maximum cargo load of 10000 kg as set by the module, or if there is a maximum
weight per cargo coded into the SDK or if this is a bug...
-
DanSteph wrote:
Dambuster a écrit:
UCGO BUG
Bug with:
Arrow/UMMU/XR-2
Short description:
EVA transfer oddities
Severity
minor
-Can you try with another name than UCGO_-_XR2 ?
-Can you try to reproduce this bug with the DGIV-2 ?
Thanks
Dan
Ok...with the XR2: I managed to replicate it using the name 'XR2 - UCGO', however not with one called 'XR2', 'bXR2A'
or 'XR-2'. When I could recreate it, the name of the invisible UMMU changed depending on the name of the vessel I
was transferring it to. However, I noticed that when transferring UMMUs from the Arrow to the XR2 (this one was
creatively called 'XR2', Orbiter froze for a second or two each time I hit the 'transfer' button. One time when I pressed
it fast enough, I wound up with multiple invisible-mesh UMMUs, 'with the names following the same pattern as the
ones above (this time with the name 'XR2' in them).
Update: I just managed to make this happen with a vessel named 'XR2', however the XR2 in question was this time
decompressed, hypoxia'd, and emptied :)- this was during the same scenario as the one where I caused the invisible
UMMUs with Orbiter's freezing.
As for the DGIV-2, I was not able to recreate this as it wouldn't let me transfer crew back into a ship with a damaged
airlock :) (however I'm not convinced there isn't a way to do it with the DGIV-2, I'm afraid I don't have the time to look
for one right now though).
Post Edited ( 01-13-10 22:24 )
-
The SEL button bug did not surface again today. Strange.
-
Question. :wonder:
How does one change the Ummu mesh to female? I went through the docs and found nothing. If this info is being held back for
final release I understand. Just wanted to know because both end users and developers will want to know.
Thanks,
Chad
-
UCGO BUG
Bug with:
UMMU, UCGO Vehicles
Short description:
server bouncing of vessels while on ground and moving
Severity
Serious
Complete description
All Vessels such as cars, mmus , etc all bounce very severely with the slightest movement. it makes an unplayable experience
Reproduce bug
Set date to 2081
Miscallenous
not sure why this is happening but from what I heard it might be due to the formula of predictions of planet positions on orbiter
Post Edited ( 01-14-10 05:28 )
-
jgrillo2002 a écrit:
Reproduce bug
Set date to 2081
Miscallenous
not sure why this is happening but from what I heard it might be due to the formula of predictions of planet positions on
orbiter
Yes, unfortunately this is an orbiter bug, this is why all scenario date are at 2001
which is near the "ref" date I think.
I submited this bug to martin but I'm not sure it will be cleared for 2010:
http://www.orbiter-forum.com/project.php?issueid=200
Dan
-
cinder1992 a écrit:
Complete description
Ok, I was on the moon with a auto-deploy probe, and accidently relesed my other probe from arrow whilst making a base, 15
seconds later, orbiter had a hissy fit and CTD'd.
Unable to reproduce. Can you reproduce it and tell me how you do exactly and
post the scenario ?
thanks
Dan
-
alright, just let me attempt to re-create it. the scenario was sort of lost in the blue.
-
UCGO BUG
Bug with:
Cars
Short description:
Cars stuck when time acceleration on
Severity
Change request (pretty please? :D)
Complete description
Cars freeze when the time factor is set to higher than 1x. While understandable, it'd be nice if they would still be able to
run at 10x to speed up loading, unloading, refueling and transportation over medium/large distances (think Ascension Island)...
Of course, there might be a very good reason why you locked them at anything higher than 1x...
Miscellaneous
Sorry Dan, I know this must sound like I'm ungrateful, but if you're going to release the thing and dive into FSP thereafter,
I'd better try to get my not-so-humble wish fulfilled before that. Otherwise I will really have to disassemble the DLL and
modify the check in assembly ;)
-
Tefal a écrit:
Short description:
Cars stuck when time acceleration on
Sorry Cars acceleration might cause all sort of problem and is not in my view of "realism"
acceleration might be good for vessel while trips are very long but for cars it would just
look as a funny cartoon.
Last I can spend the next 2 month trying to fulfill all user's view of "cool"
changes or features but I'm really out of time yet. ;)
Appart criticals bug I'll release the things as it is.
Dan
Message modifié ( 14-01-2010 11:34 )
-
DanSteph wrote:
Sorry Cars acceleration might cause all sort of problem and is not in my view of "realism"
acceleration might be good for vessel while trips are very long but for cars it would just
look as a funny cartoon.
Last I can spend the next 2 month trying to fulfill all user's view of "cool"
change or feature as I'm really out of time yet.
Appart criticals bug I'll release the things as it is.
Dan
No problem - it's your add-on after all, you decide. Well, I tried. :siffle:
-
I think on his you have to select the mesh. There is not a male & female mesh for each suit. I suppose one could make one
and just name the mesh Fsceintist,...
The female non suit meshs are UMmuSCIX02X & UMmuTECHX02X.
anemazoso wrote:
Question. :wonder:
How does one change the Ummu mesh to female? I went through the docs and found nothing. If this info is being held back for
final release I understand. Just wanted to know because both end users and developers will want to know.
Thanks,
Chad
Post Edited ( 01-14-10 15:14 )
-
I was just thinking about what I posted earlier about the UMMUs, and when transferring UMMUs between the Arrow and
other vehicles I noticed that in the menu you use to change vessel focus (F3), when you transfer a UMMU you see a
name pop up in the list for a split second, and then vanish. Is it possible that the bug I reported is just this UMMU in the
process of transferring getting stuck?
-
Hey Dan What Cars and Cargos are in The Full Version Include?
and can you make Flashlight on The Ummu it's better when the Ummus are working at night??
-
Logifech wrote:
Hey Dan What Cars and Cargos are in The Full Version Include?
and can you make Flashlight on The Ummu it's better when the Ummus are working at night??
AFAIK, lighting from a source other than the Sun is not supported by Orbiter yet, although it has been implemented as some
kind of demo hack before...
-
gattico wrote:
I think on his you have to select the mesh. There is not a male & female mesh for each suit. I suppose one could make one
and just name the mesh Fsceintist,...
The female non suit meshs are UMmuSCIX02X & UMmuTECHX02X.
anemazoso wrote:
Question. :wonder:
How does one change the Ummu mesh to female? I went through the docs and found nothing. If this info is being held back for
final release I understand. Just wanted to know because both end users and developers will want to know.
Thanks,
Chad
Sex Change Operation! :lol:
You can also create your own meshes ;)
-
gattico wrote:
I think on his you have to select the mesh. There is not a male & female mesh for each suit. I suppose one could make one
and just name the mesh Fsceintist,...
The female non suit meshs are UMmuSCIX02X & UMmuTECHX02X.
Thank you sir. That worked :)
-
DanSteph wrote:
jgrillo2002 a écrit:
Reproduce bug
Set date to 2081
Miscallenous
not sure why this is happening but from what I heard it might be due to the formula of predictions of planet positions on
orbiter
Yes, unfortunately this is an orbiter bug, this is why all scenario date are at 2001
which is near the "ref" date I think.
I submited this bug to martin but I'm not sure it will be cleared for 2010:
http://www.orbiter-forum.com/project.php?issueid=200
Dan
Just read it. ant its a pain in the ass to always use 2001 as a fix. I really hope martin makes a fix for this
version along with the 2010 version
-
----------------------------------------------------------------------
COPY ALL TEXT BELOW, REPLACE "()" BY YOUR TEXT AND POST IN BETA THREAD
----------------------------------------------------------------------
UCGO BUG
Bug with:
Waypoint Editor and at the guide for Waypoint Editor
Short description:
(http://img.photobucket.com/albums/v50/zgrillo2004/bug-1.jpg)
This should be "AI"
(http://img.photobucket.com/albums/v50/zgrillo2004/bug2.jpg)
This should be "AI to test"
Severity
typo
Complete description
Some typos that need to be fixed
Reproduce bug
Go to waypoint editor and help of the waypoint editor
Miscallenous
I would suggest others to look around for typos
-
HI Dan
First i would like to say Thanks for the Great New System.This will Change Orbiter At least as much As Vinka's Spacecraft 3
does.Your Effort is Really appreciated.....I only have one problem and that is the same one that vonneuman stated in post
number 1208 on the Orbit-Hanger Forum .I also find the control setup VERY akward and difficult with the steering and
acceleration keys seperated.I am sure that many people like me grew up in the gaming world using the mouse and
keyboard for control and are accustomed to using one hand for movement and the other for looking around with the
mouse.Having to use both hands on the keyboard to drive does not allow for using the mouse to look around while driving
and takes away from a lot of the immersion of the experience.Especially for later when there will hopefully be many more
buildings and roads to look as other people start building worlds and cities of their own.Would it be very difficult to just add
the accleration and brake keys to the keypad 8 and 2 as well as the arrow keys for control.this would give many people a
much more enjoyable and natural feeling driving experience and would leave the other hand free for other controls or the
mouse.Thank you for your patience and all your efforts so far and i hope all is well both with you and your family for the
coming year.
Thanks again
TonyZ2525
-
Well, you have a point with "gamer" but mine is as follow:
Real gamer have a joystick usually and controlling cars with I/O keypress
is missing all the smoothness of a progressive control. ;)
Using joystick you can brake/turn/accelerate with much more progressiveness
and you'd still one hand free for mouse.
I would agree to change controls howewer but yet it's too late.
Every change in code this late is dangerous I may introduce odd bug/miss a doc
update or file while repacking and last and not least I'm sure everyone have at least
2-3 things that he would like to be changed in UCGO. So if I put my finger
in "minor" change I will still be here the next two month and I can't do that,
my customers would hang me.
Thanks for posting anyway.
Dan
-
Tefal a écrit:
Short description:
RCS thrusters visible on humans (suitless UMMUs) when an autopilot is active
Mhhh... thanks for this report, howewer I'll leave as it is for several reason, some mentionned above.
Other being that if I disable thruster with flightsuit on base with low gravity humain might be uncontrollable.
(as you can't walk on ground)... so better not to add a bug to solve an annoyment.
Dan
-
Buzz313th a écrit:
Short description:
Any cargo container over 10000 kg won't load onto Arrow or forklift
As said in PM this is the upper limit, one can't put 10 ton in 1 meter cube.
If you really want to cheat with huge base packed in small cargo just
put a low weight. Result is the same and more vessel could carry it.
Dan
-
Logifech a écrit:
Hey Dan What Cars and Cargos are in The Full Version Include?
and can you make Flashlight on The Ummu it's better when the Ummus are working at night??
You have almost the full version already. ;)
Dan
-
jgrillo2002 a écrit:
Bug with:
Waypoint Editor and at the guide for Waypoint Editor
This should be "AI to test"
Severity
typo
Typo solved in doc but not in DLL , I preffer to not recompile when it's not stricly necessary.
Best
Dan
-
Also I think this is right. Anything can be packed no matter what the size.
I have been able to add in 1.5 if ummu id is "Tech" then use the tech mesh. Is it the same in 2.0.
// visual specs
BUG = AddMesh (oapiLoadMeshGlobal ("NASABUGGY1"));
SetMeshVisibilityMode (BUG, MESHVIS_ALWAYS);
BUG1 = AddMesh (oapiLoadMeshGlobal ("UmmuBug1"));
SetMeshVisibilityMode (BUG1, MESHVIS_NEVER);
BUG2 = AddMesh (oapiLoadMeshGlobal ("UmmuBug1P"));
SetMeshVisibilityMode (BUG2, MESHVIS_NEVER);
{
const char *pMiscID = Crew.GetCrewMiscIdBySlotNumber(0);
if (strcmp(pMiscID, "") == 0)
{
SetMeshVisibilityMode( BUG1, MESHVIS_ALWAYS );
}
else SetMeshVisibilityMode( BUG1, MESHVIS_NEVER ); // return: Empty string on error or MiscID
const char *p1MiscID = Crew.GetCrewMiscIdBySlotNumber(0);
if (strcmp(p1MiscID, "Capt") == 0)
{
SetMeshVisibilityMode( BUG2, MESHVIS_ALWAYS );
}
else SetMeshVisibilityMode( BUG2, MESHVIS_NEVER );
const char *p2MiscID = Crew.GetCrewMiscIdBySlotNumber(0)
-
DanSteph a écrit:
Buzz313th a écrit:
Short description:
Any cargo container over 10000 kg won't load onto Arrow or forklift
As said in PM this is the upper limit, one can't put 10 ton in 1 meter cube.
If you really want to cheat with huge base packed in small cargo just
put a low weight. Result is the same and more vessel could carry it.
Dan
that doesn't work if you want to transport more tons of fuel ;)
-
Fox-Terrier a écrit:
that doesn't work if you want to transport more tons of fuel ;)
At this level of cheating no need for cargo, simply bring the scenario editor ;)
Dan
-
DanSteph wrote:
Fox-Terrier a écrit:
that doesn't work if you want to transport more tons of fuel ;)
At this level of cheating no need for cargo, simply bring the scenario editor ;)
Dan
...And if you really wan fun, load a DGIV with some of those command modules and take off from Earth and make orbit. The
Autopilot goes into convulsions :sick: , you have to manually fly it, and depending on the engine type, you have a very high
pucker factor.
:eek:
-
I know you can set breathable area. Can you set them to be based off airlock and airlock doors? For example. A moon base
with a hanger. whne the door is closed breathable but when the door is open not breathable. You see the animation of the door
-
UCGO BUG
Bug with:
Ummu
Short description:
Orbiter freezes when entering vessels or cars by pressing E
Severity
CTD
Complete description
When I try to enter the freighter or any other car by pressing E the simulation freezes and I have to shut down orbiter via
task manager.
Reproduce bug
self created scenario, I used the dgIV, xr2, deepstar2.0, Wideawake International, Celestium2 (space station), Pegasus lander
Miscallenous
-
glider a écrit:
UCGO BUG
Bug with:
Ummu
Short description:
Orbiter freezes when entering vessels or cars by pressing E
Severity
CTD
Please use the patch utility located in Utiles folder.
-
DanSteph wrote:
glider a écrit:
UCGO BUG
Bug with:
Ummu
Short description:
Orbiter freezes when entering vessels or cars by pressing E
Severity
CTD
Please use the patch utility located in Utiles folder.
If you mean the UMMU patch from 1.5 to version 2, i have used the patch during the installation of UCGO. The error occures
only with UCGO crafts and only with self created scenarios (no problems with the standard UCGO scenarios) in my paticular
scenario there are only the XR2 and ISS as another UMMU vessel, any other vessel I use in this scenario doesn't have this
feature.
So in my opinion it's not a big problem and maybe the cause of the problem is on my side.
Post Edited ( 01-17-10 22:39 )
-
glider a écrit:
So in my opinion it's not a big problem and maybe the cause of the problem is on my side.
-It might be an hidden problem also, so please run again the patch utility and let me know if he did found something.
-Else try to disable all module and try again. (module tab)
-Post the Orbiter.log after the crash
Thanks
Dan
Message modifié ( 18-01-2010 02:26 )
-
Hello Dan,
-I've run the patch utility again with no result
-I disabled all modules with no result
Is there a maximum number of vessels and objects in a scenario that orbiter can handle. I ask because orbiter has no normal
CTD it just stops and does not react anymore the only way is to terminate with the task manager.
**** Orbiter.log
Build Sep 29 2006 [v.060929]
Devices enumerated: 6
Devices accepted: 5
==> RGB Emulation
==> Direct3D HAL
==> Direct3D T&L HAL
==> Direct3D HAL (NVIDIA GeForce GTS 250)
==> Direct3D T&L HAL (NVIDIA GeForce GTS 250)
Found 1 joystick(s)
Module AtlantisConfig.dll [API v.060425]
Module DGConfig.dll [API v.060425]
Module EnergyConfigurator.dll [API v.060425]
Module VistaBoost.dll [API v.060425]
VistaBoost 1.0: Warning: font smoothing already disabled; nothing to do.
Module VesselStack.dll [API v.060425]
Module vel_hud.dll [API v.060425]
Module TrackIR.dll [API v.060425]
TrackIR module found: C:\Program Files (x86)\NaturalPoint\TrackIR4\
TrackIR initialisation failed
Module ScnEditor.dll [API v.060425]
Module Rcontrol.dll [API v.050206]
Module orbSpotLight.dll [API v.060425]
Module OrbiterSound.dll [API v.060425]
Module NoseWheelTurn.dll [API v.060425]
Module LunarTransferMFD.dll [API v.060425]
Module LTV-MFD.dll [API v.060425]
Module LaunchMFD.dll [API v.060425]
Module InterMFD53.dll [API v.060425]
Module GPCMFD.dll [API v.060425]
Module Glideslope.dll [API v.060425]
Module Framerate.dll [API v.050206]
Module FlightData.dll [API v.050206]
Module ExtMFD.dll [API v.060425]
Module CustomMFD.dll [API v.060425]
Module CRT.dll [API v.060425]
Module CameraMFD.dll [API v.060425]
Module BaseSyncMFD.dll [API v.060425]
Module BaseLand.dll [API v.060425]
Module AutoHoverMFD.dll [API v.060425]
Module AutoFCS-STS.dll [API v.050206]
Module AutoFCS.dll [API v.050206]
Module AeroBrakeMFD.dll [API v.060425]
**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Zbuffer: 32 bit
Render device: Fullscreen 1280 x 1024
Device has hardware T&L capability
Joystick throttle: Z-AXIS
Joystick throttle control detected
Module Sun.dll [API v.050206]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll [API v.050206]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll [API v.050206]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll [API v.050206]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
BaseObject: Parse error
*** WARNING: Old-style texture contents file Earth_lmask.bin
Module Moon.dll [API v.041022]
ELP82: Precision 1e-005, Terms 116/829
BaseObject: Parse error
Module Mars.dll [API v.060425]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
BaseObject: Parse error
Module Phobos.dll [API v.060425]
Module Deimos.dll [API v.060425]
Module Galsat.dll [API v.041022]
Module Jupiter.dll [API v.050206]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll [API v.041022]
Module Europa.dll [API v.041022]
Module Ganymede.dll [API v.041022]
Module Callisto.dll [API v.041022]
Module Satsat.dll [API v.061227]
Module Saturn.dll [API v.060425]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Enceladus.dll [API v.050206]
SATSAT Enceladus: Terms 33
Module Tethys.dll [API v.050206]
SATSAT Tethys: Terms 101
Module Dione.dll [API v.050206]
SATSAT Dione: Terms 59
Module Rhea.dll [API v.050206]
SATSAT Rhea: Terms 68
Module Titan.dll [API v.050206]
SATSAT Titan: Terms 100
Module Hyperion.dll [API v.050206]
SATSAT Hyperion: Terms 595
Module Iapetus.dll [API v.050206]
SATSAT Iapetus: Terms 605
Module Uranus.dll [API v.050206]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll [API v.060425]
Module Ariel.dll [API v.060425]
Module Umbriel.dll [API v.060425]
Module Titania.dll [API v.060425]
Module Oberon.dll [API v.060425]
Module Neptune.dll [API v.050206]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Module Triton.dll [API v.060425]
Finished initialising world
Module Spacecraft3.dll [API v.050206]
Module XR2Ravenstar.dll [API v.060425]
Module PegasusAres.dll [API v.060425]
Module ShuttleA.dll [API v.060425]
Module ShuttleA_PL.dll [API v.060425]
Module Spacecraft2.dll [API v.050206]
Module ATV2.dll [API v.060425]
Module DeltaGliderIV.dll [API v.060425]
Module UCGOArrow.dll [API v.060425]
Module UCGOCars.dll [API v.060425]
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
**** WARNING: Mesh not found: .\Meshes\1999-Waste-v2.msh
-
No the limit bug was cleared. You can try with 20 DGIV.
Now this was not the only problem, somes vessels or other module scan the vessel list
and keep their handle and access them directly every n frame. As UMmu vessel is deleted
when you enter-> CTD.
This was the case for example with LolaMFD. (updated version exist)
Solution:
Try to disable one by one every third party vessel that are in your scenario until
CTD don't happen anymore.
I submited this "bug" to martin, the deletevessel function will always be a problem
as long as there will be programmer that access vessel by handle instead of name.
Much thanks
Dan
-
Dan- UCGO was released, but I found one last Beta Bug. When you turn the lights on on the truck, and then you cut the engine
off, the tail lights stay lit.
-
too late, one will have to live with this one during 8-18 month... ;)
Dan
-
DanSteph wrote:
too late, one will have to live with this one during 8-18 month... ;)
Dan
Se la ve! :drink:
-
typo bug found : " Station - Refuel at ISS or gaz station"
same error in the description "or fuel from landin g pad's gaz station.
and there is a space (en trop) between landin and g
-
Hi there,
sorry for the late reply but I hat a lot to work. I followed your adcice ans was able to locate the problem, it was the Total
Immersion version of the Pegasus Ares lander. I replaced the vessel and everything works fine now.
Greetings from Heidelberg
Thorsten