tallman

changeLog.txt: "you should now be able to use hexadecimal and binary constants". But one can only see hexadecimal example in instructionset.txt , and no binary.

Well, it needs a lot of trigonometric calculations. Which, in turn, needs a lot of tables, interpolation and so on. Therefore, it will be more experiment with implementing of a trigonometry, rather that experimenting with monitor

Do anyone have ideas for using of the graphical display ProgCom has? I mean, one can always implement Life or whotsoever, but what about ideas of using it for something useful? I want to have some experience with this screen, and I'll be happy if someone will propose some interesting idea for testing.

Looks like I should read about this GIT to understand how to upload code to your repository. I have a simple LED blinker and a PI-throttle-controller for maintaining zero vertical speed (i.e. it is not starting-and-stopping engine, like navigator.txt do, but tunes the throttle to compensage the gravity). I propose the structure for community code: Special folder ~/communitycode/ should be introduced for this Every program and every library should be in separate directory. This directory will have all the files with code, examples, manuals, crafts for testing, copyright notices and so on and so on. Directory for library should be named following pattern lib-something (~/communitycode/lib-vectors for example) I propose to not separate this directory by authors. It's possible to mention autorship in manual or whotsoever, but united space will stimulate us to (re)use code of their neigbours.

Unfortunately, no. It's the reason I asked you for this Do #include directive supports pathes? Relative pathes? Absolute pathes?

Well, yes, until one need some shared code - libraries, data tables and so on.

And then: looking at navigator.txt it looks like you added CPU_CLOCKRATE constant to the compiler (haha, it also looks like you was catched by movi / movil problem just like I was). Unfortunately, it is not mentioned in both instructionset.txt and changeLog.txt.

GitHub is, first of all, the place to share the code examples. Can you propose the directory structure for this? Mind: except of the code itself, you always need manual of some kind and, in most cases, craft file to test the code (especially when seriabus-powered devices will appear). You will have possibility to compose more interesting "starter set" probably. For example, computer-controlled rocket, which can reach the orbit "programmatically" is much more easier-to-understand example if compared to navigator.txt, I believe.

Well, probably you should not worry about coding all those (and other) sesors. Probably better to implement universal way for external "hardware" to be connected to ProgCom. And probably one of the sesors as the demo. Community then will do as many sensors as we want

SimplySimon, by the way, do source code providing with the ProgCom is contemporary (I mean, example code is little bit outdated, so the source code may be outdated too)? I can see serial bus of some kind there, thought it not included in CPUem. Is it some plans for future?

Well, I'm really not sure about it. ProgCom is "mechjeb replacement" of some kind on it's own. It can do all the same things as mechjeb can do...assuming you can provide appropriate software and align coefficients accordingly. I banned myself from using mechjeb, because it looks like computer play games with himself and I mainly looking on the pretty pictures - which is fun, but not what I'm seeking for. At the same time, I'm using ProgCom with great satisfaction. And, for example, PI-controller I designed yeasterday to control zero vertical speed, which, combined with SAS, effectively gives me possibility to build hevercrafts and cruising missiles, was very inspiring. By the way, I learned a PID controller basic theory for this, which was fun, too.

Radar altimeter is really cool feature, which I wanted to request myself. It's the only thing that prevent me from coding "rocket parachute" solution. Laser distance sensors is even better - it may be used for autonomous rovers and for semi-automatic docking. It also abolish the need of the first one. Bumper sensor looks cool, but somewhat limited usage. Cutting skycrane is the only usage I can imagine just now. Talking about sensor, I requesting "Fuel Gauge" sensor, which fits to fuel tank and returns the level of remaining fuel there. Quite usable for automatic orbit launchers. Trouble is: now ProgCom uses memory-mapping approach for input-output. It's much harder to implement, if you have several sensors of same type, providing different data (fuel gauges on different tanks, laser distance in different directions). Any possible "real-life" approach, like dynamic memory mapping with fixed-address descriptor structure or using of the interrupts will increase the difficulty of programming above beginner level. It's possible to implement special command for hardware input-output, like "readhw resultRegister, deviceTypeId, deviceNum", but it will be experience somewhat differ from "real" coding.

There are a several of us. Probably we should share our ProgCom code somehow?

Are you sure? Can you open notepad, select File-Open and then copy-paste filename with full path? And we'll se if file will appear. I mean not try to visually controll all the way, just copy and paste it and try to open and we'll look. For example, I little bit worried about space in "...PluginData\ProgCo m\..."

I just found another workaround: if I press [Esc], game pauses, but computer still works (at least console commands), and I can load everything I want without affecting my vessel. It's much better solution that fast typing at the loading time.

That is strange, that should not happen. I am unable to reproduce this problem, do you have a sequence of steps that will reproduce the bug? Well, it's happens all the time, without any special steps, both in .19.1 and (just tested) in .20 I have suggestion that it's because I'm using native Linux version, and you probably using Windows or Mac one, and therefore you, probably, can't reproduce this. I have found workaround of some kind: there are always a lag between loading the craft model and starting of phisycal engine calculation. You can move you camera, but can't use engines, staging and so on. ProgCom works in this period (well, at least console works and it's possible to load programs), so if I load needed program quickly enought, everything going ok then. Of course, it's not comfortable, but better than nothing.

I just finished my ProgCom blinker (classical "blinking led", now on ProgCom) project, and here is my comments. CTL button also blocks ActionGroups from executing. It does not mentioned anywhere, and I spend lot of tyme trying to debug my code to understand what's wrong. In "main" documention file instructionset.txt one may read "CTL toggles whether the computer can control pitch/yaw/roll etc. on and off. It also controls staging and translation until I implement separate buttons for that". But I failed to find any instructions regarding staging. Is it really possible, and if yes - then how exactly it's possible? When using "warping" (making time faster), ProgCom continues to execute at the same speed. One may expect that when time goes 5x or 10x faster, computer acts faster aswel. If it's impossible or just too boring to implement, why not just blocking time warp when ProgCom runs a program? Just like working engine blocks warping. In the example code navigator.txt one may find comment ";this bit of code sets the timer max to 96000 cycles (1 second)". Look like this comment a bit outdated, as long as clock rate are 384kHz now. Probably worth to implement constant CPU_CLOCK_RATE directly into the compiler? I have strong feeling that ProgCom should consume ElectricCharge and stop to work when we run out of ElectricCharge. For purists/IT maniacs, if halted (and waiting for interrupts), it may consume less electricity then when working in infinite loop. And, finally, why not make ProgCom module the Prob Core functionality? Why do you need additional core, when you already have ProgCom, which, in fact, programmable core by nature?

Talking about communication: for implementing communication it's neccessary at least to have ProgCom enabled and working on the spacecrafts user don't control at the moment. Now it only works and only active for the vehicle under user's control. I'm not sure if it possible at all. Probably KSP engine can handle only one "active" ship at a time, and other can only be handled as a passive pieces of mattery. For example, if you'll send SolidFuel engine to fly independently (activate and then decouple), it will disappear quickly (after reaching distance about 2.5 km from the command pod as from my experience).

Just bought KSP and ProgCom is the first plugin I downloaded. I have one main question now: when I typing the commend in the console, it also affects my rocket/vessel aswel. For example, [space] is interpreted both as space in the console and as the "next stage" for my rocket. Is it possible to avoid this somehow?