Wader8

Well okay, minor thing, but I'm not sure if renaming would change the classification, will see. I still think minor things should be taken care of, if they add up it makes the whole game look bad.

(I'm not done with the rendezvous markers, i'll get back onto that later, if the thread won't be moved there (because it's really half broken I actually wanted to rename it) then I'll make a new fresh one and keep that one only on that topic, sorry I was kinda figuring things out along the way in this first big session I had. -------------------------------------------- Oh the reason why I do this is to go over it so I figure it out, so that's how I'm learning, doing things as if I was a beta tester, but also posting the flow so it shows what beginners have confusion with most, that gives feedback but also it provides me a thread for later, I might forget these things half a year from now, I need to document it, that's how I do things, I do something for 1 to two weeks straight, then I don't get back until many months later. Ahaaaaaa now I get it what the focus view does, for whatever reason. Focus view onto one of the objects that first gets encounered (that produces a conic) seems to lock that conic path to a specific mode, so it cannot be changed (with the PreciseManouver Mod) - it locks it into Mode 0. I thought that this Conics Mode was a more bigger underlying tech, this is just more like switching prediction relativity, I consider this quite a big deal in terms of gameplay not some optional graphics option in settings. Even as I switch through the modes I see the paths move, but many paths still have missing empty space between them, but I'll keep experimenting, yes I think one of them is the thing I expected, not to say that other modes aren't useful, they are infact, I'm not saying it's bad, I'm saying it's just showing me something else that I'm expecting, as a beginner. I guess I was always expecting Mode 3 so when it kept showing me Mode 1 or which one is default, i kinda took some time to figure out what it's showing, but still, I was talking about the path inside an encounter as well, so this isn't the end of the story yet, what happens when I get inside the SOI, what kind of options do I have there. Yeah I better read on that chart, to first figure this thing out. However, just looking at the whole system, shouldn't there be better colission course detection ? http://i.imgur.com/DQrF51J.png One other thing, does the term "Conic Patch" only referr to the auto-generated manouver orbits? Not the whole vector map line system right ? EDIT: Mode 3 feels kinda bit too good to be true, I mean wouldn't taking the SOI of the flyby object a lot more mathematical computation into account, but it feels like a flip of a switch.

I have some of the launching structure debris with a lot of fuel tanks and engines ejected that happens a few high-gain direct antennas on it, it is completely uncontrollable, comlpetely devoid if electricity, but some fuel tanks are not empty completely. It is obviously not connected to KSC. But the system thinks it's a relay satellite. EDIT: I think this is the wrong forum, shouldn't bug stuff go into Suggestions and Development ? None of the forums has the kind of description suitable for bug reporting, I'm totally confused.

I have said that I am not trying to achieve anything practical about the things I'm posting here. I have read about the Conic Patch Limit that is understood to me how many forward manouvers or auto-generated orbits there can be displayed when possible. That is not the same as Conic Patch Draw Mode. I have the mod but I haven't used it deeply yet because I have to read about what it does - does the mod "fix" the things I was talking about? Even if it does, it's great for play times but it is not an objective fix and I can't rely on it when I'm doign this research, it's not an official "fix" and my critical analysis should still stand, unless I am wrong. I'm asking the community if my findings are correct as well as to serve for feedback to the developers, that's the whole point. The help that I need is in understanding the system of how it works so I can provide my feedback. Are you trying to say that the Conic Patch Draw Mode could be changed from the Precise Manouver Mod ? I have no idea yet what does this Mode do, so I'm not trying to do anything with it yet. I also do not want to get too much ahead of myself, I first need to understand how this Mode works, which is the default-install one. EDIT: Maybe I'm in the wrong forum, shouldn't I be in Suggestions & Development, for this kind of thread. I'm probably have to redo this later on to omit all my figuring out and only present suggestions.

Now I'm reading more about what this conic patch draw mode is, I'm still on default settings. Maybe this is the "fidelity" level I mentioned, maybe this will enable more of the stuff I kept saying was missing? But it will have a performance cost right ? I'm in the middle of playing, finish this session, I'll start testing it later. https://www.reddit.com/r/KerbalSpaceProgram/comments/1ly5uh/feature_request_conic_patch_draw_mode_and_limit/

