Beiträge von Schnatta

Zitat von catchie

wie du EVE mit dem Astronomer's Pack verbunden hast.

Wie ich schon zu schroben gedenkte - installier das alte eve auf einer 1.04 mit einem Astronomers Pack, kopier den BoulderCo und Envoiremental...Blabla Ordner aus der 1.04 in die 1.05 und fertig ist der Lack.

Zitat von catchie

Aber irgendwas stimmt da nicht

Wieso?

Finde ich mal interessant das Thema. Denn ich versuche schon lange die wirklichen FPS Killer auszumachen. Gerade da ich sehr, sehr viele Mods einsetzte, komme ich irgendwann an den Punkt an dem das Geruckel los geht. Und das mit einem hochpotentem System. I7-6700k und GTX970. Mit dem neuen System wurde es zwar merklich besser als auf meinem i5-2500k mit GTX670, trotzdem, ab einem bestimmten Punkt wird es wirklich unspielbar. Ursprünglich hatte ich auch reine Physik Mods oder eben Mods die im Hintergrund was rechnen im Verdacht, dann wieder Grafikmods, aber weder noch hat allein für sich ernste Auswirkungen auf meine Framerate. Sobald ich aber anfange viele Physik Mods neben vielen Grafikmods einzurichten, komme ich in Probleme. Während viele Physik Mods oder viele Grafikmods jeweils für sich völlig unproblematisch sind. Es scheint meiner Ansicht nach mehr die Kombination aus beidem zu sein, denn ein bestimmter Mod oder bestimmte Mod Typen.

Ja, einfach die gewünschten Texturen aus dem Default Ordner des KSRPC in den Default des Texture Managers. Fertig.

Platenoberflächen kommen mit dem Astronomers Pack nicht mit. Aber Du kannst Dir die Texturen die Du willst aus dem KSPRC ziehen und einfach in den TextureReplacer Deiner Installation packen. So hab ich mir meine Grafik Mods aus 3 oder 4 Mods zusammengestückelt.

Ich werd's wohl nicht mehr ganz zusammenkriegen wie ich es gemacht habe. Es war schon eine ziemliche Fummelei. Mit dem neuen EVE kannst es aber knicken, nimm ein EVE aus der 1.04, das läuft in der 1.05 unproblematisch. Damit läuft dann das Astronomers dann auch wieder. Bei Jool und Eve auch, aber ich bin mir unsichr wie es bei anderen Himmelskörpern war. Hab es ja wie gesagt nicht aktiv. Texturen tausch ich sowieso selber, meine Config ist ziemlich verstrubbelt und viele Veränderungen hier und da. Wie gesagt, für den Astronomers, versuchs mal mit einem alten Eve, das sollte gehen. Beim Install der Astronomers Pack Einzelkomponenten einfach probieren -> starten -> wieder probieren -> wieder starten...usw.
Irgendwo geht ein Astronomers Pack rum was auf die 1.05 angepasst sein soll, funktioniert aber nicht, ist die Hälfte nicht angepasst und es ist total buggy, noch schlimmer als das Original. Wenn Du noch ein laufendes 1.04 hast mit Astronomers Pack, nimm einfach das Boulder Co und EnvironmentalVisualEnhancements Verzeichnis und schieb es in eine 1.05 mit Scatterer. Dann läufts eigentlich.

Nervt zwar, aber lohnt sich halt auch. Sind zwar nur mit dem Handy abgeknipst, aber ist halt sexy. Sowas kriegst ohne Mods und Fummelei nicht zu sehen. Muss gestehen, ich versteh nicht wie man die Vanilla hier manchmal auf's Messer verteidigt.

Ich mag das Astronomers Pack lieber, ich habe mir das mit eigenen texturen noch ein bisschen zurecht gebogen. Aber das Problem, dass der RAM an seine Grenzen stösst bzw. die FPS enorm einbrechen, das hab ich auch. Allerdings benutze ich noch den alten EVE aus dem 1.04. Der neue der seit 1.05 raus kam ist mit den Rändern die die Wolkenlayer um die Planeten hinterlassen einfach nur hässlich. Die Screenshots zeigen meine Config die ich mir aus etlichen Mods zusammengebastelt habe.

Da ich aber Content bevorzuge statt EyeCandy verzichte ich derzeit auf EVE ganz. Hab nur den Scatterer (ohne Meere), DistantObject und den AmbientLight Regler und meine Kerbin textur. Damit sieht es noch halbwegs schick aus und die Leistung ist kaum runter und RAM Verbrauch auch okay. Mit meinen 120 Mods kann ich mir Wolken nicht leisten, leider. Egal wie Hammer es aussieht. Wird wirklich Zeit für die 1.1. Hab meine fertige Config schon an der Seite liegen.

