kcs123

Pre-Release version available only on github for manual download works in 1.7.2. Not any major issues. Some part have mirror symmetry bug placement in SPH, but that can be workarounded if you plan your craft carefuly. Some legs might have higher default settings for spring/dumper on suspensions, but those can be easy adjusted. Regarding textures, I have only encountered with minor issue on some part icons in SPH/VAB. Just handful of stock parts and moded parts have missing textures on icons while part itself have proper textures on craft. I can live with those issues just fine when you look at other benefits that whole mode provide. Can't tell for someone else if mentioned are such big issues that require uninstall of mod or not.

Can happen to anyone. Veterans included, wanted to admit that or not. Sitting in front of screen for too long, woeking on patches with sleep deprivation, tired, etc. Plenty of possible reasons. Our own brains fools us way too often. That is why it is good practice to give your own work to someone else, to look at it and inspect for errors. Whatever intelectual work it is, coding, working on some art, writting a book or anything similar.

Are you using engine mount plates from Making History ? There was several reports that those plates cause issue even without KJR. It may be possible that due to autostruting on engine plates KJR not work as expected.

I don't think that kOS is small-audience mod at all. Quite a lot of people from different branches are atracted by KSP. Quite a lot of them are already software develepers, some want to be and kOS can help a lot with better understanding and some are with proffesions closely related with programming. Maybe not loud audience of KSP player, but definetly important one. It is also understandable that SQUAD can't please everyone, but making things modable is good thing to go. Unfortunately, seems that SQUAD care less about moding community in last few releases than it was in past. This is first sign of noticing such things, hopefully it will be improved and not left ignored.

Stock game use option in difficulty settings menu, to set additional ground stations or not. I can't tell anything about RO, if theys have removed this from stock game menu or something else is involved.

Maybe to use more general option, "track target" instead of just Sun ? Each movable part could have one of two options enabled. Track target Yaw and Track target Pitch. In such case, target can be anything, other ship or planet. Can be useful for landing legs to track exact center of celestial body you want to land, for example. BD Armory fans might find it useful as well. My 2 cents on topic, since you already mention it here. Not super urgent request for such feature.

I think that you should be fine as long as you don't have any such craft in flight in your saved game. If you have some craft files saved, I recommend that you re-create those crafts after you apply patch, just to be safe that parts does not contain any duplicated tweakscale configs. Meaning, you need to grab each possible culprit part from craft, delete it and grab new part from SPH/VAB palette. Most safe aproach should be to create new crafts from scratch.

I will just left this here:

Not too bad, considering it supposed to be wings for spacecrafts, with ability to sustain high temperatures on re-entry and in flight over 2 machs. I almost exlusevly use FAR, so it is possible to reduce weight with wing strength/weight ratio that FAR provide. However, yes, if you want to use them for subsonic crafts, those weight too much. I was considering to create another B9PW parts that would weight less but without high temperature capacity. I tis possible to do that with MM patches, but for public usage it would require some new texture style. I have no skill to change textures in apropriate way for game usage.

Yes, those are issues with this wing types. That was reason why I have eventualy switched to B9 variants. Though, using sliders on B9PW can be clumsy to use sometimes as well, I found those that are easier to use for find tuning exact shape and attachment of control surfaces on main wing. Maybe to look in B9PW code what method is used to "snap" control surfaces on main wing to match exact proper angle ?

Link is in OP, but I will copy it here as well, to save you jumping from page to page: https://github.com/meirumeiru/InfernalRobotics/releases

I don't think that is changed much with KAX model transforms, but it use firespitter plugin for those and there was several changes in firespitter plugin regarding this.

Use pre-release IR Next. With those you can use stock sequencer/controler. It is available on github, but not trough CKAN yet.

Yep, I think that you are on right track. However, Shannon-Hartley theorem describe theoretical (in ideal case) limits. In practice it is hardly achievable.For game usage, you may want to calculate theoretical limit and lower it down to aproximate ~70% of ideal best scenario. For game usage, you might want to use some aproximation, some kind of your own function to increase noise over distance (or decrease S/N ratio with distance). Maybe to use something like A * (1/X) to calculate S/N ratio for in game usage. Where X is distance and "A" is some factor that would make final S/N suitable for in game usage. With low S/N ratio, overall transmition will take longer with same electricity usage per second, but you can safely assume that FEC is provided enough protective bits, so at the end of transmission you will always get proper data. Once such data is received it is reasonable to assume that relay could pass such data at higher rate if next antena pair in row is at closer distance and overall S/N ratio is higher for next antenna pair. So, next "leg" in transmission can be quicker. On the other hand, if next pair of antenna is at even higher distance than S/N can be even lower and overall transmission can take much longer time. My proposal for in game usage is to calculate MBit/sec from craft to first antenna in row, considering S/N between two, so you can take that for energy consuption for transmission to the first hop. But overall transmission does not end here. For each next antenna pairs down to Kerbin you need to also calculate S/N based on distance between two antenna and based on that only calculate additional time for transsmission. When some antenna pair have lower S/N, transmission time can be longer than it was on first hop. Oposite is valid too. That you can take as base for calculating overall signal delay. Because it is not only delayed due to limit of signal velocity in vacuum, but also how much of actual useful data you are able to transmit. I think that is reasonable start points that is for sure more realistic than stock system, but at the same time is not too complicated to calculate and should not take too much CPU time for in game usage.

