Agost
-
Posts
195 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Agost
-
-
Continued from here, here and here ...
As promised, here are the pictures of the robotic ship, that left prior to the colony ships.
The ship left Kerbin and after a clean Hohmann Transfer, it arrived in the joolian system in preparation for aerobraking. The maneuver went well, and soon the ship was on its way to its target destination, Laythe.
The ship was disassembled (controlled and unspontanious) into the orbital refueling relay, the rover lander and the 3 satellites, which instantly moved to their designated orbit on their own to begin scanning operations. Once the surface was scanned, the robotic lander descended to the designated landing point to deploy a rover and check for the best possible landing site.
The lander descended as planned, but during final descent disaster struck... One of the fuel lines, connecting to the outer engines was not in place anymore, putting the ship into an uncontrolled spin. And if that wasn´t enough, when the robotic AI deployed the emergency chutes one of them was torn loose. It to land using the de-orbit-engines as a little help, but the impact was rough. The rover deployed as desired and seemed to be unaffected by the crash landing, but only 3 km later it lost three of its six wheels, just by driving gently at 10 m/s.
Maybe it was the kraken playing its evil game, or a hungry technician that gnawed on the kables back in the VAB before launch... who knows...
However, i count this mission as a success. The spaceplanes have been delivered (i double checked the fuel lines...), the planets surface is mapped in all its detail, the landing zone looks promising of what the rover could manage to see and the orbital refueling relay is in place.
Hopefully, the colonists will have more luck than the rover... we will see shortly.
What's the point of that huge disk in the middle?
-
No... it should change?
This might be caused by a bad installation, maybe missing files or wrong location
-
As usual recovering on Kerbins surface rewards you with the most science. And as usual you can also transmit for a reduced amount. But this does leave your experiment inoperable and you'll need a regular lab to clean/reset it before you can use it again.
I have tried but was unable to remove the data on EVA.
So, will I fulfil the contract by only transmitting?
-
Hi all!
I have a question for you guys: when a StationScience contract wants you to run an experiment ( plant growing etc. ) and return the data, does it mean that you actually have to recover that vessel?
I mean, do I have to deorbit the whole module and recover it at Kerbin, or can I just transmit the data/collect it with a Kerbal and go back to the ground?
-
Have you tried deleting and reinstalling all those mods?
-
Alright, so DXT loading is on it's way... and WOW. Loading is fast. Blazing. Memory usage is down, and things look great!
Downside is the first loading takes a LONG time. A REALLY long time. Good news is that it only has to happen once.
For brave souls: https://github.com/rbray89/ActiveTextureManagement/releases/tag/4-0Beta
Does it require DDSLoader?
Moreover, what should I do with B9 ATM .cfg? Replace your stock one with that or just delete the one in BoulderCo?
-
well then if thats my only option ill just have to shelve this game until squad implements better optimization because theres no way this game will continue to function well offloading to one CPU core, its going to only get worse until they actually address the elephant in the room dropping to 10 fps on a 30part model is pathetic even for an "older" cpu, i mean its just sitting there theres no actual physics to calculate because nothing is triggering
It's because of Unity limitations, not squad's fault. It can use only 2 cores and, like you've been told, your cpu is quite old and Unity does not like AMD cpus very much.
However, with that CPU you are limiting your GPU in many other games, trust me.
-
A notice to anybody who has memory problems with even the agressive version of this installed:
Disable mipmaps.
It can be noticed, but once you get to it, there is no quality difference, and saves a lot of memory (It might not save it on game launch, but comparing the RAM after 5 launches with mipmaps vs 5 with no mipmaps makes the difference
)EDIT: Also, deleting texturecache folder seems to reduce the RAM usage another 600 MB
(I don't know whats going on with my ksp installation...)Cheers!
Do you use EVE/ Better atmosphere? How does disabling mipmaps affect these mods?
-
Sorry but opengl is in general faster than directx even on windows. You can read that everywhere on google. I don't know how the performance is in the case of ksp in general, but as far as i can tell from the benchmark i made i can say that there is no significant difference between opengl and directx on my computer except the lower ram usuage of opengl. I have a i5 2500k clocked to 4.8ghz and even i have massive laggs here and there. So i would recommend you to only buy a new cpu if it is the bottleneck in other games too.
There is a HUGE gap between a 2500k and his athlon x4, even at stock speeds. Are you 100% sure your OC is stable and you're not getting thermal throttling? The only slowdowns I encounter are during ship/ksc loading and I have an i7 920 @ 3.67 GHz ( 3.8 on the first two cores with turbo), so much less ST performance compared to yours.
I've always read that opengl on ksp runs slower but with less memory usage and no, opengl isn't always better in performance than dx in other games. DirectX are actually pretty good libraries, if used well
-
Because you cpu has two cores, basically it can run two things at once. Obviously you can run more than one program at a time because each core is split into threads, which allows more than two processes to run at a time. However, the most processing power a single thread can use is the processing power of a single core, since you have two cores, unity is maxing out its thread and cannot expand. Some programs get around this by multi-threading which is where they run on more than one thread. Unfortunately, Unity (and most games for that matter) is not multi-threaded. If you were to look at the occupation of each core of the CPU, you would probably see that unity is taking up 100% of its core.
TL;DR: Unity can only take up one core of your CPU, of which you have two so you see unity as running at half power.
He's got an athlon x4, not x2.
yes its dd3 its socket am3 the cpu is only 4 years old and am3+ is still the current gen.why should i get a new cpu when unity is only using half my current cpu
You CPU is very outdated and so are the "top" AM3+ FX CPUs ( they came out in 2012 )
AM3+ is a dead socket, AMD has no interest in it and it won't get any better CPU. If you have money, I'd consider switching to intel
-
Probably found the responsible for this issue. I've tried loading B9 turbofans only and they cause the issue both on launchpad and on the runway.
On the second screenshot you can clearly see the ship, in flight (?) with mach effects (??) over kerbin (???) and it's not moving (????). Moreover, there is no simmetry applied ( while I obviously applied it in the SPH )
Why this part is causing issues?? It is temporarily unlocked by a contract, could it be the cause?
-
You're going to get a better experience in every game even with just a 4th gen i3... I'd spare some money to get a better platform. If you RAM is DDR3, you can keep it.
-
It's probably CPU's fault. That's an old CPU, with low frequency and IPC. KSP relies on very high single thread performance on only two cores bacause of Unity bad optimization. Moreover Unity does not like AMD cpus very much
-
It depends a lot from your CPU. Moreover, openGL usually gives less ram usage but also less performance.
Can you post your complete pc specs? Possibly with screen resolution and video settings used
-
Couldn't you?
PART
{
name = nuclearEngine
module = Part
author = NovaSilisko
mesh = model.mu
scale = 1
rescaleFactor = 1
node_stack_top = 0.0, 1.40383, 0.0, 0.0, 1.0, 0.0
node_stack_bottom = 0.0, -1.731957, 0.0, 0.0, 1.0, 0.0
// ThermalAnim = overheat
fx_exhaustFlame_blue = 0.0, -1.6, 0.0, 0.0, 1.0, 0.0, running
fx_exhaustLight_blue = 0.0, -1.6, 0.0, 0.0, 0.0, 1.0, running
fx_smokeTrail_light = 0.0, -1.6, 0.0, 0.0, 1.0, 0.0, running
sound_vent_medium = engage
sound_rocket_hard = running
sound_vent_soft = disengage
sound_explosion_low = flameout
TechRequired = nuclearPropulsion
entryCost = 22600
cost = 8700
category = Propulsion
subcategory = 0
title = LV-N Atomic Rocket Motor
manufacturer = Jebediah Kerman's Junkyard and Spaceship Parts Co.
description = Despite the big scary trefoil painted onto the side of this engine, its radioactive exhaust, and tendency to overheat, the LV-N Atomic Rocket Motor is harmless. Mostly.
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,0,0
mass = 2.25
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 2
crashTolerance = 12
maxTemp = 4000
// Yes, I know this is wrong. NTRs don't actually burn fuel and oxidizer, but we don't want to jump into making separate tanks for the two yet.
MODULE
{
name = ModuleEngines
thrustVectorTransformName = thrustTransform
exhaustDamage = True
ignitionThreshold = 0.1
minThrust = 0
maxThrust = 60
heatProduction = 600
fxOffset = 0, 0, 1.6
PROPELLANT
{
name = LiquidFuel
ratio = 1
DrawGauge = True
}
atmosphereCurve
{
key = 0 800
key = 1 220
}
}
MODULE
{
name = ModuleJettison
jettisonName = fairingL
bottomNodeName = bottom
isFairing = False
jettisonedObjectMass = 0.1
jettisonForce = 1
jettisonDirection = 1 0 0
}
MODULE
{
name = ModuleJettison
jettisonName = fairingR
bottomNodeName = bottom
isFairing = False
jettisonedObjectMass = 0.1
jettisonForce = 1
jettisonDirection = -1 0 0
}
MODULE
{
name = ModuleGimbal
gimbalTransformName = thrustTransform
gimbalRange = 1
}
MODULE
{
name = ModuleAnimateHeat
ThermalAnim = overheat
}
MODULE
{
name = ModuleAlternator
RESOURCE
{
name = ElectricCharge
rate = 5.0
}
}
RESOURCE
{
name = ElectricCharge
amount = 0
maxAmount = 0
isTweakable = false
hideFlow = true
}
MODULE
{
name = ModuleTestSubject
// nowhere: 0, srf: 1, ocean: 2, atmo: 4, space: 8
environments = 8
useStaging = False
useEvent = True
}
}There, I did it for you.
EDIT:
Hey, look!
"Yes, I know this is wrong. NTRs don't actually burn fuel and oxidizer, but we don't want to jump into making separate tanks for the two yet."
THIS IS IN THE FILE.
So they are thinking of fixing it.
Like I said, I know that squad knows that it's wrong and they want to change it... the real question is why they haven't done it yet, since there already are LF tanks only
-
And require us to carry half-empty tanks? Or shall they create a new line of fuel-only tanks? How many and how large?
In case you find yourself with excess oxygen at some point, will you be able to get rid of it?
"Just switch the required fuel" isn't even half of it, I'm afraid. It would be a lot of work for something that doesn't really matter; from a gameplay point of view, it would only provide the player with a few more reasons why a mission can fail. Planning is difficult enough already, especially for the stock players who don't even have a delta-V calculator.
"Real" nuclear engine ( like NERVA ) were supposed to work with hydrogen. In KSP, LF is very likely to be LH2. Nuclear engines could use simple LF like jets do...
-
The camera is supposed to do that when root part is removed, and the other part happened to me, just try to salvage all you can with subassemblies and rebuild the craft.
It does not behave like normal disassebly... parts detach from others in a strange manner, like if the tree of the craft is broken. If i remove, for example, a central fuel tank, other parts attached to it stay still in their place, a little greyed out...
-
"Realistic" nuclear engines? I mean, using LF+OX for a nuke makes no sense, and squad knows it... can't they just switch the required fuel to LF only?
-
Did you do something funky during construction? Maybe Undo placing a root part or something? It would explain why loading an already built craft worked fine, too. I'm guessing the craft file is corrupt in some way, you might be better off deleting it and starting again.
I've made another KSP folder from the stock steam version ( after a cache integrity check ), reinstalled all the mods ( without planetshine ) and loaded the same save file. Then i cancelled the old ship from the VAB and made an identical one... same issue.
When i go back to the VAB, I find the same ship without simmetry on and looking like it's not a single ship anymore ( every part can be taken apart and the craft still stays the same, even if you remove the root one )
I'll provide some screenshot asap. Can the save files be useful, too?
-
1. make a shortcut to your game executable
2. add "-force-opengl" to the path of the shortcut.
this should save ~ 1gb. Anyway i think the game is just not playable atm. I have a scenario with only 10 ships each 25 parts and i get 5 frames on my 4.8ghz i5 2500k. Thats really really poor.
I solved by reinstalling everything. Probably a bad mod installation. The real problem now is in this thread...
However, your poor performance can be caused by openGL itself ( it is known for having lower performance vs dx9 in KSP ): just use ATM
-
Why yes. FAR is the correct aerodynamic model, and you have to make realistic aircraft with it. Like this one:
http://greenoctagon.co.uk/~dmpserver/gallery/dmpmodsfar/Technicalfool/2014-11-06%2023-03-10.jpg
Seriously, less of the No True Scotsman fallacy, please. You're insulting the intelligence of people you don't even know.
FAR flight assistant is showing High Dynamic Pressure, because it's in transonic speeds and has a non-aerodinamic front... it would probably get destroyed as soon as it turns.
Also SAS modules are OP in KSP, there are 2 there...
-
Not cancelled, scrubbed.
It has been rescheduled.
I've run back home for nothing... you know what was cancelled? My lunch.
Moreover, my KSP career has rescheduled, since I'm affected by a bad launchpad Kraken...
-
Still nothing. Thanks launchpad kraken.
-
This shouldn't be a ram issue...
What OS and ksp version are you running?
)
(I don't know whats going on with my ksp installation...)
What did you do in KSP1 today?
in KSP1 Discussion
Posted
It's kinda strange that the orange tank didn't blow up... was is a mild aerobraking?