\GameData\scatterer\config\PlanetsList.cfg

Bei jedem Planet mit:
hasOcean = true
auf
hasOcean = false

[wise=info]Originalthema: https://www.kerbalspaceprogram.de/index.php?thread/3480[/wise]

Da ich recht modfreudig spiele und auf sehr viele Mods nicht mehr verzichten mag, habe ich mit der zeit einige Erfahrungen sammeln können. Ich spiele derzeit mit 120 Mods recht stabil und auch mit einer annehmbaren Framerate von 30-50 FPS und fast permanenten grünen Physics.

Mit Linux habe ich keine Erfahrungen, alles folgende gilt also für Windows. Um anständig gemoddet zu spielen sind erstmal 8GB und ein 64 Bit System pflicht damit sich KSP auch wirklich die benötigten 4 GB RAM nehmen kann. Ausserdem kann der Prozessor nicht schnell genug sein, grafikkarte ist eher irrelevant, da fast alles über CPU berechnet wird, die Grafik ist eher rudimentär und selbst kleiner Grafikkarten sind eher unterfordert. Ich habe derzeit einen i7 6700K mit 4.4 GHz laufen, da geht schon was. Aber auch auf meinem i5-2500K läuft KSP immer noch anständig, wenn auch mit 10 FPS weniger und die Physics sind meist gelb. Wichtig ist - wer seine CPU übertakten kann, tut das ruhig, jedes MHz zählt. Es ist dabei unwichtig wieviel MHz auf allen Cores erreicht werden können, viel wichtiger ist wie weit man takten kann wenn 2 Cores in benutzung sind, da sich KSP nur einen (kurioserweise manchmal aber auch einen zweiten) nimmt. Also ist es besser pro Core zu übertakten als auf die gesamte CPU da man bei last auf 2 Cores meisst höher overclocken kann als bei last auf allen 4 Cores. Und wirklich jedes MHz bringt merklich was, das KSP gerade mit Mods sehr CPU intensiv wird.

Was die Grafikkarte angeht, vor allem wenn man mit OpenGL spielt sollte diese möglichst viel Grafikspeicher haben. 4GB bringen einen merklichen Vorteil als 2 GB Karten. SLI bringt wie gesagt hier nichts.

Grafikmods sind derzeit die wirklichen FPS Killer, da diese zusätzlich aufgrund der Engine die CPU extrem belasten. Planetshine ist hier als erstes zu nennen, für den kleinen (wenn auch schicken Effekt) gehen wirklich massiv leistung drauf. Der nächste Grafikmod der stark Leistung kostet ist der Atmospheric Scatterer. Man kann ihn nutzen, aber das Meer würde ich abschalten. Das neue Meer im Scatterer ist wirklich ein FPS Killer. Man kann in der cfg des Scatterers auf allen betroffenen Planeten ocean auf false setzen und hat dann die Atmosphären aber nicht die neuen Meere. Die Atmosphären sind ja wirklich schick und kosten kaum Leistung. Als letzter Mod zu nennen wäre noch der Envoirement Enhancment, der mit Wolken und City Lights, der zwingt den Rechner auch ziemlich in die Knie, besonders wenn er mit Renissance oder Astronomers pack gepimpt wird. Mit diesen Mods muss man echt einzeln rumprobieren ob man für das schicke Aussehen die Geschwindiskeitseinbrüche in Kauf nehmen will. Für das überwachen von RAM und FPS gibt es ebenfalls einen Mod im Spiel.

Mods würde ich nur noch mit CKAN installieren und manchmal in den cfgs der Mods no0ch ein paar Eigenheiten anpassen.

Ansonsten, weder der Active Texture Compressor noch der Dynamic Texture Loader bringen bei mir irgendwas, die sind völlig nutzlos. Ich kann sinnvoll nur unter OpenGL und mit der 32 Bit version spielen. Sonstige Mods wie ScanSat, Remotetech und weiss der geier was ich noch alles laufen habe run eigentlich nicht weh, nur bei Parts geht einem irgendwann der RAm aus. Den muss man wegen des Speicherleaks der Engine auch immer wieder überwachen, der Mod dafür macht das sehr leicht. Nach dem Start habe ich 2.8 GB Verbrauch, nach dem Wechsel zwischen 5-6 Missionen bin ich denn bei 3.8 GB und muss neu starten. Das Problem lässt sich nicht umegehen, nach jedem Wechsel Spaceport-Mission-Spaceport-Mission verbraucht KSP ca. 200 MB mehr. Das ist auch in der Vanilla der Fall, nur führt es da lange nicht zum Crash, da die Vanilla mit ca. 1GB Speicherverbrauch nach Start viel Reserve hat.

