Jump to content

[0.90] Kerbin Shuttle Orbiter System v4.13

helldiver

By helldiver
in KSP1 Mod Releases

 Share

Recommended Posts

rottielover

rottielover

Posted
Posted
Try the configs here:

http://forum.kerbalspaceprogram.com/showthread.php?p=1493238#post1493238

Caveat: I haven't used KSO in awhile; it's not installed in my DREC testing environment. There hasn't been anything TOO drastic in the beta that would affect the KSO configs.

The cargo bay is problematic, especially the KSO25 with or without FAR. By itself, DRE has to rely on raycasting from the center of each payload part along the flightpath and if it hits something then it treats that part as shielded. The raycast tends to fail if the origin point lies inside the collider for the thing it needs to detect.

I'm still burning the nosecone off. I've tried various angles of attack , not sure if that has anything to do with it. Noticed that I'm burning off very little of the ablative shielding on most of the parts, and I just realized that the nosecone isn't picking up any shielding.... hmm wonder why MM isn't seeing the cfg?

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
I'm still burning the nosecone off. I've tried various angles of attack , not sure if that has anything to do with it. Noticed that I'm burning off very little of the ablative shielding on most of the parts, and I just realized that the nosecone isn't picking up any shielding.... hmm wonder why MM isn't seeing the cfg?

If it's already in existence before you installed the configs then it's not going to be affected by them (at least not pre-beta, which is moving away from persistence). Those configs use no ablative shielding (except for the KSO25 when used with RSS) so if you actually see something that says 'ablativeshield' then it definitely sounds like a craft that already existed when you installed the configs. (note that the KSO25 config has to be copied over the existing KSO25 heat shield config because it wasn't designed as a patch. It's a drop-in replacement)

Link to comment
Share on other sites
MK3424

MK3424

Posted
Posted
Im having trouble getting into a near circular orbit with both the block 4 and 9 shuttles. Also I have to ditch the ET (external tank)in the middle of my circularization burn which is not right? Dont the real shuttles jettison tank before circularization burn? According to the PDF manual im suppose to have cut off my engines after 75-80 km and coast to circularize. Im trying to do a text book approach in getting into orbit by following the guide, but not getting into a great orbit. I think the culprit is the ET (too much weight?) is burdening the craft during the circularization burn. Ive had really awful orbits such as 80km/1MM <----thats megameters! And even a few dont even make it to orbit as the Pe will sink me back down to 40km. So my focus is to get into either a KSO approved circular orbit using 2 burns , or the real life space shuttle way by using the 1 burn method. Tips and tutorials are welcome :)

Try to do the same flight plan as depicted in this video from kosmo-not:

Link to comment
Share on other sites
Cairan

Cairan

Posted
Posted
Why don't the landing gears respond?????????????????????????????[/quote

you have to hit the G key twice , not once

As I've said earlier, I am having issues with the gear being not responsive too ... And this is not about not hitting G twice, hitting it as many times as I want does not resolve the fact that specifically for the KSOS gears, there is no deploy/retract trigger in the action groups, nor in the GUI, nor with the keyboard hotkey...

Is it a Firespitter issue? I don't know ... Since Firespitter is in "flux" right now, I don't want to install the whole package, so I only have the DLL installed... I tried updating it from the bundled version to the official "0.25" release, but that does not solve the gear issue...

Everything else works fine... The landing gear even has the landing light available, but again, having it retracted is not possible either in the SHP/VAB nor in the sim...

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted

As I've said earlier, I am having issues with the gear being not responsive too ... And this is not about not hitting G twice, hitting it as many times as I want does not resolve the fact that specifically for the KSOS gears, there is no deploy/retract trigger in the action groups, nor in the GUI, nor with the keyboard hotkey...

Is it a Firespitter issue? I don't know ... Since Firespitter is in "flux" right now, I don't want to install the whole package, so I only have the DLL installed... I tried updating it from the bundled version to the official "0.25" release, but that does not solve the gear issue...

Everything else works fine... The landing gear even has the landing light available, but again, having it retracted is not possible either in the SHP/VAB nor in the sim...

The latest update removed Firespitter as a dependency for the landing gear. That's what I recall anyway and that's what the release notes say. Are you guys sure you have the very latest download? If so, try uploading logs (output_log.txt - player.log if MAC/OS or Linux). I'll take a look at the logs for you and see if I can spot anything unusual relating to the KSO gear (I'm not affiliated with KSO, but I do know my way around the log files)

