Tonnz

It's a bit more complicated than that. The pointe of ANNs is that it basically is the machine making decisions. Well, you could always argue that all processors work after a predefined set of rules, but it's the same with our brains ((bio-)physics). ANNs work similar to that. The only layer in which things are predefined is a very fundamental one. In our (biological) case it's biology and physics, in the case of artificial neural networks it's the basic neural model (how do signals travel? what do neurons do?) and the learning algorithm. Keep in mind that the development of ANNs started as an attempt at recreating biological neural networks. You only show an artificial neural network what to do. You actually train it ("train" is the correct scientific terminology). The network has to do the "learning" part 100% on its own. That is the point of artificial neural networks. And once it's ready, it will do and decide everything on its own, there is virtually nothing the programmer has created (except for maybe setting one or two paramaters, but that is not "creating"). That ANN may even react differently to exactly the same situation/input. Artificial neural networks sometimes (more or less usually) grow so large (depending on model) and complex that it is practically impossible to comprehend everything/anything that is happening inside them. You could say, they sometimes become their own territory. As an example: I've trained a neural network to do basic digit recognition. I have absolutely no idea how to program digit recognition. Not a single little idea. All i did was creating a model of ANNs, implementing it, initializing it, and telling it what to learn (of course also showing/training). At the end it could recognise digits, even those that were written in a way it had never seen before. It wasn't me doing this. I still have no idea how to programmatically do digit recognition. So is it the computer making actual decisions? To some extend, definitely. It's the Synapse project from IBM you are thinking about. They've made huge progress since then, i recommend you to check it out. Really interesting.

That makes alot sense, thanks Especially the part about "Calculating the distribution of this momentum sharing" convinced me , this would be equivalent to my thoughts about the relative momentum. Now that i think of it... the equation i came up with is exactly the same as the rocket equation, just with time-dependency. Replacing the "m1" in the rocket equation with m0-t*F/Ve, and extending* the resulting fraction (inside the ln(...)) with the velocity (m/v) gives exactly what i came up with. If i undo the last step, the resulting equation would also require less floating point operations to compute. :facepalm: It could've been so much easier. Without the nasty integration stuff. Thank you for your careful observation anyways *not sure if it is the correct term, i mean multiplying both numerator and denomination of the fraction with something.

I should have thought about that . I'm also going to try that one out. Thank you very much for your help so far. I'll get back if more questions/problems arise

So i'm trying to figure out the change in velocity of a rocket after a t-seconds burn. I came up with one working approach, and then figured out there may be another way. Both return almost the same results. ALMOST m - some mass, v(t) velocity change after t-seconds burn, Ve - exhaust velocity, mDot - fuel-mass used per second, m0 - total mass at t=0 F - force, a - acceleration The naive approach would be by a*t=v, where a is assumed to be constant. So this doesn't work obviously. I'd really like to use LATEX or something similar here, but i don't think this forum allows it. I started with F=m(t)*a(t). Note that nor m(t) or a(t) are constant. I rearranged it to be: a(t) = F/m(t) I replace m(t), knowing that m(t)=m0-mDot*t. mDot is the mass-loss per second, which is equal to = F/Ve. Ve is the exaust-velocity. So i end up with: a(t) = F / (m0-t*F/Ve) Now all i need to do to figure out how much the velocity has increased in t seconds is to calculate the integral (lower bound 0, upper t) of this function with regards to t. So: ∆v(t) = ∫a(t) dt (upper bound is t, lower bound is 0), which turns out to be (i wont bother typing the hole calculation out, will only lead to a mess without more tools to write proper equations): ∆v(t) = Ve*ln( (m0*Ve) / (m0*Ve - F*t) ), where ln is the natural logarithm. This is all fine and works, BUT: I thought "Why don't you just calculate the momentum the engine developes in t seconds and apply it to the craft?" Sure, why not? The "force" is just momentum per second for an engine. So, gain in momentum: F*t, change in velocity: F*t/(m0-t*F/Ve) . Looks much easier. I tried it out, difference is neglitible. Plottet both functions to compare, resulst are almost the same (but get bigger for large values of t). But for low values... difference is neglitible. (first approach returns larger values for positive values of t than the second approach) What do you guys think? I think the problem with the second approach is that it doesn't take into account that momentum is transferred gradually, which actually is the case, but how is this a problem? I'm almost certain it is because momentum is, like velocity, relative. Which would mean that from an inertial frame where the observer is in the middle and rests, the exhaust gasses blown out earlier have a higher momentum than those which where blown out later. It would be the other way round for the rocket, resulting in a higher change in velocity compared to the second approach (which is actually the case). Any thoughts or ideas, or found an error? Anything will be welcome!

