Falki

Thanks! It was really nice to see someone try out the mod for the first time and to see stuff you were struggling with. Gives me good insight into what I should probably clarify better for newcomers (like the body category for example). Also, you can right-click on the map to add waypoints - useful for landing in specific regions. Also2, you can resize the window.

I think what kspkat is saying is that this mod (UI Scaler) isn't scaling the stock stage info bar shown in the bottom right of the screenshot. That part of the UI isn't from Micro Engineer, it's from the game itself. But anyways, I'm not on my gaming PC right now so I can't check, but isn't this mod made obsolete by the game adding it's on scaling setting a while ago? AFAIK there are 2 ways you can scale stuff now. One with the stock scaling setting that scales all stock UI segments and another with UITK for KSP2 that has its own scaling for mods that use UITK. Maybe I'm missing something and this mod still has its use.

I don't really know what to tell you, sorry. "I Wish They Made UI Customizable" is a very simple mod that was rushed and wasn't designed to be robust, to be honest. It works well enough for cases I've tested, but it's far from perfect. It certainly doesn't take into account resolution changes. UI groups' position offsets are hardcoded, values being empirically set manually by me, so it's not surprising that for some people they aren't correct. When flight UI is loaded by the game, this mod takes the position values of each UI group and works with those figures. And flight UI is loaded again each time you change your view from Flight to Map, and vise-versa and then again for every time your scene changes (VAB, KSC, Tracking station, etc.). Also, sometimes unfortunatelly the UI isn't fully loaded in time, so the mod takes the values which are not correct. Answer for the "which X position would be dead center" is -> it depends on the UI group. This mod should be rewritten at some point, to make it more robust.

Yeah, UI most of the time isn't hidden with F2. Same happens with Orbital Survey's UI. It's something to do with how UITK (Unity's newest UI framework) handles stuff I think, but I don't have a clue how to fix that. To be honest, I'm using a slightly different approach than other UITK mods, so it's probably something related to that.

When you hit 95% you're automatically rewarded with the final 5%. This is for handling edge cases where you're missing just a tiny bit and it's hard to locate where it is. Though there should definitelly be a science report for 100%. There's 25%, 50%, 75% and 100%. With the latest version of Orbital Survey reports are generated on all vessels that participated in mapping the milestone that is unlocked, so in your case vessels that scanned from 75% to 100%. I might change that so that they're generated on all vessels that ever participated, even for a single pixel.

v1.8.1 Fixed Drag & Lift Fixed Drag and Lift values not updating properly when their units change (e.g. mN -> N) - reported by @Kayser

There are 2 reasons why the legend is only displayed when mapping is 100% complete. First is from a gameplay perspective: players are rewarded with a legend when they complete the entire scan, so there's an incentive to do it. It also kinda makes sense that you'd first map the entire body, then analyze the results and then determine how you'd split a body according to different biomes present and then name them appropriately at the end. Second reason is a technical one. For performance reasons there's no connection between the legend and the area of the body that is currently mapped. There's also no record of a region belonging to an unlocked pixel. Under the hood, region maps are nothing more than pregenerated 2d textures. As you scan the map, you "reveal" what pixels are hidden in the texture, but in reality those pixels are just copied from a completed texture to an empty/gray texture, again with no data for regions that are revealed. Legend is also pregenerated and displayed when mapping is 100% complete. So if a map is not 100% complete there's only an option to display the entire legend or not to display it at all (since I don't know what regions are revealed and what aren't). And I feel it would break immersion, be bad UX, if the entire legend is displayed when there's a real chance that certain regions aren't scanned yet. Of course, there are ways to retrieve what regions are revealed and what aren't yet, but that would be more taxing to the performance, which already isn't that great, and I feel it wouldn't bring much gameplay value TBH. Besides, if you can get to a point where you have a certain percentage of the map unlocked, in most cases it isn't hard to get it to 100% - it's just a matter of having inclination close to 90° and you'll get to 100% eventually. In the mean time we figured out that "Experiment interrupted. Not enough Resources" is a stock bug, not related to Orbital Survey mod anymore. Radiation and Orbtal Survey mini lab (the part, not this mod) are generating these errors. If you remove those part you should no longer receive those errors.