Link to comment
Share on other sites
Cairan

Cairan

Posted
Posted (edited)

The latest update removed Firespitter as a dependency for the landing gear. That's what I recall anyway and that's what the release notes say. Are you guys sure you have the very latest download? If so, try uploading logs (output_log.txt - player.log if MAC/OS or Linux). I'll take a look at the logs for you and see if I can spot anything unusual relating to the KSO gear (I'm not affiliated with KSO, but I do know my way around the log files)

Well, I am puzzled then... I've verified that I downloaded KSOS_v409HF_ALL ... Here's the listing of the files, and notice Firespitter is among them:


drwxrwxr-x 3 root root    60 Oct 24 03:51 BoulderCo
drwxrwxr-x 4 root root   120 Oct 24 03:51 Firespitter
drwxrwxr-x 3 root root    80 Oct 24 03:51 JSI
drwxrwxr-x 7 root root   160 Oct 24 03:51 KSO
drwxrwxr-x 3 root root    80 Oct 24 03:51 Klockheed_Martian
drwxrwxr-x 3 root root    60 Oct 24 03:51 MechJeb2
-rw-rw-r-- 1 root root 46080 Oct  8 02:57 ModuleManager.2.5.1.dll
drwxrwxr-x 2 root root   120 Oct 24 03:51 SmokeScreen

$ cat Firespitter/Firespitter.version 
{
  "NAME": "Firespitter",
  "URL": "https://raw.githubusercontent.com/snjo/Firespitter/master/For%20release/Firespitter/Firespitter.version",
  "VERSION": {
    "MAJOR": 6,
    "MINOR": 3,
    "PATCH": 5
  },
  "KSP_VERSION": {
    "MAJOR": 0,
    "MINOR": 25,
    "PATCH": 0
  }
}

And as an example, the nosegear config file references FireSpitter functions:


