Jump to content

Poodmund

Members
  • Posts

    1,987
  • Joined

  • Last visited

Reputation

4,107 Excellent

Profile Information

  • About me
    ReStock normie

Recent Profile Visitors

28,412 profile views
  1. The HG-5 has an antenna power of 5.00E+06 in vanilla KSP. ReStock does not change this, some other mod you use must be doing this.
  2. Short answer, no. Long answer, this mod is just a bunch of configs and textures. If you feel that this mod has stopped functionality in your install, the only thing it could be is the bundled MiniAVC.dll file that was was widely distributed back in the times of KSP 1.3. Either, delete the file from your install (GameData/PoodsOPMVO/MiniAVC.dll) or download and install the mod Zero MiniAVC and give that a try. You're using a mod that is listed as compatible/to be used with KSP 1.3.1 in an install of KSP 1.12.5. It might be a dependency of the mod Outer Planets Mod Volumetric Clouds but this is more so an issue for the creator of that mod to highlight any issues with installing this mod in an instance of KSP 1.12.5.
  3. Congrats, Jonny. You're a testament to the greatness of the KSP community! For the reference of CKAN users out there who may have previously had mods like FAR (Ferram Aerospace), Photon Sailor or Infernal RO-Robotics installed, and now want to install TweakScaleRescaled, CKAN will throw up an incompatibility issue due to the already installed TweakScale-Redist dependency conflicting with TweakScaleRescaled-Redist. In this case, before installing TweakScaleRescaled, uninstall TweakScale-Redist and install TweakScaleRescaled-Redist, all in one go, by unticking and ticking them, respectively, and then clicking apply: Once replaced, you can go and install TweakScaleRescaled without issue: ---- Happy scaling!
  4. And that is exactly what was said in the OP. ... Anyway, this whole statement of feeling/concern was expressed almost a year ago now. The sentiment has not changed as the state of KSP2 has not changed all that much. The recent posts here are not really on topic for what the thread was intended for. Lets let sleeping dogs lie, eh? For now...
  5. Here is a link to the discussed patch: I assume the player will put a Docking Port Jnr on the top and a Spark engine on the bottom node so that is what the patch uses to offset the CoM of the M.E.M to try and neutralise RCS thrust torque. This doesn't completely zero out due to the bad design and lack of consideration to the RCS thruster placement on the part. @Chris Bolland, have you considered using Tweakscale: Rescaled to increase the size of the M.E.M? https://spacedock.info/mod/3514/TweakScale Rescaled I wouldn't normally recommend using Tweakscale but JonnyOThan is doing a great job in cleaning up any mess from the legacy implementations of the mod.
  6. Considering this is the recognised topic on this, I'll cross-post my thoughts from elsewhere: I think CommNet provides a challenge for controlling un-Kerballed craft in different challenge steps and occlusion plays a part, differently, at each of these steps. Progression Step 1: Low Kerbin comms - Setting up a low-to-medium altitude relay constellation to allow for communication around Kerbin - Occlusion feature impact: Large (Kerbin being in the way of the KSC has a massive impact) Progression Step 2: Munar/Minmus comms - Setting up a moon based constellation to allow for probe communication on the far side of the moon - Occlusion feature impact: Medium (you are usually already captured in orbit but would often lose comms signal on the far, dark side of the moon) Progression Step 3: Interplanetary comms - Setting up comms networks to communicate at large distances - Occlusion feature impact: VERY low (typically, the arc angle at interplanetary comms distances is incredibly minute and occlusion by other planets is easy to mitigate) I know Intercept want players to accelerate to Progression Step 3 as quickly as possible in comparison to typical KSP1 gameplay but I feel that a lot of people spend a significant amount of game time in the first 2 steps, where occlusion plays a big factor. Therefore, I would say that for CommNet to be a successful implementation of gameplay feature, it should really include the core mechanic of occlusion. Without occlusion, I honestly didn't think CommNet was working in KSP2 before I learned that occlusion wasn't implemented. Although I see this being a long way off, time wise, this is absolutely the right perspective on this issue.
  7. ReStock does not touch the EVA jetpack. I would advise you to validate your game file integrity via Steam to make sure that you have the file installed.
  8. The difference in shape (relays being mostly static and cumbersome) was an interesting design issue for the player but the whole direct vs relay mechanic was terribly communicated to the player and more often that not just left players frustrated (see the number of Reddit threads where people were asking why their vessels weren't passing communication through). Add on top of that the fact that direct antenna didn't add their strength to the relay capability and it just caused a world of confusion. This is my opinion, as someone who liked CommNet, even more than RemoteTech... but CommNet had some real big flaws that were mostly due to a severe lack of communication to the player.
  9. I think CommNet provides a challenge for controlling un-Kerballed craft in different challenge steps and occlusion plays a part, differently, at each of these steps. Progression Step 1: Low Kerbin comms - Setting up a low-to-medium altitude relay constellation to allow for communication around Kerbin - Occlusion feature impact: Large (Kerbin being in the way of the KSC has a massive impact) Progression Step 2: Munar/Minmus comms - Setting up a moon based constellation to allow for probe communication on the far side of the moon - Occlusion feature impact: Medium (you are usually already captured in orbit but would often lose comms signal on the far, dark side of the moon) Progression Step 3: Interplanetary comms - Setting up comms networks to communicate at large distances - Occlusion feature impact: VERY low (typically, the arc angle at interplanetary comms distances is incredibly minute and occlusion by other planets is easy to mitigate) I know Intercept want players to accelerate to Progression Step 3 as quickly as possible in comparison to typical KSP1 gameplay but I feel that a lot of people spend a significant amount of game time in the first 2 steps, where occlusion plays a big factor. Therefore, I would say that for CommNet to be a successful implementation of gameplay feature, it should really include the core mechanic of occlusion. Although I see this being a long way off, time wise, this is absolutely the right perspective on this issue.
  10. The UI is probably the main gripe I have with KSP2 as of the v0.2.0 release... 1. And that is mainly down to the font choice in some areas. I would like to say that the main, general font that is used throughout the game is REALLY nice, however, the pixel-y, console style font is very hard to parse and I find it hard to read. There are also some areas where some of the text is being displayed too small at a reasonable resolution. I would suggest that a minimum total pixel height be ratified by the UI team to ensure that text cannot be displayed too small on the screen (stage dV panels in the VAB) and also the option to toggle to replace all instances of the pixel-y, console style font to be replaced by the default font used elsewhere. To be explicit, offer a toggle to replace all instances of the fonts 'SB Liquid' and 'SB Websnap' with 'Realtime Rounded', would be my suggestion here. 2. Also, as mentioned elsewhere in the thread... SI units matter... and case matters for SI units. To add to the issues raised in this thread: I have annotated this image to supplement the posts in the above thread. In addition, the unit case on the navball speed and altimeter are incorrect. Hopefully by collating all the posts about these issues it can be cleared up. 3. Also... it would be FANTASTIC if when you mouse-overed a data value, it presented the raw base value as a tool tip. For example, hovering over Kerbin's SMA presented a tooltip of 13,599,840,256m. 4. Lastly, there are areas in the UI textures that feature dithered (pixel checkerboard) backgrounds. I presume this was done as a stylistic choice but this adds to the difficulty when reading the UI. It would be preferable, to me, if these dithered areas were instead, either, solid colour or represented as a gradient.
  11. This bug still persists in the v0.2.0 FOR SCIENCE! update. Unit case matters.
  12. Version: KSP2 v0.2.0 For Science! I've pulled issues from Kerbin, Moho and Minmus with annotations: EDIT: In addition to my in-image notes: Eccentricity should not be stated in units of degrees, it is unitless. The Velocity metric under the Orbital Characteristics section should state 'Orbital Velocity'. The Gravity stat is being listed as factors of 1g but are being stated as m/s^2. The body masses are out by a factor of 1000 as stated in the image but I've also determined that the body mass differences between KSP1 and KSP2 are due to the difference in Gravitational Constant values being used by both games; KSP1: 6.67408E-11 KSP2: 6.67430E-11 As body mass in KSP2 is calculated using G, gEarth (9.80665m/s^2 - KSP1 uses the same value), gASL (of the body as a factor of gEarth), and the body radius... the difference in G between the two games is affecting the mass and density values between the two. Not sure what kind of knock on effect this has with other orbital or gameplay parameters. It definitely is an argument for the need of a separate KSP2 Wiki though. Also... it would be FANTASTIC if when you mouse-overed a data value, it presented the raw base value as a tool tip. For example, hovering over Kerbin's SMA presented a tooltip of 13,599,840,256m.
×
×
  • Create New...