Overall the map wide solar view seems clunky, not only is it affected by the periodic lag (every X second freeze for a moment) when a ship reaches certain number of parts, both my ships are originally ~750 parts and 5-6 stages, most of that is ejected later and more like a 100 parts remain for the satellite modules. It is also hard to navigate not only because of the mouse hit box for various interactive thigns, but also because of the camera zoom levels not being precise enough as well as no ability to focus the camera on various markers and the manouver node it self. Are you kidding, I wasn't zoomed in enough? It takes ages of fiddling with angles just to get these shots I've made. Most of the pictures are maximum zoom, it is very frustrating to do anything as the mouse cursor hits several hit-boxes and it's very hard to precisely edit the manouver, but it's also hard to focus on the predicted encounter because if there's no target or your ship close by you can't get that many good angles. I'm trying to do critical analysis, which I enjoy doing for a bit while I play at the same time, your posts would then be considered half-half if you do not put the amount of effort in it takes, causing more confusion. Also, I didn't explain yet that what I'm doing is critical anylsis of the game, I'm not actually trying to achieve something in this case, I'm purposelly doing things to expose weird behavior, while doing this I cannot care how many mods are out there, those are all unofficial and doing testing you suppose to ignore mods can't tely on them to magically "fix" the problem, that's only a temporary convenience for personal use, which I probably will use when I play the game for enjoyment. I'm kinda doign 2 things at the same time, half the time playing, pausing, testing, and then back to playing again, hopefully this clears that out. ---------------------------------------------------------- ---------------------------------------------------------- Sorry, I didn't mean it actually shifted, I mean the GUI drawed path indication shifted. I have no idea what is the benefit of this, i see none, infact I think it is detrimental and causes more confusion. There is no indication of how is this helpful. You can see that the object prediction icon sits ontop of the planet, that icon signifies where the planet will be at encounter, but here it is basically canceling it self out, it does not appear it is showing what it has been designed for. ---------------------------- I am aware that some areas cannot be done with super fidelity because of performance constaints, but here I'm not trying to get better forward prediction, the above example was an extreme case also, but it seems like it's not showing the way I'd expect it even for basic encounters. I did hear that the map view has some things to lower computations, I'm not sure exactly where or what, but some of the areas are kinda critical to the game, a "that's what it takes" approach could be taken in some cases, while some people may already think about interstellar stuff, I would rather have the existing system work better before moving into more complex features. I understand now what the path inside encounter is, it's a SOI relative path, I think it could be indicated better what it is, but this can be done by just adding the missing paths, the brown one is the encounter transition path, the blue one is the "closest-SOI relative" relative or "primary" and can be left alone just like it is. Also yes the double-relative is not a typo, I kept using the term "relative to" when talking about what something is showing currently, what it is representing. The blue path is showing (relative to) the SOI-relative orbit or encounter path, however this is NOT a real encounter path, the actualy encounter transition, the brown path is missing, this SOI-Relative is only useful if you want to get into the target objet's orbit, which is most of the time the purpose in normal gameplay, but I think seeing the real solar-system-relative path would be interesting and would clear things up, it would also be interesting to see how much you move with the planet around the sun while also seeing your movement through the closest SOI. Obviously I am beginning to figure out that this part is a big deal in terms of computation and mathemathics, as everything's very relative to the current position of everything, SOI influence increases as the source object gets closer, so it's not that I'm whining, I understand we can't have this much fidelity for the scope of this game. My suggestion is just improving little things wherever possible without that much more impact on performance. But I have a good PC so I'm not really that worried, I also do not agree that the whole design of the game be limited to average hardware capabilities that's like being forced to drive 50mph on the highway just because some other people don't want to move out of the way, those that can't run it could turn it off. Additionally Only Closest-SOI-Object relative path/orbit is shown, with the primary blue color, yes the sun-SOI path is shown there in yellow, but the connecting brown line has disappeared, I hope that can be enabled in future, but you can also see that in the upper pre-encounter view the brown path looks as if it's in a colission course with the object, somewhat nonoptimal behavior, the predicted-target-position icon in brown appears to be showing the position when the source object reaches PE. Pe is the closest approach, the "closest-approach" markers showing the closest approach for the next orbit are useless in this case and only producing clutter and confusion. The closest-approach markers should be re-enabled when the source object gets past the SOI it is encountering (closest), after Duna Escape, could be one of the solutions, but then I think there could be some situations when it could be useful, I don't want to come here and take something away from people. On the other hand, Closest-Approach markers are extremely relative, relative to current revolution, relative to most farthest auto-predicted and/or manual-manouver orbit, and relative to where-ever is the closest-approach in that orbit - So the closest approach in the newly created orbit after Duna Escape happens to be right after the Escape, because there's no other closer point down the line in that orbit's first revolution. In many cases there might not be another closer enolovely personer than the one you're going through, so the C-A markers will a lot of the times be showing like they're tied to the Escape Point, because that's where the new orbit begins. That's the best i can figure up to this point, about C-A markers. So this is one of the changes that would make this less confusing: - Syncing the Closest-Approach Marker Icon color to the color of the orbit path it is currently relative to. - Adding a suffix icon or a star character or a "+N" number indication, appended at the top right corner the place where "power of" numbers usually stand, that PS: For a period of time I kept using "conic patch" term for the auto-generated ones, then I figured out pretty much all the lines are conic patches being drawn, ones being manual other automatic.

