diomedea

wow, picked! now, who could come, hoojiwana perhaps?

Re-opened at OP's request.

Re-opened at OP's request.

Re-opened at OP's request.

Re-opened at OP's request.

Re-opened at OP's request.

Re-opened at OP's request.

Re-opened at OP's request.

Re-opened at OP's request.

A good rule of thumb was to never exceed terminal velocity (Vt) during the whole ascent. The math for Vt is actually easier by using ballistic coefficient (Bc), so it goes as Vt = SQRT(2*Bc*g/ρ). Bc actually changes with Mach speed, and g changes with altitude; but none as significantly as ρ (the atmospheric density) that really changes a lot with altitude, and is the prime reason why Vt increases the higher the vessel is. In case anybody wonders, KSP actually shows mach and reentry effects (flames) based on a quite similar equation. Acceleration has no direct relation with the reentry effects, apart from being the cause for velocity changes with time. Managing acceleration during the whole ascent to always keep a vessel speed below terminal velocity is generally one of the factors behind a perfectly efficient launch.

Very true. Still hoping some conversion tool will come to correct all those wrong characters. In the meantime, I can only offer my ability as moderator to edit any thread/post, but need somebody with knowledge of those languages to provide the correct title/text. Of course, anybody should be able to edit his/her own posts in open threads, I may do with posts from users who left (and are still considerd of importance) and posts in closed threads, but please know I'll have to check with some translator tool the original and corrected text are the same - that's something taking a bit of time given the "unreadable" state of some of those posts. Should anybody wish to help recover such posts, please PM me.

Not only the line spaces don't work as expected. Multiquoting posts doesn't either . @ Hcube. There is nothing really definitive yet, apart the decision from Squad (not moderators) to close those language sections. At the moment, there's a lot of confusion due to all those threads out of the proper place where they stayed. To reduce confusion, threads no more current have to be let down. You may have noted however, not all were closed yet. Other languages had nothing more than a single thread with the old forum. For general discussion, that is certainly what will develop with any language (but those on their own subsections). But it's true there are specific subjects of interest deserving their own thread. One such, IMHO, is about translating KSP to other languages. Such threads however should not "belong" to any specific language. The General discussion threads will not be killed, there won't be any other "best thread" to make them go. Currently, opening new threads is allowed for any forum member, and I hope it could stay that way. But should the subject of any new thread not warrant a separate one, a decision will have to be made if its contents are to be merged in the "General Discussion" one, or the thread closed after it served its purpose. On the contrary, if a "General Discussion thread" brings an interesting subject, it may be evaluated to allow that subject to be the theme of one specific thread. Probably best with some suggestions from the international community. But one thing, certainly, to avoid even more confusion than is currently on this section, we can't let complete freedom to open threads on whatever as it was previously. I'm already having trouble to find the worthy threads in the mass, would like if users could still find where to post something in their own language. Without scrolling 6 or more pages to find the required thread. @ Gaarst. Hope the above also answers a bit to your valid remarks.

WIP, definitely. The unrecognized Unicode chars is certainly a major issue, was hoped a solution was found during or after conversion. None yet. Me and other moderators have already fixed a number of posts and thread titles by hand, this is certainly a time-consuming task however and therefore limited to threads still open. Users can edit their own posts, if they like. For some languages, we have currently no moderator able to write and correct those posts. Needless to say, languages based on a character set other than latin are the hardest, some posts almost illegible. For those, really hope some automatic conversion tool will come. The current structure is certainly very far from definitive. While entire subsections were closed and threads moved to the common International section, most old ones were closed but none deleted. Unfortunately, merging together threads opened on different subjects is never a good solution (would completely spoil every discussion), I'm not doing any of that. Each language (apart Spanish and Portuguese in their own subsections, of course) should end having one active thread only. Other threads, inactive and closed, will progressively move down the list. At the moment, those "single active threads" for languages previously in their own subsections (French, German, Russian, Polish, Italian) are not all defined yet. Me and other moderators are actively trying to steer discussion to happen on such single active threads. Many old threads in the now closed subsections were pinned ones, and still they remained pinned after being moved. Some are still necessary, but I'm already removing pins from others. Currently there is need to keep some pinned to help discussion steered to them, but in the end, no language thread will enjoy a different status (like pinned). As could be seen, is quite a lot of work, and definitely requires some contribution from the community (discussions must resume for open threads to stay at the top).

[quote name='GoSlash27']Mods, I looked through all these pages and I didn't see an answer to this question (apologies if I missed it): Will the new forum have LaTeX support? If not, will it have some sort of support for robust mathematical equation formatting? We tend to kick around formulas a lot when discussing rocket science and the old setup was lousy for that. Thanks, -Slashy[/QUOTE] [quote name='Sanic']I agree, it was really hard to make subscript/superscript.[/QUOTE] Subscript/superscript is already available in IPS4 (checked from the test site), even easier to use than on this forum. Full Latex support isn't present currently. It may come later, as additional features will certainly be added. But please know a project to add Latex to this forum (vB4) was already in development more than one year ago, and ultimately was shelved (believe the benefits were not considered as good against the added complication and admin burden). Let's hope for IPS4, Latex could be a simpler addition to make.

As somebody correctly noted, there was already another thread about this very subject ([URL="http://forum.kerbalspaceprogram.com/threads/139815"]here[/URL]) before this one started. And, as somebody correctly noted, the title of this one is misleading (instead of confirmed, the truth is it was proven false). Can see no better fate than closure for this.