Thank you, now i get it. I was thinking about positions rather than directions. One further question: Are the y/z cord. swapped for all Transforms? Because this would give me a nice explanation for the problem i just ran into (my craft got dragged towards the planet i'm orbiting, very subtle effect, but enough to drag me inside the atmosphere from LKO). I use an integration approach for calculating the distance a craft has travelled while on-rails warp (only accounting for the distance the running engines added). I use the thrustTransforms Transform from the ModuleEngines to determine the direction in which the engine fires, i base my calculation on this, and swap y/z when updating my orbit with it. If it was already swapped to begin with, it would mess everything up. I think it's time for me to use ArrowPointer ​and see what is going on. The velocity-change works fine though, and is also swapped. I'll have to take a closer look.

Thanks for helping! Well, i'm confused a little: You say that y is up for a rocket on the launchpad. How does z (forward) become "down"? Wouldn't "down" be just the negative values for Y? I'm confused. Are we talking about actual coordinates or pre-set directions, where z would return a vector that is "forward" relative to the rocket? I'm going to have a closer look at the ArrowPointer class. Will it actually draw the direction in-game? I'll have to try it out, would really be useful

Oh, forget about my first question. I found out that you can use the Object Browser of Visual Studio to find out more information about this kind of stuff. I used notepad++ to create, and the inbuilt windows command-line tool to compile .cs files EDIT: Figured the Alternator thing out!

Hello, i am searching for some info about the ModuleAlternator module in KSP. I couldn't find anything useful in the public KSP API Documentation, or somewhere else through google. Specifically, i need to find a way to get the resource consumption/creation rate (and of course what ressource it is) of the ModuleAlternator. That's my main question, anything below this is optional. Some background info: Why? I am attempting to write my first mod, it is also my first attempt at creating something C# related on my own. It would be a mod that enables timewarp while some engines (electric engines for example) are still running. Unfortunately there aren't any still around that work. I tried to fix one of them on/for my own, and partially succeeded; but there is one bug (found in all related mods) that i could not fix, but i think i have an idea*(see below). It's the issue where a craft "pulls" it apoapsis around and cannot really pass it, no matter how low the acceleration is, messing the orbit up (basically rotating the orbit in it's plane). So, i thought i should try to roll out my own mod. Why do i need ModuleAlternator? Because some engines use it (especially NF-electric engines in Realism Overhaul), and it would be a shame if they didn't work in timewarp (while the engine is running). I hope somebody knows more about ModuleAlternator, otherwise i would have to create another module only for this and use ModuleManager to set it to the ModuleAlternator-parameters for every part. That would be easy, but i don't like this approach at all. A little too intrusive and unelegant, knowing how ModuleAlternator works and how to communicate with it would be much better. * All timewarp-engines-mods i have seen that also have this issue (all, basically) use the orbit.UpdateFromStateVectors(...) method to update the orbit. I narrowed the issue down to this method. I would try to use myOrbit.UpdateFromOrbitAtUT (Orbit orbit, double UT, CelestialBody toBody) method instead, creating another Orbit-class that has the correct parameters. Well, i would need to figure out some orbital physics/mathematics, but that is a minor issue. Google will help me out at finding the needed equations My two other questions: While i'm at it, i have two other little questions: I found out (the hard way) that the Orbit class needs the y and z coordinates of vectors swapped, is it correct that this is the only class that does this? And concerning orbital mechanics, what is meant by "epoch" in "mean anomaly at epoch" in ksp? Wiki says "The value M0 denotes the mean anomaly at epoch, which is the mean anomaly at the time the measurement was taken" when was "the measurement taken" in ksp? Is it at universalTime = 0 ? I hope somebody can help! Any opinion or hint (also not directly related to the questions) is very welcome! Please note that this is my first attempt at programming mods for ksp, also my first real attempt at c#. My only experience at this is from looking at source files and manipulating existing mods to fit my needs

The paths for the NearFutureTechnologies reactors are outdated and do not work anymore. The reactors didn't show up in the VAB, i thought they were temporarily removed from RO, to be sure i had a look in the MM-files. The paths of the reactor-parts (+ RTGs) and their models has changed from: model = NearFutureElectrical/Parts/Nuclear/reactor-0625/reactor-0625 to: model = NearFutureElectrical/Parts/FissionReactors/reactor-0625/reactor-0625 I've also tried NanoExplorers IonWarp (suggestion from Felger), unfortunately there was a bug with the fuel consumption (off by a huge factor, depletes fuel instantly). I made a fix for me and also completely revised the velocity-change calculation (integral-approach, unnecessary, but i was bored). Works, i'll try to contact NanoExplorer about this tomorrow.

I've just finished my RO install (manual, no CKAN), and i notice two minor problems: I do have an additional part-"folder" in the VAB/SPH with all the "Non-RO" parts in it, but for some reason they all show up in the fuel-tanks section aswell. (I should probably post the following in the RSS thread instead...) From the last (pre-Kopernicus) version of RO/real solar system i am used to be able to switch launch sites. Is this function gone? Maybe i just haven't figured out how to do it, yet. EDIT: For some reason many parts end up in the wrong section. The AJE engines (amongst many others) are in the Electric Storage section for me, as an example. I'll just remove Filter Extensions for now. Hopefully it doesn't cause any issues.

That surely sounds interesting and of course useful. I'll keep track of that, thank you for the hint! I was planning to try using PersistentRotation (also provides a simple on-rails autopilot) together with IonWarp. This should be useful, especially when attempting to use electric engines in LEO, i hope those two mods work fine together. Unfortunately i don't have much time (to build up a RO intall and actually play it) until sunday. This should be a great opportunity to try out CKAN, hopefully it saves me some time. Or maybe it wastes time because i don't use it properly

Thank you very much! I've always had much fun messing around with electric engines in RO, so i was really worried. I'll be building up a RO install tomorrow or so (a bit busy lately), i think i'm also going to try out Principia. Seeing how much effort eggrobin & co put into Principia, "working pretty well" sounds very good.

Congratulations on the 1.0 release! But i have a little question/concern: How do we now use ion engines, or anything Near Future Propulsion delivers, now that Orbit Manipulator is completely outdated and got removed from the recommendations? There have been a few update requests on the Orbit Manipulator thread already, but it looks pretty much dead. Will there be alternatives? Or will low-thrust engines have scaled-up thrust for now? If i'm not mistaken, there had been plans to maybe implement warpable engines in the Principia project from Eggrobin (once it's ready). I'll be staying tuned!

I just wanted to let you know that the mm-config files for SSE tanks in the Modular Fuel Tanks mod do not work. They use the "cryogenic" tanktype, which does not exist anymore. I've also posted it in the mft thread, but i was told it would be better to post it here aswell. I used the following mm-config as a quick fix: [COLOR=#333333]@PART[km-*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer]][/COLOR]{ MODULE { name = ModuleFuelTanks volume = #$../RESOURCE[Oxidizer]/amount$ @volume += #$../RESOURCE[LiquidFuel]/amount$ type = Balloon } [COLOR=#333333]}[/COLOR]

Ok thanks, you're right i should post it in the SSE thread I've suspected that it would be better to post it there, but since the cfg was in this mod i decided to post it here. Yes, Default would be better, i deliberately used type = Balloon because... ehm... it's very lightweight (and a bit cheaty)