Another thing: Why is there no descending and ascending nodes for the orbiting object, to see the inclination value?

That's why I suggested it should be removed(hidden) until it's working better better because I think it's doing more bad than good. ----------------- ----------------- Another thing. When focusing on an encountering object, the Escape Path is shifted, I don't know the purpose of this, but it doesn't feel like it's intended, it feels broken.

Additionally, can someone explain the contexts of the markers here? I know what they are but I'd like to hear from someone else to check if I'm correct. Bottom View: 1. So the encounter spans for as long as I'm inside the Kerebin SOI ? (yes) 2. Being inside kerebin SOI for some time affects the orbit slightly so that's why the brown path turns into purple? (yes) 3. The end of the Kerebin SOI is the Kerebin Escape point ? (yes) 4. Why is the closest-approach markers put on the Kerebin-Escape point? (no idea) 5. Are the closest-approach markers showing now for the next orbit that will appear when kerebin escape is reached? 6. What is Pe relative to, is that the closest point in the encounter? (looks like it) 7. If 6 not true - What about the marker for that? To me, closest-approach markers are confusing in this case, even if they're showing something else, they are still the same color, same icon, they should be indicating to what they're relative to, or simply hidden, if you agree. Additionally, the Closest-Approach markers disappear when Kerebin is not set as a target. --------------------------------------------------------------------------------------- With the following picture it is more clear, I shifted the manouver to separate the green, which apparently is the new orbit generated from the shift caused by Kerebin's SOI, right. From basic operation I have seen that the Closest-Approach markers start showing things relative for the manouver's orbit, away from showing things about the current orbit. So my speculation is that these markers always want to display things relative to the most forward orbit, including manouver orbits, and here in this case we have a tertiary orbit that's in green (secondary if you only count manouvers), so these markers are probably relative to that green orbit and showing things about what will happen when the ship revolves the first time around it, and where is the bug in this if at all, not sure exactly, but one scenario is that I guess it's not counting for 1 revolution across the green orbit and it's showing the Closest-Approach for the start of the green orbit, and the start of the green orbit starts at the end of the Encounter, at the Escape point, that would explain why the marker it's fixed onto it. It may not be a bug as in a code error, but it may be unintended behavior, whatever it is, I don't agree with it and hopefully the devs would agree it should be changed. However: Whatever the Closest-Approach markers are showing now or in future after this "fixed-onto-Escape-Point" is changed, a lot of beginner confusion would be avoided if their color would be appropriately tied to the same color as the color of the orbit or manouver they're relative to. That would clear thigns up for just about everyone, not just beginners, Periapsis and Apoapsis and other things, they all have their colors synced. PS: Correction, earlier I said that there's no way to unset a target, well, it appears it is possible to do this with planets and such, but in that session I still didn't figure it out. BTW: I was trying to rename the thread title into Various not "Rendezvous" since I expected to see more things as I dug deeper, but the edit didn't stick throught the edit process I guess. ------------------------------ Update: Continuing, I changed and fiddled with the manouver a bit more to create one heavily convoluted one. Two things stand out. Closest-Approach markers probably aren't technically tied to the Escape Point, as this pictures show, are those example's coincidences? Well even if it's showing correctly, it should be more clear that it is showing about the next orbit. The second thing is, I am correct that the markers always show the most forward manouver orbit, in this case it's showing for the blue orbit, there's like 3-4 orbits behind it. This one isn't showing any C-A markers here ... Hit the Mun too. In this case it doesn't fall on the escape point, so at least proving the point that it could be a coincidence in eariler examples, it may not fall always on the escape point later on. Still the color of the marker is the same, everything's the same as if it were showing things for the first orbit, so when there's a lot going on, it can lead to confusion. There's an unrelated effect I found, when focusing camera to Kerebin, which for me is a bug.

