woodywood245

I'm on KSP 1.4.3. I removed the mod after discovering that it was the source of problems in both manned and unmanned craft: Jittery keyboard controls (pitch, yaw, roll) No joystick input Docking Mode button disabled No linear RCS control

I'm having a similar problem, but in my case I can't get the kerbals of the ground-level hatch.

I'm keeping an eye on this one. I haven't downloaded it yet because I'm waiting for the delay feature. But whenever that gets worked out, it'll be one of the most important mods in my arsenal.

I've managed to kill her two times in a row, and the four times she's flown in my current save have resulted in complete and utter disasters. Each of the four times involved an abort, two of them killed her. All of them involve the same rocket that had been successfully flown multiple times. The first time she went up I had to abort because of a coolant leak (Dangit!), so I built another of the same rocket for the same mission, and I tried that second flight (three times, reverting to launch) and every time something new happened. I'm starting to think she's cursed.

I narrowed down the problem to Real Fuels, or some interaction between Real Fuels and Procedural Parts, and possibly another mod. However, removing both RF and PP worked.

From the way things are sounding, it sounds like other people are at least getting their games starting with PP on it. Mine stops loading at: ProceduralParts/Parts/ZOtherMods/RFSRB/proceduralSRBRealFuels. I have no idea if this is related to any other mods (such as Real Fuels which also doesn't have an update) or some weird interaction involving any of the other dozen or so mods of mine that haven't updated yet. I can say that it just STOPS loading, but the game doesn't crash. Right before the loading stops, there are a pair of MissingMethodExceptions for ConfigNode.SetValue, along with two NullReferenceExceptions. I also get an IndexOutOfRangeException, but those seem to be showing up all over the place. Here is a link to my full log: https://www.dropbox.com/s/4mas0t6c77ipie8/KSP%201.0%20PP.log?dl=0 Any help would be appreciated, especially if it doesn't involve uninstalling the mods I currently have. I'm a little tired of having to start my game over again after KSP updates. BTW, the unofficial update does not solve this problem, and all of the mods that I have that have gotten updates are currently up to date via CKAN.

I didn't test this, but this is what the code for adding this mod to all pods and probes should be. @PART[*]:HAS[@MODULE[ModuleCommand]] { MODULE { name = DigitalClock } }

I'm back! Again. As usual, life kinda went on a rollercoaster ride, and I haven't had as much time to work on this as I'd hoped. However, I'm getting back into it, reading the code, fixing stupid mistakes, removing bugs, and implementing features. Or in some cases, completely re-implementing features (WHAT WAS I THINKING!?) Over the last couple days, I've fixed some problems in compiler's implementation of the Shunting-yard algorithm, fixed issues with the PRINT keyword, re-implemented SET, fixed a keyboard input issue, and added a handful of extra architectural stuff. I'm not done yet, though. - - - Updated - - - Thanks for the offer. I'll think about it, but to be honest, I'm a bit of a control freak. I also don't currently have a clear development roadmap because I've been off the project for so long. So as far as that goes, I wouldn't exactly know what to have anyone else work on, because I'm not sure what I'm working on until I'm halfway into it.

I've looked into this a little bit, but I'm not sure if it's possible without jumping through too many hoops. I am planning an alternative if this isn't possible. I do want to have some kind of thing for GUIDO to do.

I have no idea what mod is causing this, but I just had the most unusual bug occur. I had a pair of kerbals on the ground in the desert on Kerbin, when suddenly their temperatures started to rise and they burst into flames before exploding. As hysterical (and terrible) as this sounds and looks, it's quite off-putting. The only mods that I can think of that might cause this are Deadly Reentry and TAC Life Support, but I can't imagine why either one would happen like this. I wasn't reentering the atmosphere. Is there some other thing anyone can think of? If it helps, I was near a particular easter egg in the desert, but I wasn't quite there yet. This isn't some kind of Indiana Jones face-melty thing, is it?!

The Public Affairs Officer console is currently in the works. The PAO will be able to record "voice" transcripts of mission control and capsule loops such as: Air-to-ground loop PAO commentary loop Mission control loop Onboard voice recorder Combination of all above The mod will generate things to put in each loop as different flight events happen.

I've designed a "formal" protocol by which the data will be transmitted, so I can support multiple formats going in both directions. All data is transmitted and received in the format below: [table=width: 500, class: grid, align: left] [tr] [td]Byte Range[/td] [td]Value[/td] [/tr] [tr] [td]0-4[/td] [td]ASCII value "begin": 0x62, 0x65, 0x67, 0x69, 0x6E[/td] [/tr] [tr] [td]5[/td] [td]Protocol ID[/td] [/tr] [tr] [td]6-37[/td] [td]Reserved[/td] [/tr] [tr] [td]38-41[/td] [td]Data Length[/td] [/tr] [tr] [td]42-n[/td] [td]Data Segment[/td] [/tr] [/table] This format is represented by the class TelemetryServer.DataBlock. I've also written a general Client class in the TelemetryServer DLL. This way, anyone who wants to write their own client can just use the existing system to pull data off of the TCP line. The current list of protocols defined by Protocol ID: 0 - Raw (this is raw binary data). 1 - String (this is UTF8 text). 2 - TelemetryData (this is the serialized TelemetryData structure) 3 - CommandUplink (this will be the serialized CommandUplink structure. This is a planned feature.) Being that Protocol ID is a one-byte value, I can support up to 255 different protocols, which is more than enough for anyone to expand upon. Update: It occurred to me in my sleep that I should at a few bytes of reserved space just in case I need additional flags and parameters later. So I've tacked on a 32-byte reserved field.

It's fine, I understood what you were going for. I even had a momentary mental image of trying to code the telemetry to be sent via email.

For right now, the main protocol is a serialized structure: https://github.com/griderd/SpacecraftTelemetry/blob/master/TelemetryServer/TelemetryData.cs I used to use a raw data specification, the basics of which can be seen here. I'm in the process of re-implementing that as a possible alternate protocol. There is no particular protocol set in stone, and I'm willing to look at any possibility. I considered both JSON and XML for a time, but the downsides outweighed the benefits for the beginning of the project.

Yeah, TCP is a transport layer protocol. Telnet is an application layer protocol. It's up to the client software to interpret the data that's being transmitted. I only wanted to get the data out of KSP, and TCP seemed the easiest way to do it given the limitations of KSP's IO library.

The server can transmit pretty much anything from raw binary to UTF-8 strings. Originally, all of the data in my client-server setup was transmitted via strings in key-value pairs. However, the more complex the information got, the more complex things became when trying to interpret the data. For example, I wanted to be able to transmit resource information related to each part in the vessel. Eventually I decided that it would be easier for me to use a serializable structure that can be deserialized on the client side. I'm not entirely happy with this solution either, as raw UTF-8 transmissions are preferable for the reasons you mentioned. In the future, I'm hoping that I can switch between protocols to support that type of data. However, at the moment I'm focused on trying to get the mission client working. Update: I've added a class that transmits non-collection data. I'll be testing it today. If it works well, I won't be making any modifications to the raw telemetry client. I'll add an option to the transmitter in KSP allowing the user to switch transmission protocols.

Telemetry Radio is dead! Long live Telemetry Radio! New realization available here: http://forum.kerbalspaceprogram.com/threads/100781-WIP-Telemetry-Radio?p=1553448&posted=1#post1553448

A Telemetry Radio is an idea I've had for quite a long time: specifically a way of transmitting telemetry data from a spacecraft to the ground like Telemachus, but with the line-of-sight and range restrictions of RemoteTech. I started out with a grand and somewhat complex system, but eventually I simplified it heavily and broke it down to this: a simple data server on one end and a receiving client on the other. Things are nearly at the point where I'll be making early releases so you can see what's what, so keep an eye out over the next few days. At the moment, the server is a TCP server that establishes itself at the IP address and port listed in the antenna config. At the moment, the mod also requires RemoteTech. The mod's DLL actually references RemoteTech because it uses the RemoteTech.API class to gather connection information. I've tried getting to this class via Reflection. If anyone has any advice on how to get to this class through Reflection, I would be very thrilled. At the moment, there are two clients, though only one of them is up-to-date with the latest protocols. The big one is a NASA Apollo Mission Control-style client implemented using WinForms (so expect it to work in Windows only). It has all of the flight controller stations (see the gallery below), with lots of plans and hopes and dreams. The other is a very stripped-down client that simply takes the data it gets and saves it to a CSV file. The second isn't a priority at the moment, so it isn't currently functional, though when it is, it should work in Linux and OS X, as it's a console program. Pros Transmits telemetry approximately every quarter second. TelemetryServer can transmit raw binary, strings, or anything else you might want. My client programs only expect a specific structure. Compatible with RemoteTech, which means that if your antenna loses power, goes out of range, or drops out of line-of-sight, you lose signal at the same time that you lose RemoteTech connectivity. Very very expandable. If you want a particular or function value added, I'd be happy to try to accommodate you. Cons At the moment, RemoteTech is required. If I can find a way to get to the RemoteTech.API class with Reflection, I will write it so that you don't need RemoteTech. It will only be highly recommended. At the moment, there is no control of the craft from any client program. The server does not have an uplink capability right now. However, there are plans to change this (note the ABORT button on the BOOSTER station). The Mission Control style client requires that you're running Windows. TO-DO Finish all mission control stations Get into RemoteTech.API class with Reflection. Create at least two antennae. Add some shine. Add uplink capability. Delay data transmission based on RemoteTech delays. Setup bulk transmission of recorded data after acquisition of signal. Set limits on how much data can be stored. DONE Standardize transmission protocol. Record data onboard vessel during loss of signal. The INCO (Instrumentation and Communications Officer) station now allows the user to record telemetry to a CSV file. The PAO (Public Affairs Officer) console now semi-functional. Certain flight events and mission control events are recorded by the PAO console automatically. The PAO console also offers the ability to add PAO commentary. Data transmits fine across networks. Made some changes that helped it along. If you're interested in taking this for a test drive, helping write code, or even make a model or two, I'd appreciate the help! Source: https://github.com/griderd/SpacecraftTelemetry

Jebnix is not complete. So no, not yet.

I am at the point where the control flow from compilation to execution is complete. There are a lot of things that need to be implemented in both the compiler and runtime. I also need to set up vehicle control and some additional data types. Then I'll implement a KSP version of the console. That's the short version.

A sample of the WinForms Jebnix Debugger. This includes the new video memory viewer.

Aaaannnd we're back! I went AWOL for a while. As I'd mentioned in April, I'd made some major life changes, and I was working in relation to those. In short, I quit school and I'm starting a business. As a result, I've been doing a quite a lot of work in that area to get it going. However, I haven't stopped working on this. I've just performed a commit a few minutes ago, which fixed a few known problems in the code. Hopefully I'll get a few things done over the next couple days.

This is a sample of the documentation I am writing for this project. This page describes the Vector structure in KerboScript++. https://github.com/griderd/Jebnix/wiki/Vector-Structure-(KerboScript) Is there anything else you'd like to see in the documentation that will make working with KerboScript++ easier? P.S. The other wiki pages, except for Official Features, are out of date by several weeks because of the changes I've made. However, I will be updating them as I go.

I've just added an Official Features List. This list is not complete (I still need to add stuff to it), but it contains a good idea of what I've got done so far and what I need to do still. This only applies to the compiled version, which I consider experimental. https://github.com/griderd/Jebnix/wiki/Official-Features

I will be including a debugger, which will include stepping, stack trace, and variable values, as well as the values of the evaluation stack, all with symbols (the virtual machine will be a stack machine). You will also be able to do a memory dump. I will also be including the console debugger that I use to test everything, which is simply a Windows Console application that emulates the machine in the game, except without a rocket attached to it.