Jump to content

EverydayKerbonaut

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by EverydayKerbonaut

  1. more like, the starter course was raw, still waiting for drinks. I actually decided not to get SOTF at launch because I thought I would bee too busy on KSP2, but since then I rectified that mistake and steam now say I play that 3x more than KSP2
  2. no i think you are missing the point. this needs to improve the formula's used for calculations and have time passed as a factor. this needs to be simplified so a ship can be calculated moving at 10x, 50x, or 1000x you should not need to watch it do calculations for every frame, since time warp is a thing, and inactive vessels is a thing, the formula used for time warp simply needs to see if the craft can obtain a stable rotation in the time that passed, or calculate movement change in the time passed and current heading, velocity and all that. now as for physics, it needs to simulate larger chunks of time as a single calculation so if it takes 5 seconds to simulate 1 second worth of action then instead it is smart enough to group every 5 actions into a single simulation and achieve a steady 1 second to simulate 1 second worth of action. the physics formula needs to adjust to allow the steady passing of time, now if physics formula allows for larger chunks of time to be calculated, then it will also work with warping. one formula that fix lag and allow time to move at the correct speed, and also allow for it to function under time warp as well. oh and for multiplayer they will need to reduce the amount of info sent over the network and most likely its simply the vessel layout, and initial orbit, then only changes to orbit and configuration
  3. got my single craft deplorer of 12x units of my "Com-Links (because space needs WiFi too)" into orbit. this is a lag monster. it use 12 XL cargo bays placed alternated rotated 180 so they open to different sides, have solar on the underside as well for when ion deep space unit is attached. its motor is docked for easy replacement, this is the 3rd stage, had first stage to get off planet and 2nd stage was same engine with side mounted drop tanks, here's the Com-link here's a view of a single cargo unit, the design allows the Com-Link's solar panel to be used as well, increasing the overall available power for long ion boosts. Previously deployed 3x into KSO with one above space center, and 3 in orbit around Mun ToDo: - rescue Tim C Kermin who is stranded in low Kerbin orbit. - send up the Deep space engine and dock onto craft - send to Mun orbit, waiting for Mun to be "radial in orbit " (closest to sun), then escape into solar orbit on lower than Kerbin orbit, - deploy Com-Link's at equal spacing in same solar orbit as Kerbin - retire Deployer by raising orbit to match moon's radial out and scrapping it on Mun by means of high velocity impact Long term goal: complete Com network by deploying 3x Com-Link into orbit around every planet and moon
  4. So there is bugs, yea we expected some. but looking at the most common bugs raises concerns that they need to go "back to formula" see what outers think is simply a annoyance bug points to much larger issues. and there are a few "gotcha's" First off is simply user interface, how key and button input is handled. but also how it is processed. an example is when writing a ship's name, M key takes you to a map view. this shows inputs are global instead of mode specific and/or the mode swapping is not handled properly. then there is the lack of response from interface when crafts of extreme loads are being launched, lets say you get time to pass once every 10 seconds, pressing esc you wait up to 10 seconds to see map. this is first a ticking issue, shows the menu is not calculated independently and have to wait for the world render cycle to complete before it is acted upon. the menu us a slave function to rendering. this should not be so. next there is time itself. time should pass once every second, no lag or load should reduce that. any function should be a slave of time and use "time passed since last action" as part of its calculations. instead of relying on each action's output to calculate the next, formula's should allow passing of any amount of time and be able to adapt to those. an example is rotating to a position over time, instead of needing to take action at every passing unit of time, a simple formula can be used to see how far it would be towards its goal giving this amount of time passed. so if a craft would need 8 seconds to rotate from prograde to retro, and you are on 10x speed, then simply assume that in the passing of 10 seconds it made the rotation and set it as such, and deduct the propellant it would have used for that. simple this will fix rotation and acceleration not functioning over time warp of any kind. then as for physics, this should be simplified where you can pre-calculate it take the assembled craft in its current state, then do a linetrace from it from every direction, get the relevant angle of the hit and assign a value to it. do an additive overlay for control surfaces and other moving parts. now simplify it into center of drag, and center of mass use this along with speed to calculate everything else needed, bit you now get to treat it as a single part and not 100's of parts, and only needs to recalculate if the assembly changes. you can further pre-calculate each part and in the final calculation use those as an is visible basis. you're welcome. the current setup looks to prioritize visual priority of execution should be: 1 - time 2 - interface input and response 3 - control input and response 4 - vehicle movement 5 - actual rendering, here going LOD or even complete basic Low poly will be acceptable as long as time keeps passing, input responding and actions happening reliably. next assembly again looks like rendering is prioritized. it looks like everything is as movable and lighting is dynamic, this is wrong and even bad for performance. treat every placed object as static, use directional light and pre-bake light as much as possible, then calculate dynamic shadows for the single combined model. also VAB should have better uniform lighting with less shadows, it's a rocket factory after all so can assume its getting at least 4x light from each side and from on top, this makes baking light easier. as for placement sockets, sure snapping to anything is a function now, but how about if we mid-mouse-button select something to then prioritize snapping to the object that we are focusing our view on? also you dont have to make an entire assembly as moveable to attach it, simply rendering a 2d version of it for the current view and using a depth offset, use that as a card for the moveable part, and hide the static once you render the card, then you dont even need movables. there is also collision issues with many parts, the simple solution is to do a visual interrace and get tangent at location, use that instead of collision, so a surface mount item will mount to the visual outer surface. these are just a few bug fixes and performance booster i would have looked at. again this is speculative and only the opinion of a play test, and I have no actual knowledge of how the code actually functions
  5. I also experienced this, looks to be related to the message that pops up saying shim is on collision course with Mun. I found that EVA with one Kerbal you can leave and grab ladder, but if you switch away and get the on collision course message then can no longer grab. it looks like the Kerbal thinks its a dead ship and refuses to interact with it, switching to ship it still functions
  6. Have a vehicle with extendable ladder. ladder extends beyond landing gear. while landed on Mun EVA, climb to tip of ladder (under terrain) leave ladder, Kerbal fall to Mun center, then slingshot out at incredible speed then exit solar system have been able to reproduce using different vehicle builds. landed on Mun, Bob on ladder penetrating ground https://prnt.sc/FLp9Eur9xU-w Bob on bottom of ladder, camera also glitch trough ground https://prnt.sc/gEItr5ZdDQ91 Bob @ 283 242 m/s https://prnt.sc/HA8ui4p1M3-N escape trajectory https://prnt.sc/jDWxBhD5loC_ also have save file
×
×
  • Create New...