ThermalShark

I was originally going to do the 1st before release, but it turned out too complicated so i scrapped it. I am going to take a look at your mod later, but before i will do the first three things on the list. Seems to be exactly what i need though. I am also trying to find a way to access the WheelCollider of a rover wheel, so i can make a telemetry mod. That would help a lot with the development of Rover Wheels when i start making a realistic engine simulation. But i may decide to not use the stock ModuleWheel, and instead use from another mod or create my own, as that would give me a lot more freedom. I still want to make the telemetry mod though.

The tweaking is from the TweakableWheels mod, made by OrbitusII, not me. And you can simply choose to not tweak it, as the default values are the same as for a stock wheel. Actually the need to pump fuel is not a problem to me, it is part of the challenge of building a car. What i said was that the engine always consumes a fixed amount of fuel as long as it turned on, no matter how fast you are going or if you are even driving at all, and that is definitely a problem.

Rover Engines mod v0.1 LiquidFuel engines for rovers, separated from wheels Rover Engines is a mod that adds LiquidFuel engines for rovers, independent of the wheels. On stock KSP, the top speed of a car is defined mainly by the torque curve, and the straight-line performance of a car is based only on the number of powered wheels compared to the mass of the car (see below). In real life, the acceleration of a car is defined mainly by the power-to-mass ratio, and the top speed is on the point in which the drag force and wheel force are equal. In stock KSP, the power of a car is defined by the number of powered wheels, and mass and drag are the same thing, so the mass of the car compared to number of wheels is the only thing that matters for acceleration, and for top speed, you will be limited only by the torque curve. Therefore, to win a racing challenge with stock KSP, you must make the lightest car possible with the maximal amount of powered wheels allowed, while trying to make the car very low, wide and short, to assist in cornering. (and RCS is not a major factor.) But with FAR, Tweakable Wheels and this mod, car engineering in KSP is a lot more fun, and is something that requires skill, like spaceplane engineering. Download v0.1(Dropbox) This mod comes with a modified version of TweakableWheels by OrbitusII. Install instructions are included in the download. Special thanks to: - OrbitusII, for allowing me to modify his mod. - Snjo, for his jerry can part from Firespitter. The engine part looks like an RTG, but much brighter. When turned on, it consumes LiquidFuel and produces a custom resource called EnginePower. There is also a copy of the black stock wheel that consumes EnginePower instead of ElectricCharge, and it has a different torque curve (much faster). The engines must be turned on/off either by right-clicking or action groups. Just making a powerful engine will not make your car faster, you need to use TweakableWheels to adjust the percentage of torque (and consumption) of each wheel. Each engine can produce exactly enough EnginePower to feed one wheel at 100%. The fuel is not automatically pumped to the engines, and you must do the pumping yourself if necessary. Keep in mind that fuel crossfeed never occurs through radial attachments, with the only exception being that an engine radially attached to a part can pump fuel from that part, if it has access to fuel. Here is an album showing what works and what does not: On the back is a RTG for color comparison. The jerry can is from Firespitter. Future Plans: - Support for M1 wheels (the yellow ones) - More fuel tanks - Better torque curve, based on real engines - Engines only working in an atmosphere with oxygen - Transmission - Ability to consume oxidiser (along with LiquidFuel), as 'Nitro' - Realistic (but simplified) engine simulation with RPM, (auto) clutch, etc - Engine Sounds, probably through this Feel free to suggest more! Known Issues: - When turned on, engines always consume a fixed amount of fuel, even when wheels are not being throttled. License: RoverEngines is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Never needed it, what i do are mostly rovers and planes, but it makes total sense that we should be able to extend antennas on EVA. After all, kerbals can tele-psychically instantly fix flat tires without tools...

I also think the best axis would be perpendicular to the orbital plane (assuming equatorial orbit), because that way the whole station gets equal sunlight. Some parts of the station getting more light than others is not good. This axis also ensures all windows gets an view to Earth, except those 'pointing' along the axis. And an axis intersecting the Sun will result in daylight cycles in which one day lasts an year...

The universe will be destroyed by then...

