opteron123

Somebody give that man a cigar!!!! This has been driving me nuts limiting mods on a 64bit platform and that has fixed it!!! mod a + b would work! mod a + b + c crash! remove mod c mod a + b now crash! remove mod b mod a work! mod a + b crash! ????? reinstall KSP and only add mod a + b Aaaarrrggghhh! Now: mod a + b + c + d + e WORKS!!! This fix beautifully!!!

oooh I like that. Building on the data payload layout that eyecikjou567 suggested (now I'm just being silly I guess and its late, but trying to keep real world SocketIO restrictions in mind) what about, say, 4 virtual GPIO buses with programmable flags and external 16 byte RAM buffers (see below) with each bus being a UDP socket OR file handle. This way it could then be extended to a databus for all sorts of virtual hardware, other then communications packages. So the virtual hardware theory behind this is any device communicating with the CPU on the databus has DMA to external RAM modules that the CPU clocks in serially. This cuts the complexity of bus mastering from the CPU and lowers overheads from real world CPU socket/file read/writes.....maybe. So a scheme could be: PORT A BUFFER_ADDRESS 128 PORT A BUFFER_ADDRESS_OFFSET 129 PORT B BUFFER_ADDRESS 130 PORT B BUFFER_ADDRESS_OFFSET 131 PORT C BUFFER_ADDRESS 132 PORT C BUFFER_ADDRESS_OFFSET 133 PORT D BUFFER_ADDRESS 134 PORT D BUFFER_ADDRESS_OFFSET 135 (These are real life 16 byte socket/file buffer arrays with index) PORT A-D FLAG REGISTER 136-139 Each ports FLAG register is bit addressable. bit 1 - Interrupt Enable (AsyncSocketRecv() OnFileChange() )? bit 2 - IO Direction (low= Output, High=Input) bit 3 - Latch Data (technically not a clock/latch but a nice bit to set to fire off SocketSend() WriteFile() ) bit 4 - .... (anything else that makes Real Life socket/file IO easier) bit 5 - .... (or any other bits that simulate control of a parallel data bus) .. bit 32 ProgCom opens the sockets/file when the plugin starts on UDP ports 6502-6506 (homage to MOS-6502) ready for connection/listen. SocketSend()/Writefile() is initiated when the data has been clocked from the CPU to the virtual RAM buffer and the latch bit is set to 1 SocketRecv() / OnFileChange() will flag INT_PORTNUMBER so the CPU vectors to the interrupt handler whenever there is data in a socket receive buffer. Now if only there was a way to pump other plugin data to UDP.....

Great work!!!! This adds a whole new dimension. Just throwing ideas out here, would it be possible to have a CPU i/o addressable interface that is an xml socket server. This would then allow an uplink/downlink style interface with the xml structure simulating a radio packet, that way ProgCom remains a programmable device, it is up to the user on what they do with the raw data. This could allow for user designed: Web based "mission control" style telemetry interfaces. The more adventurous users could develop a full fledged mission package written in the language of their choice to interface with the virtual probe via the limited command xml up/down link. Programmable scientific payloads. Where ProgCom sends raw data and the user "scientist" can do whatever they wished. Oh man, the possibilities...