Okay, if it's showing closest approach, then I disagree with this behavior using this marker, because the marker is about intersection and it also doesn't provide how far away, this would help with precise manouver plotting when there's a lot of unclarity There is no indication this is showing closest approach to the target orbit, see, what I talked about before, there's imo mixed up contexts and things being vague with various things. Intersection markers should be shown, switched to, only when the the orbits are within X kilometers, 5 sounds a good number, if it's more than five then the marker whould switch to a different lookign and differently colored appropriately labeled "closest-approach" marker. The biggest thing this game needs to pay attention is the map clarity as it is the most critical area because it's very easy to be disoriented in space and even more when we have to represent this in software simulation on non optimal devices, I do have a good machine with 1440p and RX480 tho, as far as performance goes there's no big problem in my case.

I forgot to mention that one of the biggest positive things in the editor, is the strut attachment caching when duplicating so it remembers where the connection were and also duplicates appropirately even for the struts that were not sourced on the parts piece that was used for duplicating, remembers the whole thing. Secondarily, when duplicating more stuff on an duplicated part it treats that as a whole and appends, that's also a big big deal. These 2 things have a huge effect. -----------------------------------------------------------------------

Thanks, I also recall the name now, it's called the "Engineer's Report" that's the messages I was talking about, that when I attach a decoupler to a dock it thinks that I'm trying to use docks as decouplers. Yes I am trying to eject leftover fuel tanks but also leave the module with a dock port, so that's why this message could be removed imo. Attacking a decoupler to a dock port could also put shroud around it just like with engines, this would be more logical to me. But there's nothing wrong practically, it all still works. I hope I worded this correctly now.

