swifthands

I rushed to check if i bought the game before April 2013, My order confirmation from the store says October 2012, i had no idea so much time passed... man... at that time it cost 18 USD, we came a long way... and considering the price it has now, and the fact i get free DLCs, it must be the best gaming deal i ever had. Kudos SQUAD for keeping your promise. EDIT: Had a quick thought about it in my head, I want to announce here that since i only had to pay 18 USD at the time, considering the amount of work you invested in this game and the current game price, i am going to purchase a DLC even if i can get it for free, i think loyalty from the devs for such a long time deserves this, thank you for an amazing game and years of fun!

servers down? even the status page cant be reached... what happened?

Thank you i see now there are 3 cover parts for the 3 different engine sizes

are there no engine covers when making stages as the stock and other mods have? when i have a decoupler under an engine, it is not being covered am i doing something wrong or this mod doesn't use the automatically generated engine covers?

you have an option on the steam client to not automatically download and update games \ specific game, do this for KSP if you find this feature to be problematic...

Thank you so much for the effort in putting those flags together!

Thank you very much for this awesome mod, I have a request if you dont mind - is it possible to have the mods in this pack separated into their specific related parts \ capsules etc? for example if i want only one type of soyuz, or some other craft, but not the rest, since this mod adds so much content (120+mb), its hard to keep track on what is what in case i want to manually add the parts i want for one specific rocket \ craft type. that would be really great if you could do that! and i would really appreciate it, another more simple option that will also work, is listing all the files required separately for each craft, so if we want to do it manually we know what specific parts are required to make each set work properly without missing any dependencies etc.

*seeing kerbals stranded in jool and barely making it to jool with 2 kerbal command module* *knowing i need to build a better more complex rocket to rescue the stranded kerbals* .. .... ..... It just occurred to me how much i love giving a good speech!

hey mate, thank you for your input! In regards to the scenario of players hanging outside kerbin, as i see it in theory is that you login into a server, or rather a "domain" if you will, this "domain" is nothing more than a server cluster, the domain player limit can never exceed a single planet max player count possible, so even if the domain is full, and all players on the domain choose to be on kerbin sphere ( \ server), then they will be exactly the max players possible for a single planet, so no scenario of players "pending" outside kerbin without a pending system possible in space travel really. it could be mitigated if you make the planet servers completely unrelated to one another, and are all load balanced between a huge cluster of every "currently available" server of that planet you are trying to get to, the problem with doing this is the fact you lose any persistent value in the gameplay, you could leave kerbin with your station on it, that was on domain 1 server 1, and when you get back there after a trip to the moon, you actually log in to domain 11 server 20 etc, and ofc - in this case, the station you made will not be there, as its not the same planet server you constructed it on... so having ONE domain which cover all planet server for THAT specific domain, can give you persistent data. physics warp can be dropped for multiplayer imo... flying anywhere in atmospheric flight to an extent that actually means something will take a lot of time even with physical warp... same for driving, same for waiting those few minutes for your capsule to touch down after you deploy parachutes, people can live without those minor boosts to speed. real time warp on the other hand, should be managed on the low scale of one planet between players, I am sure there even more solutions that can be found to better meet the complexity that exist on the low scale time warp as well... maybe having 70k alt of atmosphere and above atmosphere set as different synced \ unsynced regions of that same server instance. maybe a 3rd layer of sync \ unsynced can also exist above 300k alt etc etc... just to provide some more layers of flexibility and less dependency on the entire player list on that same planet server for doing or not doing time warps, ofc whoever is with you on that same layer \ ring of sync must meet time warp with you as stated before. i believe the real issue is how to deal with interplanetary travel time warping, as the real problem is having people agree to timewarp on their orbital operations for the length of time required to do a time warp, ie: player 1 traveling to jool, player 2 traveling to the mun. having a group of people agree to enter timewarp to complete orbital maneuvers is easy. having them agree to warp for 2-3 years so someone else can reach jool, is a serious issue... this is why my idea completely ignore the interplanetary realm, yet very much keep it as part of the game almost seamlessly. i think this method could work, or at least it sounds like the best plan on how to go with it (thus far). i am eager to hear more opinions on this method \ ideas of other methods as well.

how is your craft recharge electricity? do i miss something?

Not sure i follow you... what large amount of data needs to be transferred? the rendering and positioning of the crafts in the server will be done client side, all the server need to do is transfer 3d grid location of a craft, and the parts names that make up this ship, what is it? few KBs? besides, a more complex data staging can be done with middle servers keeping persistent info of each planet server, and the client will fetch data from these mid servers rather than from the main planet server and impact performance, in terms of infrastructure and data transfer we have already more than enough solutions to deal with it, even on massive player counts and data transfers. the real issue here is time warp, which i think what i suggested in my previous reply (page 3), is a good solution to dealing with time war EDIT: sorry i think i understand what your point was now, you may be right, if it is proven not to cause too much strain on performance to have all the planet "sphere" regions on one server, then i guess the concept of planet local scale sphere separation can be done in code, once you enter the regional sphere of a planet, you are then synced in that bubble with the players in it... splitting it to server per planet with connecting and disconnection from planet servers as you move can only allow for greater player count in theory. read my previous reply on page 3