Selbst Outer Planets, Grafikmods, Physic und partmods sind aber mit viel Fummelei irgendwann zum flüssigen Spielen zu bewegen. Und dann macht es echt total laune weil die Komplexität (und die Optik) doch enorm zunehmen.

Trotzdem bin ich Aufgrund des RAM verbrauchs am Maximum was noch so spielbar ist und freu mich auf die 1.1 wo das endlich aufgrund von Multithreading Physics und 64 Bit aus der Welt sein dürfte und Mods Tür und Tor offen stehen.

Auch mit dem Fix lassen sich Septratrons nicht immer vermeiden. Beim Verbauen drauf achten, dass der Ausstoss nicht in Richtung anderer Teile zielt sondern in's Leere. Dann sind die unproblematisch zu nutzen.

Die 2.4.2 funbktioniert mit dem RSS eigentlich problemlos. Das Problem ist da ein Anderes. Im RSS wobbelts mehr als in Stock und der Mechjeb nutzt das Vectoring um dem Wobbeln entgegenzuwirken. Und da schaukelt sich's einfach nur extrem hoch weil das Vectoring das Wobbeln verstärkt.

Folgende Tips können Dir helfen:

Nicht das AR202 verwenden sondern das Mechjeb Module mit Modulemanager direkt in die Pods laden.
Installieren des KerbalJoint Reinforcement. Unbedingt die derzeitige Developer Version nehmen, alle anderen sind böse buggy gerade. Solltest Du KJR sowieso installiert haben, dann liegt es daran, updaten auf Developer Version!!! (https://github.com/ferram4/Ker…balJointReinforcement.dll)
Ohne KJR ansonsten - Struts, Struts, Struts, noch mehr Struts

Mit folgender Config (einfach in eine eigene .cfg Datei schreiben) lädst Du das Mechjeb Module in alle Pods:

Ja, das Problem hatte ich früher sowohl unter DirectX als auch jetzt unter OpenGL. Mit OpenGL hat's nix zu tun.

Hab mir das mal näher angesehen. Es scheint als werden die Texturen beim Laden unter DirectX im Arbeitsspeicher der Applikation gehalten, beim Laden unter OpenGL im Grafikspeicher. Ist der voll wird auf den Shared Memory den Windows der GraKa zur Verfügung stellt umgeschaltet.

Das erlärt warum die Applikation selber unter OpenGL weit, weit weniger Arbeitsspeicher benötigt als unter DirectX.

Mir ist nämlich aufgefallen, dass KSP selbst bei mir nur 2.7 Gig Ram verbraucht, aber trotzdem nach dem Laden insgesamt 8 GB Arbeitsspeicher belegt sind.

Also spart OpenGL keinen RAM sondern er wird nur anders genutzt und so kann man die 4 Gig Limitierung umgehen.

Taurec , das hat dann aber nicht mit demGrafikspeicher zu tun, sondern mit der 4 GB Limitierung der 32 Bit Version auf dem Arbeitsspeicher. Ich hab z.B. das Astronomers Grafikpack laufen. Mit sämtlichen AddOns. Auch zusätzliche Planeten und die Kerbin Basen und weiß der Geier was noch. Alles in der 32 Bit Version. Wie in dem Thread schon geschrieben, ist das aber nur unter OpenGL möglich, nicht mit DirectX.

Ich habe eine GTX670 mit 2 GB.

Jetzt wo Du's sagst, hab ich mal nachgesehen. Tatsache, die Auslastung des Grafikspeichers ist ständig bei 100%.

Wäre ja mal interessant zu wissen wie das zusammenhängt. Ich hab nie die GraKa unter KSP überwacht. Jetzt wo ich da mal so nachsehe, das ist schon abgefahren. Die GPU hat Langweile, egal was ich mache, die GPU Auslastung gammelt bei 20-30% rum und der GPU Takt ist noch nichtmal bei 75%.

Aber der Grafikspeicher ist voll, da passt nix mehr rein.

Weiss einer ob das irgendwas bringt wenn man bei KSP eine 4GB GraKa hat? Sieht fast so aus.

Ich hab ne Nvidia. Da geht's. Hatte früher mal ATI, kann mich erinnern, dass es da auch Options dafür gibt.

Ich meine mich zu erinnern, dass bei ATI DirectX und OpenGL Optionen getrennt eingestellt werden müssen. Ist aber lang her, kann sein, dass es mittlerweile anders ist. Gibt's den Rivatuner noch? Mit dem geht's sicher auch bei ATI. OpenGL lohnt sich bei KSP wirklich, aber das Gepixel ohne AA würde ich auch nicht wollen.

Schau mal ob Du's nicht mit dem Rivatuner einschalten kannst.

Zitat von seb-eisdrache

Es scheind, das im OpenGL modus kein Antialiasing funktioniert, aber der speicherbedaft wurde extrem reduziert

Halb so wild, stellt man in den Optionen des Grafiktreibers das AA fest ein, gilt das auch für OpenGL und KSP läuft dann auch unter OpenGL mit AA

Btw, wer mit OpenGL spielt, sollte den TextureCompression Mod runterschmeissen. Der lässt im Falle von OpenGL den Ramverbrauch steigen statt ihn zu senken. Hab weit über 70 Mods laufen incl. jeder Menge Grafikmods. Selbst mit Texturemanager unter DirectX nimmer spielbar, unter OpenGL bin ich bei 2.7 Gig und es läuft flutschig.

Volllbild geht ebenfalls, sollte Jemand das Bildflackern/schwarze Teile des Bildes im Vollbild nach dem laden haben, genügt es mit Alt-Tab kurz auf Desktop umzuschalten und dann wieder zurück in's KSP - Voila, kein Darstellungsproblem mehr.

Nach Splashdown.

Ich habe bereits mehrfach mit dem Zeigefinger gegen die Anzeige geklopft - aber nichts passiert. Sie besteht stur darauf unter mir wären noch 1000 Meter Luft.

Kombinierte Radar/Sonar Anzeige? Höhe über Meeresgrund?

Hey Nereid,

der Mod ist extrem cool, nur ist es derzeit lebensgefährlich sich drauf zu verlassen

Beim Abstieg stimmt was nicht mit der Radar Alt. Abstieg über dem Meer zeigt immer eine Radarhöhe von 1000 Meter zu hoch an!
Ob es über Land auch so ist, weiß ich nicht.

Ich hab schon 2 Pods gecrast weil ich nachts (habe durch Mods wirklich stockfinstere Nacht) in's Meer geknallt bin weil ich die Fallschirme zu spät ausgelöst habe.

Siehe Screenshot, ist ein Abstieg über dem Meer, man sieht halt nix, weil stockfinster.

Links oben die Nano Gauges Radar Alt ~ 1300 m -> 1000 Meter zu hoch.

Der Fehler ist bei mir reproduzierbar.

Noch enttäuschender, das Brett muss nichtmal angewinkelt sein. Du kannst ein ganz normales Brett einfach waagrecht an den Rumpf schrauben. Wenn das Heck ein Höhenruder hat und sich die Konstruktion ausreichend schnell bewegt und das Höhenruder nach oben ausschlägt, genügt das um die Nase des Konstrukts anzuheben und es entsteht der positive Anstellwinkel.

Bei ausreichend Geschwindigkeit und Flügelfläche würde das Gefährt abheben. Mit 2 popeligen Regalbrettern.

Super ineffizient, aber fliegen würde es. Zumindest 2 Meter. Dann fängt es an durch die Luftverwibelungen bis zur Zerstörung zu vibrieren.

Zitat

Und warum spricht dann jeder davon, dass der weg, den die Luft zurücklegen muss, oberhalb größer ist und unterhalb kleiner und das dadurch der Druckunterschied zustande kommt der das Flugzeug in der Luft hält.

Weil das bezogen auf den Anstellwinkel der Grund ist warum Auftrieb erzeugt wird.

Das Profil der Tragfläche kann, wenn es einseitig gewölbt ist, ebenfalls Auftrieb erzeugen, auch ohne Anstellwinkel, aber bei normalen Flugzeugkonstruktionen genügt das nicht zum abheben.

Ist Dir schon mal aufgefallen, dass Flugzeuge beim Start die Nase heben? Das wäre gemäß Deiner ursprünglichen Vorstellung ja völlig unnötig,sogar problematisch, wenn der Auftrieb durch das Tragflächenprofil zum Fliegen genügen würde.

Bei Hubschraubern lässt sich das auch sehr gut beobachten. Die Rotorblätter bewegen sich normalerweise permanent mit gleicher Geschwindigkeit. Der Auftrieb wird erzeugt indem die Rotorblätter längs verdreht werden und so der Anstellwinkel entsteht.

Am einfachsten kannst Du es bei Ventilatoren sehen. Das Prinzip ist das Gleiche.

Und noch einfacher, hier tatsächlich ohne ein Flügelprofil, kennst Du diese Weihnachtskarusells aus Holz wo man Kerzen drunterstellt?

Das sind nur Holzbrettchen die kreisförmig wie bei einem Rotor zusammengesteckt werden. Aber es snd völlig flache Holzbrettchen. Diese werden aber angewinkelt indem sie um die Längsachse verdreht werden. Ist alles das gleiche Prinzip.