That is ... impressive at least. Pictures ? And maybe comparison with and without KJRn ?

Slightly more complex topic other than that. Generaly speeking, modulation of signals is used for adjusting input signal for transfer over media that is used for transmission. Does not always need to be vacuum, although for RT and in game usage it is your main focus of interest. Media for transmiison can also be copper wire pair, coaxial cable, air(atmosphere), water (submarine comms), fiberglass, etc. For example, coaxial cable have much better properties than twisted copper pair wire when comes to influence of external noise. While it can be used for much higher frequency signals than twisted copper pair cable, at certain frequency threshold you get way too much energy loss due to inductance and capacitance (impedance) of cable itself. Necessary bandwith that is used for transfer strongly depends of what kind of input signlal you want to transmit. For example, for human speech it is enough mentioned 300 to 3400 Hz to be undersandable and distinctive transfered voice. For music bandwith is up to 20 kHz, (edge of human hearing frequency) and for television you need to add more, for monochrome and color picture (can't recall exact data from top of my head). Digital signal can be used on much lower frequency, not necessary starting with 1Ghz. For example, frequency for regular analog TV signal is 30 MHz to 300 MHz for VHF bandwith or 300 MHz up to 3GHz for UHF bandwith. In the past, UHF bandwith for TV was also analog signals. But, novadays it is converted to digital MPEG2 or MPEG4 digital signal first allowing to have much more broadcasting TV stations for the same bandwith usage. Main issue what kind of bandwith you will need for transmission of digital signal is original imput signal. For example, for proper sampling of analog music signal , you need at least double frequency of sampling rate of maximum frequency of input signal to be recognizable after AD conversion. On top of that you also need certain exact discret levels of amplitude for loudness of analog signal. You can find more on that topic on AD converters page. So, necessary "evil" of digital signal is that is never "smooth" as analog signal, but with enough discret levels and sampling rate it can be recognizable enough. This is not over yet. On top of that you also have compression of digital signals with acceptable loss. MP3, MPEG2, MPEG4, jpeg ... That might be more familiar things to you . But that might be way too broad topic for in game usage for RT. Your main focus should be frequency bandwith from 1Ghz and above. Should also assume FM or FSK modulation. Those are somehow minimal frequency that is good to "penetrate" atmosphere without significant signal loss and prograde to space trough vacuum. Next thing to emulate is S/N ratio in regards to traveled distance of signal. With more range it is more likely that some background noise from space would interefere transmited signal. For example solar flares from sun, or distant signals from pulsar stars etc. To overcome issue with noise, mentioned FEC is used. With more distance, more "protective" bits you need to detect and recover from errors in transmission. For example, let's say that in low orbit you don't need any FEC at all. You are capable to recognise all 8 bits of transmited data over some bandwith. You can transmit that for simplicity in example within 1 sec. Now, as distance become bigger and bigger, you start to picking up more and more noise, so you no longer can transmit whole 8 bits of data in one seconds. You may be able to transmit only 2 bits of useful data and additional 6 bits of FEC "protective" data. Therefore, while transmitter still send 8 bits per second, only 2 bits are useful, so your data rate become only 2bits per second. So, pretty much distance and S/N ratio dictate what transmission speed would be, rather than bandwith used. Bandwith width is useful only up to certain point, again, input signal dictate waht kind of bandwith you need and do you need it in realtime for retransmission (live picture) or you can wait and put everything together later on. Too wide bandwith may add too much in complicated hardware for transmiter and receiver than it is worh for. I hope that I have provided more useful data to you than adding more complicated noise into topic .

Can't help much with this. I can only guess from KJR continued changelog: --Fix a critical bug involving unphysical forces applied to vessels on load / unload of other vessels and SOI switches --Fix multijoints breaking IR joints and any other exempted parts from moving --If physics jolts cause a vessel with launch clamps to shift out of PRELAUNCH then put it back in PRELAUNCH. (and reset launch / MET timers) --Launch Clamps can now be set to completely rigid --KJR Continued v3.4.1 now also has basic support for robotic parts. It doesn't do anything to make the joints between them stronger but at least the robotic parts shouldn't get locked up either. I assume that RO was having some issues with Launch Clamps, I think that those are only pieces of code added after your fork from ferram. I have no idea what was issue with clamps in RO in the first place, though.

Hahaha, what is next after washing loundry ? Dishes ? Some kind of Goldberg machine ? Definately some crazy contraptions .

In RL, beside mentioned, major factor is also signal modulation. It is quite diferent if you use AM, FM or FSK modulation, for example. Low frequency signals, often use in military and still restricted to military usage can prograde to very long ranges, but data transmition rate is quite low. Some are restricted to still use morse codes because frequency bandwith is too low for voice transmission (300 Hz up to 3400Hz for phone usage, for example). Those are mostly only analog signals used today. Forgot to mention that low frequency signals bounce off from top of atmosphere and are not quite useful for space. So, if you plan to simulate analog signals and antenna, my recommendation, for game usage is to restrict those for ability to control craft but to exclude ability to transmit science data. Digital signals, on the other hand, use mostly higher frequency with some iteration of FSK modulation. FM and FSK have much better signal to noise ratios over AM modulation. Meaning if you have a lot of useless background noise in received signal, it is much easier to exclude those and still reproduce only wanted data. And it is not all yet. With additional message coding of analog signal itno binary digital signal, you can add FEC bits into message. Forward error correction allows you not to only detect errors in received message, but also ability to correct received message, so you don't need to send request for re-transmission of bad packet data. Downside of FEC is that less useful data is transmitted, so overall transmit takes much longer (slower speed). That is one of reasons why it takes weeks and even moths for deep space probes to transmit pictures and other data back to earth. So, there is a lot of room to have different antenna types in game, but still have to keep in mind that this is still only a game and some of real life things might not be suitable to simulate for game usage. Have to think to be "lightweight" on CPU usage, for example.

Most probable cause of issue you have already detected by yourself. Maybe to play around with angle on both, wingtip angle and on tail. Main issue with any replica attempt is that you can get a good look of craft, but you can't get exact mass distribution and mass amount with KSP parts. So, you might need to sway away slightly from real life craft in terms how it look, or you may need to alter part config files to get exact weight distribution as real life craft.

IIRC, I have seen some other complains about rotatrons elsewhere on forum. And it seems that issue between KJRn and stock robotic parts are only with rotatrons. Hinges, pistons and other parts seem to work fine. There are also complains with stock only game and rotatrons on certain crafts. Have you tried to use some other robotic part instead of rotatrons ?

I agree on the above and pretty much known already to me. My digression was more about how to detect faulty hardware, so you can get waranty if something is wrong while PC is still new, rather than performance. So, GPU benchmark utility is good enough to occupy most of VRAM and keep GPU busy most of time for testing when you are unable to watch screen all times. Prefered way is to play KSP or some other game, of course, but it is not always possible. At the end, if case and CPU's are not hot enough to fry eggs, it is passed quality control .

I always respect mod authors, it is their finall decision should some of proposed be adopted on the end or not. Instead of just complaining about something, I have also proposed solutions. Even if something is not adopted as proposed, it will be easier to do additional adjustments for the next update. I post all my findings here on forum because I'm "lazy" to create github account (have already too much account to handle, both, private and at work). Also, I don't know how much time I would have in future, to create some kind of UKS config extension or similar add-on mod and continue to maintain it. @SpinkAkron, take your time, private life commitments have always priority. Community will have to either, be patient for next update or learn how to create their own set of patches for personal needs.

That is nightmare for any developer, to create UI that is for everyone taste. If you hide everything out of user view and force some kind of default presets that were hardcoded either, directly in plugin or trough editing config files then you will end up soon with users complaining how that is impossible to fine tune some preset to their exact needs. On the other hand, if you overload UI with bunch of information at once, users are confused where to look for something that they need at given moment. At the end, some compromise have to be made between those two extremes. In my opinion, TCA is fairly good with it. Not perfect, and not for everyone, some effort to learn at least basics of UI have to be made, but reasonable good.

With very basic stuff. Thinking about beginers, I think that most of them fail to tag proprly engines in SPH/VAB. It may be already covered in older videos, but GUI have changed a lot since those are made (both, KSP and TCA), so It might be good idea to dedicate few minutes to that. What need to be set in SPH/VAB and how it works in flight. What should be covered next may be how to control simple VTOL in flight, followed by more advanced staff, like fly to navigation points, land on exact geographic long/lat. point etc. Each next advanced topic is equally important. Does not hurt to mention, what should be put in consideration in single engine (helicopter a like VTOLs) designs and multiengine VTOL designs (area where TCA work the best). Also differences in engine throttle responses (jets vs rocket engines and between various rocket engines). Not each engine respond to throttle change in same way, jets for examle are more noticable that need some time to achieve full thrust. Just few things that poped up on my mind.