Sorry, I actually wrote a different title but canceled out and changed it after I figured out I was a bit wrong, I made a minor issue a big deal but a bigger deal just a small mention, in the heat of the moment I just left the image. I went into a long session yesterday and the day before and went to sleep at 3 AM which is not recommended, I never have nightmares but I had a few creepy moments of feeling half-asleep and dreaming I was holding a fizlling phone that was just about to blow up it's battery which woke me up for a moment lol, but I learned a lot despite unfortunately losing nerves because of the clunkyness of the controls and other minor things, I think I spent like 4 hours trying to dock, but that is just me being used to FPS and RTS games I guess, yes I am not experienced with the control scheme, but it wasn't the controls that much, the Dock Port Targeting mod thankfully has those "invert axis" options so that helped, but I had to redo my whole Satellite Core that night because of bad design issues around the whole RCS navigation, I had pods upside-down and I went overkill with RCS, I removed all SpaceY mod RCS parts and replaced with stock 4-direction ones and placed them even-angle aligned with the snap-to-angle mode so all the RCS are only on the true-north-south-east-west side of the spacecraft, a lot of fiddling with center of mass and I think I solved that whole thing, but I didn't try it yet, will do in some days as I get time. Searching on some videos thanfully provided the answers that are kinda not self-explanatory in the game, I did read a lot of tips, but a lot of the times when I kinda go into these "let's figure new thing out" sessions I usually want to go down to the meat and potatoes and not read tons of documentation for hours beforehand, so that is definitely my fault. The point is I realize this and a lot of complaints would be very subjective so I just cut it out and I'll just post objective things which I think are real bugs or. I just installed like 10 mods 2 days ago after I played got this game since like 0.9 but I never ever played more than a few hours I was just fiddling around not doing much serious, no it's not the game, it's that I don't game a lot as much as I did, it's like only like 5 games, a few 10 hours a month, it's all working very nice without any crashes, ofcourse it starts lagging when certain part numbers are reached but it's been better technically than I expected. I just don't like that the music keeps playing when I alt-tab out to windows desktop, and some mods keep listening to key-commands when I write a save game, when I press P some mod activates/deactivates it self, one other button was some "Administration mode" or something. But I do not think I have any mod that changes anything with the map orbit display, unless one is doing something I don't know, here is the list of mods: I actually didn't use much of the stuff yet, mostly engines, fuel tanks, not only it's too muh at once but I also purposelly want to gradually discover things so the experience is more slower and prolonged, and some of the stuff probably has to be enabled ingame before it's active, no I didn't use MechJeb on any of these flights. But I might do a specific thread later to post all my things that bothered me, kind of like a list of the top things, I know a lot about gaming, but this is more like a simulator, yes I turned into simulators in later times, for any software like this minor things can ruin the experience quickly no matter how good the rest of the game is. Some of the most little things can sometimes mean a whole lot, I think this is very healthy feedback, now this can actually help all the other newcomers that may not be gamers for a long time and they certainly won't have the patience to sit 5 hours in front of documentation, Highlights in this 3 day session: (first day i had no mods but didn't do much anyway) - No right click menu button to unset target (extremely annoying that this cannot be done by clicking in the menu, I think one of the mods that displays stats had a button) - Fuel Crossfeed lines actually affect how tanks get emptied, plesant surprise. - Can't click on the commanding ship to set focus to it (ragemode, and you can't view controls ingame, so all the way to some post to find the key which was tab, and even that needs a lot of toggling to get to my ship, it's , it's more about that it killed the experience for a good 15 minutes) - Editor camera movement limitations, can't get close enough in some areas even with a lot of fiddling, but it was one of the bigger ones so it's not a problem most of the time, sometimes I kinda have to make a structure around it, it would be nice to have more buffer, Secondly there are lmitations to zoom amounts depending on which way camera is positioned at, despite looking from the ground up 90 degrees, I can't zoom in to better what I'm doing up there. Thirdly the camera can't focus on a different point, it's fixed to one point in the hangar and can only rotatate and move relative to that point. - Can't build parts on their own or at least cant build more modules of a rocket at the same time, se can't move the camera and use the editor when there's no primary command pod even if there are other unattached comand pods around. As I said, don't take personally the enraged points, there's a lot of factors including being behind the PC the whole day, however, I would always develop something so these things are avoided and even in such events which in the wild out there will continue to happen, someone's going to have a bad day and he wants to ride it out, I mean, I tend to play such games only at times when I am not in a mood to do real work and other chores, not always true and in this case it was half-half. I was tolerating a lot of lag once I got over 300 parts or something, basically every 10-20 seconds the whole game freezes for a few moments, this is probably some part of the engine getting clogged up not being up to par and it's unfortunate that it is mucking up things a bit, because the rest of the time the game is still smooth, I mitigated this by taking a break and restarting the application, thisfreeze- lag is present across the whole game, in editor and in main menus. I'll just stop here or else it'll turn into a wall of text. The thread I was writing before was about label details at the "Intersect 1" markers, I just couldn't understand the whole intersect thing because of the inconsistency, the pictures you see above is actually a real bug that was confusing me thinking that there's a range, the intersect marker I think only appears when the orbits intersect but within 5 kilometer buffer, well, it looks like this buffer is WAY too big and way too off, and I kept looking at the ascending and descending nodes and thinking that is the intersection, it's just that terminology is field-specific but also context-specific and that was a big confusion, if you look at the horizontal view, the orbits lines do "intersect", but that is only in 2D illusion when you're looking from the side like that, so this Rendezvous Intersection is a real one, I thought that the marker was similar to the ones for planets when you have a flyby and closest approach, but I have a more detailed thoughts all about that and right now I don't want to make this more complex by mixing too much all in one, basically I'd like the labeling and terminology to be more specific rather than vague like "Distance:" or "Speed" as well as Periapsis ..etc and other markers because these things change when the target changes so it's a more relative sometimes, it could help if the markers would have a suffix or prefix or some kind of extra indication, color probably should be the same, there could be a small tiny character or a "*" sign added to them or some kind of other icon, you could have more things displayed, some people could think it's cluttered but so should be optional, cause currently, the same markers that show the current orbit details are moved to the manouvering orbit but they all look the same. Now I don't have any specific explanation here of how I would have it, this is just a draft of what I'm thinknig about right now. I was confused for some time because the detail labels, the "Separation" value below on the intersect point shows the distance of the target at that time the commanding ship reaches that point, I kinda expected that would show me how far the orbits are apart, until I figured out it works in another way. But this is just my subjective idea, so I did not want to make it sound like it's a bug report, just my suggestion. This is what I was going to post, without the other obsolete thoughts: I think that even if the intersection buffer is still as low as 5 km, this would give extra precision, it would still help having this number in my head to better have the situational awareness. I purposelly created this manouver orbit plot so the imo-bug can be seen in action, there's some other stuff I thought it was weird and had a lot of confusion with but I didn't had enough grounds for those, I identified them as my beginner inexperience and other categories, this is the one I think it just doesn't look like it's intended. Extending the manouver orbit makes the marker disappear, so this is how far the manouver orbit can go before it disappears. Also the screenshots are garbled because it was a quick shrink from 1440p, I can provide the full resolution if anyone really needs.

Same thing when using 2 docking ports to get rid of fairing and fuel tanks, now this could be justified here, but not the one case I was using above.