cat KSO/Parts/nosegearkso.cfg 
PART
{
// --- general parameters ---
name = nosegearkso
module = Part
author = helldiver
// --- asset parameters ---
MODEL
{
model = KSO/Parts/nosegearkso
}
scale = 1
rescaleFactor = 1


// --- node definitions ---
node_stack_top = 0.00, 0.584847, 0.1430568, 0.0, 0.0, -1.0, 1
//node_attach = 0.00, 0.0, 0.00, 0.0, 0.0, -1.0, 1

// --- FX definitions ---



// --- Sound FX definition ---


// --- editor parameters ---
TechRequired = heavierRocketry
entryCost = 2500
cost = 1250
category = Utility
subcategory = 0
title = KSO Nose Gear
manufacturer = Murika Superstellar Inc.
description = The KSO's landing gear is rated to tolerate the high stresses of most shuttle landings. Although known to sometimes malfunction and stick in the closed position, the landing gear trades reliability for ruggedness. The nose gear features a landing light and dual shock absorbency.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,0,0,1


// --- standard part parameters ---
mass = 0.5
dragModelType = default
maximum_drag = 0.3
minimum_drag = 0.2
angularDrag = 1

maxTemp = 3600 

crashTolerance = 175
breakingForce = 133
breakingTorque = 250

//MODULE
//{
//	name = ModuleLandingGear
//}

//MODULE
//{
//	name = ModuleSteering
//	controlAxisType = Forward
//	steeringAxis = 0, 1, 0
//	steeringTransformName = Steering
//	steeringLocked = false
//	steeringCurve
//	{
// 	 key = 0 24
//	 key = 10 11
// 	 key = 30 2
//	 key = 100 1
// 	}
//}

MODULE
{
	name = FSwheel
	wheelColliderName = wheelCollider
	boundsCollider = Bounds
	wheelMeshName = Wheel
	suspensionParentName = suspension
	rotationAdjustment = 2.0 // adjust the visual rotation speed of the wheel meshes if they are off
	numberOfWheels = 1
	animationName = Take001
	disableColliderWhenRetracted = True
	hasMotor = False
	motorEnabled = False // set to false for landing gears to start unpowered.
	motorTorque = 3.75
	maxSpeed = 35 // the motorTorque is 1 at 0 speed, and 0 at this speed, meaning the actual max speed is probably way lower.
	overrideModelFrictionValues = True // MUST be on for any of the friction values to take effect, otherwise it uses the values in the models wheelCollider
	forwardsStiffness = 3.0 // Forwards friction (Unity default is 1.0, which is not enough to get up small hills)
	resourceConsumptionRate = 0.2
	resourceName = ElectricCharge
	//motorStartsReversed = True
	brakeTorque = 12
	brakeSpeed = 0.45
	animationLayer = 2
	deployedDrag = 0.35
	retractedDrag = 0.0
	guiActiveUnfocused = True
	unfocusedRange = 5.0
	//brakeEmissiveObjectName = noselight
	//onEmissiveColor = 1, 0.2, 0.2
	//offEmissiveColor = 0, 0, 0
	//deployingEmissiveColor = 0.2, 1, 0.2
	//disabledEmissiveColor = 0, 0, 0
}



MODULE
{
	name = FSpartTurner
	steerMultiplier = 12
	targetPartObject = dummy_nose_gear_pivot
	rotationDirectionX = 0
	rotationDirectionY = 0
	rotationDirectionZ = 1
	defaultRotationX = 0
	defaultRotationY = 0
	defaultRotationZ = 0
	steeringEnabled = False	
	reversedInput = False
	speedAdjustedSteering = True	
	speedAdjustedSteeringMinimumMultiplier = 0.1
}


    MODULE
    {
        name = ModuleAnimateGeneric
	animationLayer = 3
        animationName = navLights
        startEventGUIName = Turn on landing spotlight
        endEventGUIName = Turn off landing spotlight
        actionGUIName = Toggle landing spotlight
    }
//MODULE
//    {
//        name = ModuleLight
//        lightName = LandingLight1
//        useAnimationDim = true    
//        lightBrightenSpeed = 1     
//        lightDimSpeed = 1           
//        resourceAmount = 0.02    
//        animationName = navLights 
//        useResources = true     
//    }

//MODULE
//{
//	name = FXModuleLookAtConstraint
//	CONSTRAINLOOKFX
//	{
//		targetName = dummypoint1
//		rotatorsName = dummysusp1
//	}
//}

//MODULE
//{
//	name = FXModuleLookAtConstraint
//	CONSTRAINLOOKFX
//	{
//		targetName = dummypoint2
//		rotatorsName = dummysusp2
//	}
//}
//
//}

I've tried an older version of the FireSpitter DLL I had from 0.24.2, and now despite the warning, the landing gear now works... So it seems this is a FireSpitter issue after all. Yet I don't understand what could have changed in FSWheel in the DLL compiled for 0.25 vs the older one for 0.24.2 to break the gear extension/retraction functionality...

Edited by Cairan
Info on FireSpitter
Link to comment
Share on other sites
Angelo Kerman

Angelo Kerman

Posted
Posted

Get the latest release here.

0.2: Updated The Foot's art assets. Introduced the Inflatable Multipurpose Warehouse. Fixed a problem with the MBU leaping into the air upon being deployed with legs out from the VAB/SPH- thanks nil2work! :) Fixed efficiency parts on kerbitat and greenhouse templates.

2EtxfWc.png

qbkjEfu.png

Hint about the next release: E.P.L.

On a personal note, two weeks into my new job and I'm kicking butt. :)

Link to comment
Share on other sites
qnistNAMEERF

qnistNAMEERF

Posted
Posted (edited)

Well, I am puzzled then... I've verified that I downloaded KSOS_v409HF_ALL ... Here's the listing of the files, and notice Firespitter is among them:


drwxrwxr-x 3 root root 60 Oct 24 03:51 BoulderCo
drwxrwxr-x 4 root root 120 Oct 24 03:51 Firespitter
drwxrwxr-x 3 root root 80 Oct 24 03:51 JSI
drwxrwxr-x 7 root root 160 Oct 24 03:51 KSO
drwxrwxr-x 3 root root 80 Oct 24 03:51 Klockheed_Martian
drwxrwxr-x 3 root root 60 Oct 24 03:51 MechJeb2
-rw-rw-r-- 1 root root 46080 Oct 8 02:57 ModuleManager.2.5.1.dll
drwxrwxr-x 2 root root 120 Oct 24 03:51 SmokeScreen

$ cat Firespitter/Firespitter.version
{
"NAME": "Firespitter",
"URL": "https://raw.githubusercontent.com/snjo/Firespitter/master/For%20release/Firespitter/Firespitter.version",
"VERSION": {
"MAJOR": 6,
"MINOR": 3,
"PATCH": 5
},
"KSP_VERSION": {
"MAJOR": 0,
"MINOR": 25,
"PATCH": 0
}
}
And as an example, the nosegear config file references FireSpitter functions:

cat KSO/Parts/nosegearkso.cfg 
PART
{
// --- general parameters ---
name = nosegearkso
module = Part
author = helldiver
// --- asset parameters ---
MODEL
{
model = KSO/Parts/nosegearkso
}
scale = 1
rescaleFactor = 1


// --- node definitions ---
node_stack_top = 0.00, 0.584847, 0.1430568, 0.0, 0.0, -1.0, 1
//node_attach = 0.00, 0.0, 0.00, 0.0, 0.0, -1.0, 1

// --- FX definitions ---



// --- Sound FX definition ---


// --- editor parameters ---
TechRequired = heavierRocketry
entryCost = 2500
cost = 1250
category = Utility
subcategory = 0
title = KSO Nose Gear
manufacturer = Murika Superstellar Inc.
description = The KSO's landing gear is rated to tolerate the high stresses of most shuttle landings. Although known to sometimes malfunction and stick in the closed position, the landing gear trades reliability for ruggedness. The nose gear features a landing light and dual shock absorbency.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,0,0,1


// --- standard part parameters ---
mass = 0.5
dragModelType = default
maximum_drag = 0.3
minimum_drag = 0.2
angularDrag = 1

maxTemp = 3600 

crashTolerance = 175
breakingForce = 133
breakingTorque = 250

//MODULE
//{
// name = ModuleLandingGear
//}

//MODULE
//{
// name = ModuleSteering
// controlAxisType = Forward
// steeringAxis = 0, 1, 0
// steeringTransformName = Steering
// steeringLocked = false
// steeringCurve
// {
// key = 0 24
// key = 10 11
// key = 30 2
// key = 100 1
// }
//}

MODULE
{
 name = FSwheel
 wheelColliderName = wheelCollider
 boundsCollider = Bounds
 wheelMeshName = Wheel
 suspensionParentName = suspension
 rotationAdjustment = 2.0 // adjust the visual rotation speed of the wheel meshes if they are off
 numberOfWheels = 1
 animationName = Take001
 disableColliderWhenRetracted = True
 hasMotor = False
 motorEnabled = False // set to false for landing gears to start unpowered.
 motorTorque = 3.75
 maxSpeed = 35 // the motorTorque is 1 at 0 speed, and 0 at this speed, meaning the actual max speed is probably way lower.
 overrideModelFrictionValues = True // MUST be on for any of the friction values to take effect, otherwise it uses the values in the models wheelCollider
 forwardsStiffness = 3.0 // Forwards friction (Unity default is 1.0, which is not enough to get up small hills)
 resourceConsumptionRate = 0.2
 resourceName = ElectricCharge
 //motorStartsReversed = True
 brakeTorque = 12
 brakeSpeed = 0.45
 animationLayer = 2
 deployedDrag = 0.35
 retractedDrag = 0.0
 guiActiveUnfocused = True
 unfocusedRange = 5.0
 //brakeEmissiveObjectName = noselight
 //onEmissiveColor = 1, 0.2, 0.2
 //offEmissiveColor = 0, 0, 0
 //deployingEmissiveColor = 0.2, 1, 0.2
 //disabledEmissiveColor = 0, 0, 0
}



MODULE
{
 name = FSpartTurner
 steerMultiplier = 12
 targetPartObject = dummy_nose_gear_pivot
 rotationDirectionX = 0
 rotationDirectionY = 0
 rotationDirectionZ = 1
 defaultRotationX = 0
 defaultRotationY = 0
 defaultRotationZ = 0
 steeringEnabled = False 
 reversedInput = False
 speedAdjustedSteering = True 
 speedAdjustedSteeringMinimumMultiplier = 0.1
}


 MODULE
 {
 name = ModuleAnimateGeneric
 animationLayer = 3
 animationName = navLights
 startEventGUIName = Turn on landing spotlight
 endEventGUIName = Turn off landing spotlight
 actionGUIName = Toggle landing spotlight
 }
//MODULE
// {
// name = ModuleLight
// lightName = LandingLight1
// useAnimationDim = true 
// lightBrightenSpeed = 1 
// lightDimSpeed = 1 
// resourceAmount = 0.02 
// animationName = navLights 
// useResources = true 
// }

//MODULE
//{
// name = FXModuleLookAtConstraint
// CONSTRAINLOOKFX
// {
// targetName = dummypoint1
// rotatorsName = dummysusp1
// }
//}

//MODULE
//{
// name = FXModuleLookAtConstraint
// CONSTRAINLOOKFX
// {
// targetName = dummypoint2
// rotatorsName = dummysusp2
// }
//}
//
//}

I've tried an older version of the FireSpitter DLL I had from 0.24.2, and now despite the warning, the landing gear now works... So it seems this is a FireSpitter issue after all. Yet I don't understand what could have changed in FSWheel in the DLL compiled for 0.25 vs the older one for 0.24.2 to break the gear extension/retraction functionality...
The KSOS is still very much firespitter-dependant, especially for the landing gear and the heli. I expressed concern about this to Helldiver and Nazari since firespitter development is currently halted. That said, with the release of KSP 0.25 came a stock animation module (that the mk2 parts use for their animations, such as the cargo bay door animations). Firespitter previously filled the void this new animation filled. So I tried the new module on the KSOS parts and it worked. The landing gear, for example, do not use this module for their animations however. But there is a stock landing gear module that the stock gear bay use. But it's not a simple swap as with the animation module. It would require access to the unity workspaces and possibly re-exporting them to get them to work with the stock landing gear modules, and possibly with both stock and firespitter (depending on the presence of firespitter). I don't have access to the workspaces so it's not possible on my end. I'm a firm believer that KSOS should rely less on firespitter where it can but I don't know yet to what extent that's possible. 
So, to address your issue: the v409HF is for KSP 0.25 only and is not backwards compatible with previous versions. v409 (which I linked to earlier in the thread) is currently still hosted and can be downloaded for KSP 0.24.2. The hot fix addresses some bugs that surfaced and takes advantage of the new animation module I mentioned earlier. It was released to ease installation for everyone migrating to KSP 0.25. That said, as far as I understand, firespitter is not really updated to KSP 0.25, it's just had its version checker changed to 0.25. So if I understand correctly, the firespitter DLL from 0.24.2 and 0.25 are functionally the same. One of them just doesn't throw a version warning in KSP 0.25. Please feel free to correct me if I'm wrong. The DLL included in KSOS is the pre-release of firespitter version 7 that was released for 0.24.2, hence the version warning.


Edited  by qnistNAMEERF








Link to comment



Share on other sites























Cairan









Cairan




Posted 


















    









Posted 

(edited)










The KSOS is still very much firespitter-dependant, especially for the landing gear and the heli. I expressed concern about this to Helldiver and Nazari since firespitter development is currently halted. That said, with the release of KSP 0.25 came a stock animation module (that the mk2 parts use for their animations, such as the cargo bay door animations). Firespitter previously filled the void this new animation filled. So I tried the new module on the KSOS parts and it worked. The landing gear, for example, do not use this module for their animations however. But there is a stock landing gear module that the stock gear bay use. But it's not a simple swap as with the animation module. It would require access to the unity workspaces and possibly re-exporting them to get them to work with the stock landing gear modules, and possibly with both stock and firespitter (depending on the presence of firespitter). I don't have access to the workspaces so it's not possible on my end. I'm a firm believer that KSOS should rely less on firespitter where it can but I don't know yet to what extent that's possible. 
So, to address your issue: the v409HF is for KSP 0.25 only and is not backwards compatible with previous versions. v409 (which I linked to earlier in the thread) is currently still hosted and can be downloaded for KSP 0.24.2. The hot fix addresses some bugs that surfaced and takes advantage of the new animation module I mentioned earlier. It was released to ease installation for everyone migrating to KSP 0.25. That said, as far as I understand, firespitter is not really updated to KSP 0.25, it's just had its version checker changed to 0.25. So if I understand correctly, the firespitter DLL from 0.24.2 and 0.25 are functionally the same. One of them just doesn't throw a version warning in KSP 0.25. Please feel free to correct me if I'm wrong. The DLL included in KSOS is the pre-release of firespitter version 7 that was released for 0.24.2, hence the version warning.
Yeah, I got this issue on an almost vanilla install of KSP 0.25 with 409HF + FireSpitter compiled for 0.25 ... the older 0.24.2 version of FireSpitter does not cause the landing gear issue... So yeah, for now, one must live with the version check warning or else not have functionnal landing gears on KSOS crafts... As my son is the one using KSOS the most, I've wrapped a little script that checks the username calling KSP.x86_64 ... if it is my son's login, it links FireSpitter.dll to FireSpitter.dll.0.24.2, else to FireSpitter.dll.0.25 ... :cool:
However this would seem to indicate that there are variations in the code between prerelease 7 on 0.24.2 vs the 0.25 compiled on GitHub...


Edited  by Cairan








Link to comment



Share on other sites























qnistNAMEERF









qnistNAMEERF




Posted 


















    









Posted 











Yeah, I got this issue on an almost vanilla install of KSP 0.25 with 409HF + FireSpitter compiled for 0.25 ... the older 0.24.2 version of FireSpitter does not cause the landing gear issue... So yeah, for now, one must live with the version check warning or else not have functionnal landing gears on KSOS crafts... As my son is the one using KSOS the most, I've wrapped a little script that checks the username calling KSP.x86_64 ... if it is my son's login, it links FireSpitter.dll to FireSpitter.dll.0.24.2, else to FireSpitter.dll.0.25 ... :cool:
However this would seem to indicate that there are variations in the code between prerelease 7 on 0.24.2 vs the 0.25 compiled on GitHub...
In this case, yes, that's correct. Since one is pre-release v7 and the other is release v6.3.5. I meant between the release versions (v6.3.5) of firespitter between 0.24.2 and 0.25 are (as I understand it) functionally the same.








Link to comment



Share on other sites























CommanderSmith









CommanderSmith




Posted 


















    









Posted 











Why does this happen? I installed the KSO mod with the included files, however, my game kept crashing on load, so then I installed Texture Replacer, and it booted up. But as soon as the VAB loaded, all parts on the KSO super 25 were white, seemingly untextured. When I try to fly this untextured shuttle, the nose landing gear "teleports" open whenever I load a scene or turn on the gear. I am running mac OS X yosemite. Am I doing something wrong?
I know of this. Basically, KSP has problems reading .tga files for some reason. It does it to random textures, and the best solution is to convert all of the .tga files to .png or something similar. I hope this helps. :)








Link to comment



Share on other sites























King Arthur









King Arthur




Posted 


















    









Posted 











I realize my asking this is akin to throwing oil into a blazing inferno and then setting fire to the fire trucks, so I'm going to keep this as polite as I can and ask that others do the same.
Would it be possible to, at some point, provide an alternative archive(s) with textures that aren't quite as ginormously huge and high-resolution as they are right now? KSO_25.tga alone weighs in at 16MB and is 2048x2048. Just the two 1.25m and 2.5m orbiter packs alone weigh in at ~562MB, this is simply ludicrous; B9 is usually thought of as a heavy mod but this is easily 5x+ its size.
I understand and have read that ATM is strongly suggested, in bold, in the OP; I have understood that completely and ask that replies along the lines of "just install ATM" or "don't complain" be saved for other times. My setup is currently such that I fortunately do not require ATM to achieve stable play.








Link to comment



Share on other sites























dtoxic









dtoxic




Posted 


















    









Posted 











I realize my asking this is akin to throwing oil into a blazing inferno and then setting fire to the fire trucks, so I'm going to keep this as polite as I can and ask that others do the same.
Would it be possible to, at some point, provide an alternative archive(s) with textures that aren't quite as ginormously huge and high-resolution as they are right now? KSO_25.tga alone weighs in at 16MB and is 2048x2048. Just the two 1.25m and 2.5m orbiter packs alone weigh in at ~562MB, this is simply ludicrous; B9 is usually thought of as a heavy mod but this is easily 5x+ its size.
I understand and have read that ATM is strongly suggested, in bold, in the OP; I have understood that completely and ask that replies along the lines of "just install ATM" or "don't complain" be saved for other times. My setup is currently such that I fortunately do not require ATM to achieve stable play.
well you can try and resize the textures you're self , but i would recommend doing it with ATM (in the cfg files just define the size of the tex that saves you the trouble of doing it you're self one by one) 
on the other hand a total tex convert to mbm would be nice since tga has problems and mbm is more memory friendly as far as i know.








Link to comment



Share on other sites



























Kerbas_ad_astra









Kerbas_ad_astra




Posted 


















    









Posted 

(edited)










I use both together just fine. On top of OpenGL and ATM, converting (most of) my heavily modded install's textures to DDS knocked about half a gigabyte off of my RAM usage, and reduced loading time by what feels like an order of magnitude. I might even be able to start using DirectX again and reduce my processor load.


Edited  by Kerbas_ad_astra

Refined estimate based on more running of the game.








Link to comment



Share on other sites







































Guest







 This topic is now closed to further replies. 













  Share





















Go to topic listing



















×


















×



    

  • Create New...
    •