When squad said they have no plans for implementing this system, they didn't mean they planned to not implement it. This is one of those things that will with no doubt be eventually added to KSP, because a complete space program game simply cannot be complete without them. Imagine playing KSP, many years from now, and trying to make a colony in Eeloo, but being forced to send all supplies (other than ElectricCharge) from Kerbin, activity which wastes 98.2% of the money invested in the project. And all that with lots of water ice just below the base. This would be stupid, and the same as not having bases in career mode. So, obviously this will be implemented in KSP some day, and i hope this day to be in this year. Even if just water extracting, that would be great just on it's own. Mods would be made to use the water and oxygen for life support, and the system could be made so that mods can add more extractable resources.

When i said create/destroy resources, i meant adding or subtracting amounts of a resource to a existing PartResource. But just out of curiosity, can i do this:? private PartResource pr = new PartResource(); //(set up stuff like resourceName, maxAmount, etc) part.Resources.list.Add(pr) Thanks. RequestResource will return the amount of resource it has drained, right? My problem has been solved (for now), but if wanted to drain 30 LiquidFuel from a tank, without ever affecting other parts, i could not use RequestResource because if the tank only had 20 LF, i would drain 10 from other parts. In that case the only option would be to directly modify PartResource.amount, right? (maybe disabling crossfeed could not be an option, because i could need to transfer unrelated resources through the part, or if i needed fuel lines to not be able to pump from the part.)

I agree completely with the first sentence, but this does not means we should make it kethane-like in an attempt to keep it simple. We should place the system gradually, for example with a first update that does the following: - Renames LiquidFuel to Hydrogen and Oxidiser to Oxygen, but keeping them as just fuel. - Only water as an extractable resource, actually not "Water", but "Hydrogen"(1) and "Oxygen". Since there is no use for non-electrolyzed water, the extracting unit electrolyzes it automatically. - 3 extracting units: a drill, an air scoop(2) and a water scoop: - All may return different amounts of Hydrogen and Oxygen on different locations and situations. - They run on ElectricCharge. - Makes the LV-N run only on Hydrogen. Using tweakables, it runs on Oxygen, but less efficiently. The reason for this is that you may be in a location/situation where it is easier to collect Oxygen than Hydrogen. - Maybe: an monopropellant creator, which makes monopropellant from hydrogen and oxygen.(3) Now, who would not like an update like that? Well, i am sure most of the community would love this, and would want more. Imagine sending a capture mission to a huge asteroid, then collecting water from it to make the fuel you will use to move it! and maybe even monopropellant! Also look at this thread. Its creator sends fuel tanks all the way from Kerbin to the surface of Laythe(4), but he could set up a simple floating water collection platform, and have all the fuel produced right on the surface of Laythe. Note 1: I know it would be weird for jet engines to consume "Hydrogen", but making a separate "JetFuel" would not be worth it. Note 2: Air scoops should not be the same as air intakes, because air scoops need to consume electricity, and there are balancing reasons. For the same reasons, IntakeAir should be different from Oxygen. Note 3: Actually there is a monopropellant in real life that is made only from Hydrogen, Oxygen, and a bit of water. That's hydrogen peroxide, and Northstar mentioned it. Note 4: At least it was that way when i last read it... And i am not 100% sure if Brotoro is male. It actually is pretty simple unless you want to dive head-first into it. Remember that the KSP orbital mechanics are very complex, but not only this complexity is fun, but the starting player only needs it gradually, and has a lot of help from others. And saying that this will make KSP a whole new game is exaggerating; it would be just a major update like 0.18 was. Not "interesting/challenging for more skilled player"? Well, here are the main alternatives, which are much less interesting and challenging: - Spending a lot of time (and soon enough, MONEY) sending fuel from Kerbin to Laythe. - A kethane-like mod that has a single magical resource that is everywhere and does everything. (What i described used only "water", but that was meant to exemplify an initial update on ISRU.) Interesting and challenging is setting up a second KSC on Dres, or making an huge ship that goes to every celestial body and deploys landers and satellites on all of them, using ISRU to get water from asteroids to fuel the nuclear thermal rockets, then arriving on Jool and deploying hydrogen-collecting probes. Or an orbital construction outpost on the asteroid belt. (i know that goes beyond ISRU, but ISRU would be a major part in it.) And with a complex system like the one Northstar proposed, it would be a great engineering challenge, much more fun than if using a kethane-like system, and it would also make a great story to post on the forums.

