I' solved all these fatal errors.
VLD is a Visual Leaks Detector, I don't know how to use it, but downloading it and adding a path into Incudes wasn't very difficult. :lol: The ONLY fatal error I have not solved yet is the absence of IMS.rc .
Good to hear, but I did want to get a confirmation from Jedidia on that. It is always possible for him to have named his own file vld.h, which would have a function completely different from what you find on the web, so better to be sure.
Me too. I suggest us to find more realistic-looking modules like those from Piper's pack and compose a realistic pack from these. What do you think?
That would be great. I also have all of the station modules from the Orbiter Francophone site in my IMS folder. As many of them represent the individual components from the ISS, I was thinking it would be cool to create the ISS as an IMS vessel.
One minor note about the Piper package, that really cool Coms module I mentioned will only allow attachment & integration when its not docked. Must be a cfg error somewhere.
You could use small fuel tanks from SSBB41 as RCS tanks. What shape should the descent stage tank be?
Well, even just a mesh of the Apollo LM descent stage would be good, but you can try other designs too. (maybe mess around with some of the meshes in Mars For Less 1.6?) The issue with the current parts is that they A-dont look right on a lander, & B-dont fit functionally. The little tanks from SSBB 4.1 are too bulgy, & too small to be effective unless I stack 3 in a row. The big ones are just way too large to land with anyways. We really need parts that are flat & wide in order to make effective landers.
It was tested quite thorough, I don't really remember such behaviour :hmm: I'm planning to have a big testing run on this weekend, I'll test all the things we've been talking about lately then.
It could be a builders bug too :shifty:
The Audacities TEI window doesnt open up again for quite a while, so I'm starting work on a Jupiter vessel inspired by the Deepstar. Its not finished enough yet, but you'll get to see the Aquarius soon enough
Ok, back after 2 days of travelling and 2 days of ensuing sickness. Sorry for being a bottleneck.
Not at all :thumbup:. We think of you more as a funnel, or something...
Shame to hear you werent feeling well.
Big oops. Forgott that I had Visual Leak detector in there, you could just have taken it out, but it's a really nifty tool to have, so no loss. The resource file... was plainly forgotten. It doesn't really do much anymore. Will upload as soon as I get the chance.
As I said, a scenario editor derivative with IMS' needs in mind would fix that. You don't even need a direct connection to IMS, although some nice features could be implemented that way.
The basics I had in mind for such a thing are: easy creation of vessels, default starting page shows folder open, maybe with thumbnails, doubleclicking amodule creates module with some deffault name+index.
Creation of multiple modules by entering a number of modules of the same type to be spawned.
Copying of modules with same option.
Copying of stacks: You have a basic elements composed of several modules (trusses, tanks etc) that will show up several times in the construction. Spawn modules, dock stuff together, then copy entire stack. New modules will spawn docked the way the original was.
These things would be relatively easy to implement by some messing with the scenario editor source code.
Please make sure to include vld.h in the next upload. I want to double check that IMS.rc was actually missing though. I feel like my copy had it right where it was supposed to be.
My experience programming with the scenario editor is nil, so I'll leave that up to you, but Im not sure it should be our number one priority just yet. I find that the bigger problem in design usually ends up being how to track down exactly what the problem is, but thats just me.
No, you need a heat exchanger for that. Just physical contact is rather inefficient... However, that would be part of the radiator, not of the cooling module. The module would contain pumps, control system, pressure regulators and coolant storage.
Hmm, I do have a fairly good understanding of thermodynamics, but it has been a few months since I really used it.
I suppose what Im saying is:
Is the MCS intended to create a preferential heat gradient? In other words, I would assume that the whole point of lugging pumps & pipes & whatnot up to space would be so that we can send heat to where we really want it. That would seem to indicate that, in theory, if we had the mother of all MCS systems installed, we could keep shifting waste heat into one puny 64m2 920K radiator until it vaporizes. (and then there would be trouble :lol
If we have the ability to really move heat the way we want it, as quickly as we want it, we can just dump it into one little radiator until the thing is running at a molten 900K.
But that cant be right, can it?
An Ion engine is just your basic electric engine: decent ISP, abysmal thrust, uses electricity to run (quite a decent efficiency in terms of power usage nowadays). As such all its properties are covered by the electric engine type, as is the VASIMR. The reason why the cluster wasn't included in RC2 is that I never got around to texturing it...
Generally re propellant types: the density is not actually coded into IMS. You give the density automatically when calculating how much kg of propellant it can hold. The propellant types are merely hard-coded for managment reasons.
Texture that my man! I am finding our current stable of engines less than flexible for my maniacal plans...
Right, so the propellant types are more just for the display systems to show, and to ensure the right engines use the right fuels. Got it :thumbup:
It doesn't even support graphics clients yet...
Orbiter works fine on multiple monitors in windowed mode, by the way.
I told him it probably could be done with the Master/Slave utility, although it probably hasnt been tested with IMS yet. Not a bad idea if it works, though :hmm: All of those views!
How high is graphics client compatibility on your list of priorities? I havent been able to get 2d panels of any kind working yet, so I cant really help, but it may become more pressing in the future. Some people are unwilling to use almost anything that doesnt work inh D3D9.
That's no problem at all... Paint one side white, the other black, PROFIT!
It takes a bit more than that to minimize and maximize radiation of course, but it's not a problem. Lots of designes rely on one-sided radiators, but yes, I haven't gotten around to tackling this in IMS yet.
The major problem I could see with the Audacity is that her rear radiators would be blown right off by the surrounding engines :lol:
Actually theyre meant to retract during burns, but I got a bit lazy & left them open. Theyre high temp, meant to handle the waste heat from the NTRs (gas core I think?), but Im not sure that the engines waste heat is working, I dont get much of a cooling spike after burns at all.
She is an outstanding ship to fly, particularly because acceleration when fully loaded is 0.1 G. Not many IMS designs Ive seen so far can claim that much ease of use with such high capability ( ~14 KPS at least). At least not without cheating (yes the hyper engine counts as cheating :lol: )
The only issue was that damn consumeables storage I added along the bottom side 15 mins before TMI, when I realized the CG was way off. It keeps overheating & freezing, sending consumeable warning messages at me, even though I have regenerative supplies for all of my crew. Is there a way to stop those stupid warnings about consumeable depletion on the systems MFC?
That should be correct.
re: touchdown points. Yes, that shouldn't be too tough to implement (at least if they're static). Some things to consider:
Needs to handle the exception if the user adds more than three. Orbiter doesn't allow more than three, so if someone adds four, the program has to decide which ones to group together.
Not sure how touchdown points handle CoG shifting. Might need some manual shifting.
positions of touchdown points should be remembered absolute to the CM (as are the positions of docking ports, attachment points, exhausts, etc), meaning they have to be converted on integration. Look at the code for attachment points etc.
Ummm :uhh:, if a user adds three, I think the program will just ignore it, nobody needs more (not in this Orbiter version anyways)
Im sure a more complex solution can be put in later, but for now we're just going to have them defined manually in the scenario file.
Imagine my excitement when I found setclasscaps in the IMS source code :lol:! Jedidia really is mortal! I can edit this code!