v0.9.4 Fixes and QoL Fixes Fixed: science button won't flash anymore for Visual/Region mapping experiments - FYI @Spicat Speculative fix: "Experiment interrupted. Not enough Resources" notification should no longer show up during high warp. This doesn't retroactively fix the notification spam for existing vessels, but it should work for new vessels - reported by Argon Other All vessels that participated in scanning of the current level of the mapping milestone (25%/50%/75%/Complete) will gain the research report in their Research Inventory, so any vessel can transmit back the report to gain science. Of course, each report can only be transmitted once Internal rework of how research reports are triggered, with insight from Kuriosity Science. If you notice some weird behavior with triggering reports (25%/50%/75%/Complete) please report it Added Giant celestial body category. All bodies in the stock game are keeping their current categories (Small, Medium & Large). This is just a support for the 2.5x Kerbolar System and future mods that will add bodies with larger radii Note: in order for Visual and Region mapping research experiments to show up correctly in Science Arkive, you'll need to update that mod to the latest version

I'm able to reproduce this. If you add additional engines after the 2nd one, it correctly lowers the deltav, but the switch from 1 to 2 engines is not correct. For stage info Micro Engineer is taking the values that the game itself is producing. And, unfortunatelly, the game still has issues calculating correct values in some cases, asparagus staging for example. So it would be better if you report this as a normal game bug.

No, it doesn't show discoverables yet.

v0.9.3 Waypoint loading fix Fixed waypoints not being loaded when first booting up the game - reported by @Kayser Increased the hitbox of the map marker (vessel & waypoint) so it'll be easier now to right-click on the existing waypoint in order to edit/delete it

There is, thanks for reporting it. I'll release a fix soon. It happens when you first start the game. There are plans for some other future update, yes

Unfortunatelly no, game only supports the yellow one.