I noticed this thread has only 2 votes. Ratings and reputation are things that get forgotten a lot in forums...

Don't worry about getting carried away! Everything you said so far is very interesting and inspiring, and i'm sure it will make many people realize the coolness of ISRU.

KSP has some pretty advanced orbital mechanics, and interplanetary transfers are extremely complex to a player sending their first mission to the Mun. But a new player don't need to know interplanetary transfers, they just need to know basic orbital mechanics and munar injection. They do need mastering rendezvous and knowing interplanetary transfers, but only much later in the game. That way, KSP can have advanced orbital mechanics, while still not being 'too advanced', as the player only needs to learn it gradually. The result is that the player learns physics, orbital mechanics and a bit of astronomy and rocket engineering, while doing something that they like. And that is without mentioning that said player will have lots of help: There are the in-game tutorials, YouTube tutorials, the wiki, the forum... With Northstar's idea of a complex chemical system, the same thing would happen. A player that has already landed unmanned rovers on Duna will be wanting to take a step forward, and decide it is time to launch a long duration manned mission to Duna, or set up a base on the Mun. For that, the player will only need to use the basics of the ISRU system, which is to use H2O to make H2 and O2, not only for fuel but also for life support. (And of course, the same player can also just get a huge lifter and assemble in orbit the 2-3 parts of the interplanetary ship, with all the fuel that will be needed.) When this player decide to take still another step forward, they will also get a lot of help, again from in-game tutorials, the wiki, YouTube and the forums, and they may also have a quick reference chart when planning the mission. On the other side, a very experienced player with ambitious plans to make a base Laythe that is not only self-sufficient but self-expandable, will need to use the most advanced of reactions and construction methods, which i don't even know, even though i know that are possible. In short, my point is that as long as it's implemented in a good way, there is no such thing as 'too complex', because games have the power to make anyone easily learn anything.

You should not make points based on parts, instead make it based on mass. Otherwise someone can get a lot of points from the "largest lander" by having lots of tiny parts in a tiny lander, for example. And the yellow "Space Station" text is very hard to read. Make it some other color.

I see that RequestResource returns a double or float. But what exactly RequestResource does? It pumps resources from other parts? Or drains from the part and returns what it drained so i can add it directly to the PartResource.amount of another part? Or it is used to create/destroy resources? And what i do with what it returns? Please explain me how i can do all these stuff: - Pump resources around - Create resources - Destroy resources

Now i need to know what is the best way to drain or add a resource. I want to drain only from a single part, without automatically pumping stuff from other parts. In the KSP API, here is what i found about the subject, all on the Part class: //FUNCTIONS: virtual bool DrainFuel (float amount) virtual bool RequestFuel (Part source.float amount, uint reqId) double RequestResource(int resourveID, double demand) float RequestResource(int resourveID, float demand) double RequestResource(string resourceName, double demand) float RequestResource(string resourceName, float demand) double TransferResource (int resourceID, double amount) But i believe all of the above, if they work, will pump fuel from other parts, so the only way might be using one of those: void GetConnectedResources (int resourceID,List<PartResource>resources) OR //this is a property: PartResourceList Resources [get] Then directly adding or subtracting the amount. But i have many of questions about these: Does the first even work? The API says it returns void, so i don't think it works. And what is with the resourceID argument? About the second: As Ippo said, it's type is PartResourceList, not List<PartResource>, but there is not a page about the PartResourceList type on the API. I think this means i can't do something like that: part.Resources[0] to refer to the first element in the list. Can someone confirm all these stuff?

I figured the resources out. I noticed GetConnectedResources() returns void, so i looked harder and found the property Part.Resources (i had not seen it before because i only looked at the functions and variables). But i still have questions: Is Part.Resources a list of PartResources? If yes, are the PartResources sorted in a certain way on the list? If i wanted to know the amount of ElectricCharge, would i need to loop through all PartResources seeing their names until i found the ElectricCharge? I still don't know what the dictionary stuff is, though.

What is this dictionary stuff at the beginning? Also another question: how do i know the resource information about a Part? I need to code a PartModule to know what/how much resources it can contain, the current amount of a certain resource, etc. GetConnectedResources() is what i am looking for? How do i use it? If you look at this API there is an int argument called resourceID. What it is used for? If i want to know how much of ElectricCharge a certain Part currently has, for example, what i would need to do?