How about this: each planet is basically represented by a server, the universe is a cluster of servers, once you enter a planet's predefined sphere of range, you are connecting to a server basically.... now to keep things simple - when you connect to a server on a user POV, you choose a server name as you would in any other game, but this "name" represent a cluster of servers (this is so the same people can go back and forth from planet and meet the same constructions they built \ other people built there. now as for time warp, i think we all agree that on a small scale, time warp is doable, a basic all = active basis, time warp priority is dictated by the lowest value among the players in that same planet server, so if 5 people set warp to >>> and one player set it to >>, the time warp would be >>, this system is pretty simple in theory, no need for vote prompts, and the coordination on when and how people should warp can be done on a chat system (relevant for that small scale area of a specific server). how we deal with planetary travels? i think of having two time warp systems: 1. client side interplanetary time warp 2. multiplayer - small scale - planet specific (server) time warp (shared with everyone on that same planet server). now these two time warps can be controlled separately. we consider that most of the activity will be done within a relevant planet's sphere of influence and not during planetary travel (and yes, this is the downsize, you may wont be able to build a space station with a friend as you travel to duna.... i say, "big deal", you can build it when you are both in duna). now how it works in theory: the client side interplanetary time warp warps only the solar system itself, the only thing changes are the locations of planets and moons in their solar orbit, as this environment is warped (completely separated from the online time scale) your craft and the planet server you're in move in unchanged real time scale - so no warping at all. yes, it means completely separated people can have their solar system oriented in a completely different way, the whole "existence" of the solar system is very much client side for that matter. what it means in terms of simulation impact? boo hoo the planets wont have a true facing based on their rotation as they should have if the actual time was warped for several years in interplanetary travel, they will however, have their orbital position as far as you are concerned. so say you and another friend plan to to a trip to duna from kerbin orbit, you both position yourself for the escape burn, you separately set your solar scale time warp to match your desired burn window, and then simply burn to escape... once you leave the planet's sphere of "online realm", you are effectively disconnected from that planet server, and enter some sort of basic online data I\O, what you do with it? ill explain. lets say you warped the solar time warp (client side), to the right window in order to escape from kerbin to duna. your friend got the exact same window, but his is actually two years or more after the window you have in your solar scale. you can have the option of matching a player's solar time period, since the position and pattern of the solar system is known for each given moment in time, you can just match your time to be aligned with another player's solar system "time period", so they are effectively matching one another... why? its convenient, rather than setting it manually for each and every player - if one player set his to the right window, great, the rest can choose to sync their solar system with his, or not... it changes nothing. but the good thing here, is that a group of players can choose to sync their solar system AND their time warp during the interplanetary travel... (if they go to the same location, burn to escape at the same time, it may be something they would like to do, and ofc - they can choose not to). if they do sync their solar system and interplanetary time warp, they will "appear" (connect) to the duna server at the same time more or less... if they dont, one can choose to warp his travel faster for example - and will connect to that planet when enters the duna's sphere of influence... (at which point he is subjected to the local time warp priority for small scale warping operations (orbit, deorbit, escape etc etc). and lets imagine that the second player doing the same trip to duna chose to take his time, move some parts around in his spacecraft, maybe using a tug to undock and dock a section into another location... it doesn't matter, as its all done client side in interplanetary travel \ environment. and once he finally reach duna, he will be connected to duna server same as the first player. downside? yes it means you can both escape kerbin on the same trip to duna, and each one of you will connect and "appear" on the duna server at a different location, the first player to connect to duna will most likely be further "down the road", completing his capture with the planet etc etc. does it matter in terms of gameplay? i personally don't think it does, and it does solve the issue of warping on large time scales. and with the option for people to choose to sync their client side environment (solar system) with a player of their choosing in an instant its important to mention that the sync of solar env can be done in two manners: 1. snapshot sync - you want the general position of another player's solar system state and maybe even warp more on your own from there. 2. locked sync - it will do a snapshot to sync the time period and "picture" of the solar system state on both players, and will also subject the time warp on that solar system scale to be the same as the "close scale" but only between these two players (it can be 3-4, its basically done by choice of a player to be synced with someone else or not, the other side can accept or reject the request) - and again, at which point, the mechanics of the locked sync players for solar system scale time warp - will work exactly like the one for players in the close scale planet servers (lowest warp scale among the synced players is the one active - simple). any thoughts? (and yes, i know its long, i apologize - as well as any mistakes that may be in the text, English is not my native language)

please check your PM inbox - just sent you a PM

can you please post a clean list of the parts you load? just put a list of all the dir names in the /parts folder also post your full HW specs here if you can. i want to do some testing and comparisons.... i use a lot of mods and my loading time was always below 1min... something is clearly wrong with the load times on your end, and i think the problem is not as simple as HW specs.

Built a carefully designed rocket, proper asparagus staging, every bit of weight was taken into account for maximum T\W ratio and efficiency at every step. the plan was to perform a mining operation with a kethane fuel depot orbiting duna. i constructed the space station that is supposed to act as the fuel depot. sent 4 lander missions to dock with the station before starting the runs up and down from duna to stock the station kethane tanks. after all was done and ready to begin the actual work, i undocked one of the 4 already lined and ready landers from the station, carefully performing the ascent and watching how my marvel of design that is my lander, performs everything perfectly. drogue chute deployed, slowing down to final breaking burn and touchdown, a perfect landing, solar panels deployed, kethane tanks open and ready. deploying the kethane drill. drill deploys upward towards the sky........