v0.9.2 Map Body selected automatically Changed: on opening the map UI from the app bar, current body of the active vessel will be automatically selected. MapType will be set to Visual if nothing was previously selected - requested by @rogerawong Fixed: styling of the "track vessel" button that broke with the previous version Dev notes: Updated SpaceWarp.Template to the newest version (UI Toolkit Unity project is now bundled with the main c# project)

You can go to ..\Kerbal Space Program 2\BepInEx\plugins\OrbitalSurvey\patches\configs\ , open _constants.patch with any text editor (notepad, word...) and change Field Of View values yourself. Values are defined per part, so you'll be changing the FOV for any body. Then let us know how it works for you. Still, I don't really see this as an issue since you can easily go to the tracking station and be done with it in a minute. I could increase the FOV values in general, if that will help. But other than that it's a change in logic that will take more time to do and it would add exceptions to the logic, which I'm not happy with unless it's for a strong reason.

v1.8.0 New entries, fixes, refactor New Entries (23) Vessel: NonStageableResources (double click to toggle capacity) - requested by JustinSchneider CommNetRange CommNetStatus AngularSpeed DryMass FuelMass Surface: TerrainAltitudeFromCenter TerrainAltitudeFromRadius (can be used to read ocean depth beneath the orbiting vessel) AltitudeFromCenter - requested by Unknow P Body: BodyOceanDepth (max depth of the ocean) Target: Target_ClosestApproachDistance (updated from Flight view also) - requested by @Biggen & alex-sherwin Target_ClosestApproachTime (updated from Flight view also) - requested by @Biggen & alex-sherwin Target_ClosestApproachRelativeSpeed (updated from Flight view also) - requested by @Biggen & alex-sherwin Stage: StageDryMass StageFuelMass StageEndMass DecoupledMass Misc: CurrentPatchEndType Surface: TimeToImpact ImpactLatitude ImpactLongitude ImpactSeaLevelAltitude ImpactRegion - requested by @munix Other Changed: StageFuelPercentage moved from Vessel to Stage entries (not working currently due to game bug) Changed: updated SpaceWarp template to the newest version Changed: plugin name changed from "micro_engineer" to "MicroEngineer"; also changed mod_id to "MicroEngineer" Fixed: mouse wheel scrolling entries in EditWIndows doesn't trigger game zoom anymore Fixed: game input is now properly disabled when editing TextFields (EditWindows) Fixed: milli unit precision - reported by @rogerawong Refactored: moved UITK custom controls initialization to the controller classes. This enables the same custom controls to be used in the unity project's UI builder Moved code repository to a new fork: https://github.com/Falki-git/MicroEngineer. Old location won't be updated anymore. Notes Most of new entries aren't shown by default. Add them with the EditWindow - click on the cogwheels to open that window Impact data: Micro Engineer uses the game's patched conics to determine the impact location. Since the last patch ends before the actual collision, up to several hundred meters above ground (according to my testing), collision point isn't 100% accurate. If you have a high horizontal and low vertical velocity, precision won't be accurate. IMPORTANT IF UPDATING FROM AN EARLIER VERSION MANUALLY (without CKAN): Since the plugin folder name changed, you need to manually delete the old folder after updating. Optionally, before deleting the old folder copy-paste "MicroLayout.json" file in order to keep the same window layout you had before the update.

Because most of the time players won't go to KSC and then to the Tracking station to do mapping. They'll do it from Flight/Map view. So the user experience in Flight/Map view matters most. That's why scanning while at altitudes that unlock higher warp factors is important. (BTW Minimum altitude is 60 km. Ideal is 220 km.) Also, lower than 220 km would be too low for relatively bigger bodies like Ike and Dres, scanning area would be too small for comfortable scanning. v0.9.1 "I Want To Paint It Gray" Added a new config setting "Always show Map view overlay" - requested by @123man When toggled, it will always display bodies with a hidden visual overlay in Map view. This effectively makes all bodies hidden/textureless until you scan them. This setting defaults to OFF so you need to toggle it in Mod Settings if you want it. Main Menu -> Settings -> Mods

See here: There are some compromises I had to make for Gilly as it's totally different (smaller) than any other body, but I didn't want to create a new BodyCategory just for Gilly, same as I didn't want to create a Jool-only BodyCategory. So the solution is that the Minimum altitude is really small for the Small category, it's only 60 km. You don't have to be at Ideal altitude to scan it; in fact you can't be since the SOI is only 126 km. You can be anywhere between 60 km (min) and the 126 km (SOI), so choose what's best for it. Take orbital resonnance into account also. Why not make the ideal altitude lower for Small bodies? Because limited warp factors are unfortunatelly also a thing in KSP (why IG, why?! ). If you take a look at the table here https://github.com/Falki-git/OrbitalSurvey/wiki/Celestial-Body-stats you'll see that Small bodies have warp factor x10000 unlocked somewhere between 160 km and 214 km. Since I wanted all bodies to be scannable at factor x10000 (except Gilly of course), Ideal altitude is set to 220 km. So both Jool and Gilly are outliers and they take a lot time to scan. Good thing is that you don't have to be in control of the vessel while scanning. You can go back to the KSC or Tracking station, then increase warp to x10000 and see Gilly scanned a lot faster. It will still take a lot of in-game time to do it, but that's orbital mechanics for ya. I don't recommend higher warp factors than that because of a stock bug that doesn't handle EC usage well in super high warp factors.

You right-click on the waypoint, then click Remove.

I already fixed this, but haven't released it yet:

Those are nice looking mockups, thanks . Yes, I had something like this planned. Either full orbits or just those little dashes at the equator that SCANsat has, depending on how resource heavy it turns out to be. There's an easy solution right now that you can do yourself to show any vessel on the map. In "Kerbal Space Program 2/BepInEx/plugins/OrbitalSurvey/patches/" there's a file named "orbital_survey_module.patch". It's a text file you can open in notepad or something similar. There's a line that says: :parts #antenna_0v_dish_ra-2 { If you want, you can add additional parts here. For example: :parts #antenna_0v_dish_ra-2, #antenna_0v_16 { This will add the OrbitalSurvey module additionally to all Communotron 16 parts. If your lander has this antenna, it will show up on the map. You can add any part here really, doesn't even need to be an antenna.

This suggestion is more realistic, but would cause more issues. Biggest reason for the scanning altitude revamp was impact on performance, especially for small bodies. If we have a FOV concept, then altitudes need to be vastly different between small and large bodies. Given enough altitude, even a tiny FOV while scanning a small body can mean that a large area of the body is covered by each scan, which drastically impacts performance. We could eliminate FOV and have a fixed scanning area, but I like having it, seems more realistic, more fun gameplay wise, and simply more fun to see dynamic scanning areas on each body. If this was a feature that was brought to the stock game, it would probably be that each antenna (or scanning part) has a fixed scanning area for all bodies. Later parts would simply have a larger scanning area. But this is a mod and mods tipically introduce more complex concepts that cater more to advanced players, to challenge them; that's my personal view anyway. So in a way I actually like that resonant orbits are a thing that you need to account for - but at the same time, yeah, it might be too much for an average player to grasp that without an introduction/tutorial. Overall I'm pretty happy with the current system. In a later patch I might tweak the altitudes a tiny bit to avoid worst resonant orbit lockings. And next revamp would probably be when custom parts come one day (not soon, because I want to focus first on meaningful additions that expand functionalities, and then later worry about nice to have things).

v0.9.0 "Wayfarer's Waypoints" Added Waypoints Add, Edit or Remove Waypoints by right-clicking on the Map canvas Waypoints show in the Map UI, Flight view and in Map3d view You can define Waypoint names and colors, however in Flight and Map3d view waypoints will always be yellow (limitation of the game) Mouse-over Waypoint markers to show their name and geographic coordinates Toggle the side controls to permanently show Marker names and Geo coordinates Note: waypoints will be usually created on the surface of the celestial body, however if you create a waypoint on a body that isn't loaded (for example you're controlling a vessel on Kerbin, but you're adding a waypoint on the Mun), then the waypoint will be created at a certain altitude above the surface of the body (several kilometers). That's normal behavior. Mouse-over shows Region names and Geo coordinates Toggle the side "NAM" and "GEO" controls to activate showing of Region names and/or Geographic coordinates while mousing-over the Map canvas LAT/LON will display if "GEO" control is toggled Region names display if "NAM" is toggled, but only if the body is 100% mapped Other Chinese translations updated by @fengyuan0529 French translations added by @Olympic1 & @Spicat German translations updated by @Olympic1

Oh that's a nice idea, don't know why I haven't thought about that yet. I'll add it to the list. That's on the TODO list, but it probably won't come soon.

There are additional entries that are not displayed by default in the Flight category, so you can take a look there if there's anything that's useful to you: Lift, Drag, Lift to Drag ratio, Drag coefficient, Atmo density. But you already know about that probably. Weight seems like a good thing to have. It has been reported by someone that "Mass" that MicroEngineer is displaying is actually wet mass, not current mass. I remember being confused when I was first adding the mass entry - there are multiple mass values that the game is providing, but they didn't correspond to the masses that you would expect - dry mass, wet mass, current mass - but somewhere in between in some cases. Also, I don't know if this is an industry standard, but Weight in the TWR is always calculated as if it's the Weight at sea level, so it isn't adjusted by the actual value of gravity at a certain altitude. Again, maybe that's the convention that the space industry uses? I'll have to look at this a bit more to figure out stuff. Sorry for the slow replies, I've been busy lately with real life stuff and with other priorities. There's a Close Approach Distance/Time ("C.A. Distance1", "C.A. Distance2") available in the Target window, but you have to be in in the Map view for those values to update, yeah. MicroEngineer is pulling them from the game and those values are updated only when Map is open. Personally, I do all my rendezvous in Map view until it's docking time, but I understand a preference to do it in Flight view also.