How do i know the drain rate of a resource in a vessel? Preferably without taking into account the production rate. Also how do i know how much of a part there is on a vessel? I think there is a part list.

Actually, it would be better if we continued this after the forum reset, which will be after everyone's exams (probably).

I hope this isn't dead. I am going to make a truck if it isn't.

How would a spacecraft travel between 2 stars in a binary star system? With a normal hohmann transfer just like a planet and a moon?

Most arguments in this thread about the in-game praticality of interstellar travel can be fixed. (i know that's not what the OP wants, but it is what i want, in addition to having the option to start in a random procedural system). First, nobody is saying it should be released close to now. I hope this to be added after we get significant in-situ resource utilization. Without in-situ resource utilization, it is impossible to do anything more on another star than sending some probes to scan stuff. I also expect for KSP to have a much more advanced building system than sticking pre-defined parts together and changing some properties and resource quantities. And an economy. About the distance, Kerbol can be in a binary star system, and the other star would be the randomly procedural one. Even in real life, stars in a binary system are a lot closer to each other than your average distance between stars of several light-years. This, along with the scale reduction in the KSP universe, can make the stars close enough for slower than light travel. I know it will still take long, but there is no problem with that. You can launch a interstellar ship then do some missions on Jool, for example. Or just go to a super timewarp mode and reach there in 1 minute real life time. You would only rarely send interstellar ships, because the ships sent would extensively use in-situ resource utilization, and you would be able to build more ships when you get there, and reproduce more kerbals. Just one other star would be enough, because with updates a star can be very vast, when you have the freedom to make underground mining bases, a construction complex in a hollowed asteroid, and all that cool stuff. Right now all you have to do is explore the surfaces and move asteroids; and science as it is now doesn't count, as it is just getting to the place and pressing buttons so you can press more buttons on more distant places. In my view a interstellar project should be really big business. Something to do after you have a self-sustaining colony on Laythe, solar farms near Kerbol, and a asteroid mining program to fund the interstellar one. It should be something you spend a lot of time planning, something a person wanting to do it for the first time will want to ask for advice to experienced players. It should a week of real life time to complete the first stage of the program, which would be setting up the funding, building the orbital construction site that will build the interstellar ships, scanning the other system for locations, planning what they will do after they get there, etc. Of course, such a big thing will need to be released after the game is stable enough so updates may never break saves... Edit: Here is some real life data on stars: distance between... Alpha Centauri and us = 277600 AU Stars in Sirius binary system = between 8.2 AU and 31.5 AU, average 19.85 AU Stars in Procyon binary system = between 8.9 AU and 21 AU, average 14.95 AU Stars in Alpha Centauri binary system = between 11.2 AU and 35.6 AU, average 23.4 AU this means the distance between the Alpha Centauri stars is 13513 times smaller than the average distance between stars around this part of the galaxy. Stars in a binary system are A LOT closer than unrelated stars. Divide 23.4 by 10, to account for the fact that everything is 10% of the real size in KSP, and now it is too close instead of too far. 2,34 AU is 25,7 KAU

In microgravity, surface tension would make the puke wrap around your head and you would die. Taking off your helmet would be worse, because you would be instantly immobilized and going unconscious in 15 seconds, and if the depressurization is fast enough, your lungs will be ripped off and now you are inevitably dead, unless you have a machine that can put oxygen directly in your blood; in that case, you have a few minutes of life, and would probably not get unconscious anymore, so you would feel a lot of pain and suffer a lot.

Recycle them with Extraplanetary Launchpads. Put them all in a same graveyard orbit then send a recycler ship to turn them into raw materials to make a interplanetary ship.

You didn't watch the video in the link. You may have a point, but just look at how the fighter in the video moves in space, it's ridiculously stupid. Like, to move relative to the nearby space station, you ALWAYS have to keep your engines burning, and your speed in relative to the station is going to be constant, not accelerating. And there is a 'boost' that gives more power to the engines, and that will make your speed go up but then remain constant until the boost ends. Also, if you want to turn left, then you just point left and now your velocity vector is magically pointing forward, with absolutely no rightward movement. And if you turn off your engines while moving, you start to lose speed quickly until you stop.