Not really a Kraken. If that miner had struts keeping the ore tanks in position, those would not be wobbling and no destruction would occur (tested with a full Ore load). Allow me to explain. KSP, though not perfect, has some realistic physics. Among else, physics routines compute at each frame the forces between parts. When those ore tanks are full, their mass drastically increases (by 3 tons each!). Those tanks are connected to the ship only through the top joint, to a RCS tank each. That joint is robust enough to keep the empty tanks (0.5 ton) but not the full ones (3.5 tons), when the ship accelerates. The solution is really to use struts connecting the base of each tank to the rest of the ship. I put 2 struts for Ore tank (8 total) connecting the Rockomax 2.5m tank at the base, and that modded miner ship works no problem.

[quote name='Vanamonde']Oh, no. I am totally not jealous. :mad:[/QUOTE] Oh, yes. That's something to be jealous about :wink: (certainly I am a bit). Congrats Bill Zarr, what an achievement :).

Yes, reported on the tracker less than 30 mins after my previous post.

Please note, as Edfred's pictures clearly show, the aerodynamic forces (drag and body lift) are from the fairings, misplaced, but none shows about enclosed parts. There was a recent report about this very issue in Support, detailed enough to allow verification; following that, the issue has already been reported by me and acknowledged by developers, I'd hope it will get fixed for KSP 1.1 if not earlier. Unfortunately this discussion should have been conducted in Support, this isn't the place and I invite any further relevant posts be done in that thread to keep consistency. Thread closed.

Thanks for your detailed explanation, it would have been pretty hard to get what the issue is without it. But, at least IMO, you made a great description of a bug with TileCreator. It is the proxy set by TileCreator that should also set the folder path, exactly as it works with desktop shortcuts. Could be KSP.exe could be modified to change to its install folder earlier (but please know, that file is actually a Unity 4.6.4 runtime exe, as such there may be very little Squad may do to change its behaviour). Other software expect to access files from the folder the system has set for them, so would not work at all if started with the proxy.

Believe you are trying to download from the KSP Store. I see it currently works fine for me, and was working before; but probably you tried to download at a time when that server migration was relevant. Could very well be you keep having shown a message from your browser cache, instead of it trying to fetch the current page. Refreching cache has been an issue even recently from the server side, in this case may be refreshing the client (your browser) cache is what's required for you to solve the issue.

Please know it's practically impossible to provide support without being able to diagnose your issue(s). This thread was moved to "Support (unmodded installs)" to receive attention from who's able to help. However we need knowledge if any add-on was installed (provide list, please); need to check your savegame (upload and link persistent.sfs); also provide the output.log and follow any other suggestion listed (as appropriate) in the support guides (unmodded and/or modded). But before even being able to look at your issue(s), can confirm changes in 1.0.5 have an impact with most ongoing career games. Squad has never guaranteed save compatibility across versions, because any of the many changes applied with each new one can screw the old saves. It could be possible to find exactly what impacts your game, and to suggest ways to solve specific points; but consider good practice to finish a career game with the same KSP version it started with, and start a new game with each newer version (reason why I'm keeping separate KSP installs with each version of the game).

Good find, checked and can confirm. Would rate this a bug, will be reported for action.

Not surprising you miss that part: the TechRequired in its config file changed, was = advAerodynamics in 1.0.4 but is = specialisedConstruction in 1.0.5. Therefore the part isn't unlocked any more until you also unlock specialised Construction. But if you need it for crafts already built in your game, take what I wrote above as instructions to modify that config file (fairingSize2.cfg, in GameData/Squad/Parts/Aero/fairings) in your install.

Can't provide a sure recipe about best settings, each system and install (if not game situation) may require different ones. I would actually check the performance tab (from Debug menu) to find the FPS ingame, and if too close to the Minimum FPS, would try tweaking. What I can certainly tell, the "Max Delta-Time per Frame" controls the worst case condition. Normally KSP should complete all physics calculations within the time for the next frame to display. Let me say that is when the time indicator is green. The actual FPS shown on the performance tab would then be higher than the minimum. When running out of time, KSP starts to delay the next frames. That setting tells how long the interval between frames can arrive. Of course the longer the interval, the less accurate and less responsive KSP becomes. Less accurate makes KSP choppier, less responsive means any input is affected by lag. I'd be safe to tell then the time indicator shows yellow. The actual FPS drops to the minimum, and the minimum FPS = 1 / "Max Delta-Time per Frame". In the extreme, calculations require even more time than the Max Delta-Time allows. I am of the idea (but can't confirm without seeing the code) frames may actually be skipped at that point. Red time indicator should be representative of this situation. But to stay on the simple, a lower Max Delta-Time setting (e.g. 0.03 s) makes for a very smooth, accurate, but also slow-motion run. It could be best when flying a complex vessel with lots of parts, to avoid physics forces to get too large and bring spontaneous disassembly. Certainly the indicator would be almost always in the yellow. A higher Max Delta-Time setting (like 0.12 s) allows large intervals, so KSP is less accurate and responsive, but also would run faster. As the Minimum FPS is then allowed to be lower, a green time indicator would more probably show; however the number of actual FPS doesn't increase, only the time between each frame. Then, the setting is more affecting our experience with the game, rather than solving framerate issues. We can't exclude physics routines in KSP, that would be a way to reduce the time taken to perform calculations. Some parts are excluded from physics interaction (their config has "PhysicsSignificance = 1") to diminish the number of parts requiring calculations. The scenery, beyond graphics rendering, always requires CPU time, so limiting scenery elements is always useful. Deleting debris helps, showing data (either from stock KSP windows or add-ons) requires more CPU time. The real improvement remains the ability to use the full power of modern CPU, that Unity5 should allow with multithreaded physics.