Rodhern

Members
  • Content count

    302
  • Joined

  • Last visited

Community Reputation

59 Excellent

About Rodhern

  • Rank
    Rocketeer

Recent Profile Visitors

2330 profile views
  1. I may not be the best to answer this question, as Xamarin Studio won't really work for me. As for the dotnet35 thing, occasionally I misconfigure my Visual Studio, and I noticed that I can open the project files in a text-editor and correct stuff like the references and Visual Studio will keep my changes even if they don't exactly match up. I don't know if Xamarin will let you do the same. It may be worth a try. Try to look in the .csproj and find/read/change: <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
  2. I guess I can't argue with the "better safe than sorry" attitude you display. Also, it is nice of you to make recommendations to better avoid mistakes. In this case though, I (and it may well be just me) do not feel that an extra set of parentheses makes the formula any clearer. Again, this isn't meant to say that @DC's suggestion is poor; it is more for readers stumbling on this post later and wondering if stuff like " [M]/100*[E]*3600*[O] " needs parentheses to work; it doesn't, but you can add parentheses if you feel it is an improvement. Edit: Ahh, maybe I remember a reason for your recommendation after all. Some people in some contexts use "/" to mean an implicit set of parentheses to the right of the "/"-symbol. You can avoid that by an explicit set of parentheses. I hadn't that in mind when I answered, simply because I don't use that convention myself. So maybe, yes, your recommendation might make the formula clearer after all. And it got me to ponder which version is clearer - probably a healthy exercise.
  3. I am an idiot that answered an old post.
  4. Recompiled for KSP 1.3.1. Uploaded to Github as Kapoin ver. 0.1.1.1.
  5. I think you misunderstand what I am trying to say. I completely agree with your statement. I wasn't trying to say that doing it by hand should be the main way. I noticed a pattern/behaviour that would allow several easy ways of implementing part module load/save, and noticed that a particular node got in the way. Now JPLRepo have explained that the upgrades system makes it so that it is not easy to do it the way I suggested. I am sure that sort of conclusion is obvious to those of you that are very familiar with the code. If I don't ask if a feature can be improved you probably wouldn't even have guessed how potentially confusing it can be for someone that only knows of the KSP code by a number of API signatures and some forum posts.
  6. I am not entirely sure, but I think this is how you do. Go to KCT Settings, fold out the formulas by clicking "Show/Hide Formulas". In the NodeFormula window you see something like "2^([N]+1) / 86400". Change that to, say, "2^([N]+1) / 86400 * 3". [Edit: Remember to click apply]. Now your nodes will be researched 3 times as fast.
  7. Yes, I think you hit the nail on the head there. I would prefer to have something in a set way, and I do realize that it is not my decision to make. Thank you for taking time to answer that there is indeed a reason for the different pattern. Can we at least agree, that if there had not been a particular reason for a different pattern, then you could as well use the pattern that is most pleasing to the customer/modder/player ?
  8. Funnily enough, for me, the Spacedock one crashes, and the Github one freezes. A subtle difference, but interesting. Edit: Ahh, never mind, it just needed another minute. It crashes for me too.
  9. I think we agree on 90%+ of the stuff here. Obviously I don't want to save the stuff that is already saved for me. Looking at "EVENTS", "ACTIONS" and so on, it seemed to me that there was a sensible pattern there (that PartModule.OnSave takes care of those). Then "UPGRADESAPPLIED" seemed to break that pattern. At first I was annoyed, and then I got curious if maybe there is a good reason "UPGRADESAPPLIED" can't fit the 'old' pattern. That's all.
  10. You make a good point; most people probably won't be bothered this 'issue'. It is not so much that I need to do custom load/save, it is more that I find it more natural or elegant. In case you are wondering, I am happy to give an example: My part module is a container that is supposed to store collected 'asteroid samples'. When you think about it, there is really no good reason why the part module needs to know every little data detail of an 'asteroid sample' at compile-time. In theory the part module couldn't care less, if somewhere down the road it is asked to store a sample with data like "colour = green" or "scent = odourless", even though those properties do not exist in the present code.
  11. Well, technically you are correct, it is not a problem, it is more of a nuisance. In my naive implementation my custom modules would store the node information in memory when loaded, then write the in-memory information when saved. This way any information changed in the meantime would automatically make its way to the persisted node. In the naive implementation PartModule.OnSave (the inherited bits) would fill out everything except my custom data, so I just had to not overwrite the already added values and nodes and all was good. With UPGRADESAPPLIED in the picture I have to (at least indirectly) keep track of which data is custom data. Just seems like an unnecessary complication to me, but sure, it is manageable.
  12. I think you are very close though. Let us assume that at some point you have your cone (positioned and) rotated so that it matches Kerbin in its zero rotation state. Then you can store that state with something like: q1 := myConObj.transform.localRotation Then in every frame update the rotation: q2 := FlightGlobals.Bodies.[1].transform.localRotation myConObj.transform.localRotation := Quaternion.op_Multiply(q1,q2)
  13. If you are fine with sharing your code, maybe you could post the code needed to draw your current cone. It might be fun to play around with it a little and learn something.
  14. How to use ConfigNode?

    If you know which values and child nodes you are looking for you can do it a bit easier. I, on the other hand, have a fondness for the idiot proof method. You can run foreach on ConfigNode.values which will give you all the values of the node as key-value-pairs of type ConfigNode.Value (edit: which in turn has ConfigNode.Value.name and ConfigNode.Value.value). You can run foreach on ConfigNode.nodes which will give you all the direct child nodes (as ConfigNodes). Just run the foreach recursively and you will soon have traversed the tree.
  15. Compatible mods for KSP v.1.3.0.1804

    Let my counter with an other stupid question then; what version number does your KSP show?