[1.8-1.9] Modular Fuel Tanks v5.13.1

[Drakoan]

Don't know if I have done something wrong but when I remove a tank with the GUI I can't replace it, just comes up with no room for tank.

[skeevy]

Don't know if I have done something wrong but when I remove a tank with the GUI I can't replace it, just comes up with no room for tank.

Assume that's part of the 5.2.0 misrelease and wait for a fix. I'm having that issue and more from the current release of MFT. Taniwha seems to be aware of the issues.

I'd post logs, but I happen to have tried some older 0.24.2 mods and don't want to submit a bug report if I'm not 100% sure it's being caused by a specific mod, doubly so if I'm doing stuff that isn't supported...

[taniwha]

I noticed the problem when I found exceptions related to KAE in my logs, and every one of them was from MFT. Recompiling MFT and actually installing the right build fixed it :/. I'll do a release tomorrow (to tired now: one brown paper bag update per release is more than enough).

[Drakoan]

Assume that's part of the 5.2.0 misrelease and wait for a fix. I'm having that issue and more from the current release of MFT. Taniwha seems to be aware of the issues.

I'd post logs, but I happen to have tried some older 0.24.2 mods and don't want to submit a bug report if I'm not 100% sure it's being caused by a specific mod, doubly so if I'm doing stuff that isn't supported...

Yeah will do, just thought I'd check just in case I had missed something simple.

[skeevy]

I noticed the problem when I found exceptions related to KAE in my logs, and every one of them was from MFT. Recompiling MFT and actually installing the right build fixed it :/. I'll do a release tomorrow (to tired now: one brown paper bag update per release is more than enough).

Thanks. Tomorrow can't come faster now

I have the same exceptions in my logs as well. Basically this for every part using MFT. Using KAE from Infernal Robotics with this and TweakScale (works for me other than stuff not set up in configs). There's also some RF/MFT tweakscale dll errors, but I kind of expected that since I'm using some 0.24.2 mods....like RF and TS (I'm aware RF is waiting on TS before it updates). I had to try...might have gotten lucky.

[EXC 19:14:01.174] ArgumentException: Message argument is null	KSPAPIExtensions.PartMessage.PartMessageListener..ctor (System.Type delegateType, PartRelationship relations, GameSceneFilter scenes)
	System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType)
	System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit)
	System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, Boolean inherit)
	System.Reflection.MonoMethod.GetCustomAttributes (Boolean inherit)
	KSPAPIExtensions.PartMessage.ServiceImpl.Register[ModuleFuelTanks] (RealFuels.ModuleFuelTanks obj)
	UnityEngine.Debug:LogException(Exception)
	RealFuels.ModuleFuelTanks:OnAwake()
	PartModule:Awake()
	UnityEngine.GameObject:AddComponent(Type)
	Part:AddModule(String)
	Part:AddModule(ConfigNode)
	PartLoader:ParsePart(UrlConfig, ConfigNode)
	:MoveNext()
[EXC 19:14:01.215] NullReferenceException: Object reference not set to an instance of an object
	RealFuels.ModuleFuelTanks.RaiseResourceListChanged ()
	RealFuels.ModuleFuelTanks+FuelTank.set_maxAmount (Double value)
	RealFuels.ModuleFuelTanks+FuelTank.InitializeAmounts ()
	RealFuels.ModuleFuelTanks+FuelTank.CreateCopy (RealFuels.ModuleFuelTanks toModule, .ConfigNode overNode, Boolean initializeAmounts)
	RealFuels.ModuleFuelTanks.UpdateTankType (Boolean initializeAmounts)
	RealFuels.ModuleFuelTanks.GetInfo ()
	UnityEngine.Debug:LogException(Exception)
	RealFuels.ModuleFuelTanks:GetInfo()
	PartLoader:ParsePart(UrlConfig, ConfigNode)
	:MoveNext()

On a sidenote, you don't realize how dependent you become on mods until you can't use them. Just need this, RealFuels, TweakScale, FireSpitter, TACLS, and B9 to complete my KSP experience.

[Drakoan]

I know what you mean Skeevy its the only real problem with playing a game still being made hehehe.

[Eskandare]

Question, I'm playing with x64 stress tests. Is Modular Fuel Tanks automatically disabled for x64.

The last build of KSPx64 became stable with certain plugins (for me anyway) I'm attempting to analyze why that worked and if I can make it happen again.

[skeevy]

Question, I'm playing with x64 stress tests. Is Modular Fuel Tanks automatically disabled for x64.

The last build of KSPx64 became stable with certain plugins (for me anyway) I'm attempting to analyze why that worked and if I can make it happen again.

Yes. Says it in big letters in the OP.

[taniwha]

I have released vertsion 5.2.1 of MFT, fixing both the KAE problem and some problems with tweakscale (thanks to NathanKell).

64-bit Windows is NOT supported due to it being an unstable mess.

Nobody will stop you from modifying it to work, but you will get NO support. Anybody distributing a modified version of MFT (for any reason, actually) must make it prominently clear that it is not MFT as released by me or another MFT/RF maintainer. Also, by releasing a modified version, you agree to accept all responsibility.

Edited October 11, 2014 by taniwha

[Camacha]

Is there any relation between this and Procedural parts? I am a bit confused, I thought they were the same.

[skeevy]

About time you woke up and uploaded the build

Only it's bad timing cause I'm about to go to sleep and won't get a chance to use it

[Eskandare]

I have released vertsion 5.2.1 of MFT, fixing both the KAE problem and some problems with tweakscale (thanks to NathanKell).

64-bit Windows is NOT supported due to it being an unstable mess.

Nobody will stop you from modifying it to work, but you will get NO support. Anybody distributing a modified version of MFT (for any reason, actually) must make it prominently clear that it is not MFT as released by me or another MFT/RF maintainer. Also, by releasing a modified version, you agree to accept all responsibility.

So in other words to use certain mods I am forced to used x86 with it's limitations. B9 fuel tanks really become useless... and I don't have a compiler on this machine. Trying not to be mean here, but it does seem to be a bit of a rotten thing to do. Could you at least compile a version that x64 can use but state in big red letters that no one will get support if they use it in x64? By the way I noticed the x64 runs better in a window then it does full screen also -force-opengl seems to make things better too (both and individually).

[NathanKell]

For the record, that's what we tried, for .24, and it didn't work.

And .25 is about 1/4 as stable.

(we = modders; MFT did not have a giant warning, but TACLS sure did and that didn't help any)

[Surefoot]

I have released vertsion 5.2.1 of MFT, fixing both the KAE problem and some problems with tweakscale (thanks to NathanKell).

Thanks Taniwha, works like a charm. I confirm the kraken is gone and everything is back to normal operations (as normal as they can be with kerbals..)

[Blu_C]

Not sure if this has been reported (I checked and didn't see it when I skimmed the past few pages), but most of the MK2 Fuselage parts don't work with this. The only one that appears to work is the Mk2 to 1.25m Adapter, all the other ones do not bring up the menu when I go to edit their contents.

It isn't really a huge deal since there are several versions of most parts, but the Mk2 to 1.25 Adapter Long and the Mk2 Bicoupler are both parts I would like to have the ability to change.

Is there a way I can add them to the config? I've already located them (in the SPP subfolder inside the Squad folder).

[taniwha]

Oh, dear. I completely forgot about the SP+ parts. Yeah, it's easy enough, just study the other .cfg files to see how. The tricky part is getting the volume right.

[rainerd66]

There seems to be another issue with tweakscale.

I tried this mod with tweakscale on a test-ksp.25-win32 without other mods. I created a 5m scaled vessel with stock parts (nosecone mk7, RC-L01 RGU, advSASLarge, Z-4k Battery, Kerb. S3-14400 tank, S3 KS 25x4 EC engine; all scaled to 5m ).

It seems to speed up like crazy during start and then shoots off the camera view, far away almost not visible.

Sometimes this happens with unscaled parts, especially nosecones and remote guidance units.

oops... accidentally used the older version!

everything is fine

Edited October 13, 2014 by rainerd66

[Blu_C]

Oh, dear. I completely forgot about the SP+ parts. Yeah, it's easy enough, just study the other .cfg files to see how. The tricky part is getting the volume right.

Not a big deal. Since they were all new parts I'd guessed they simply still in the works or overlooked.

EDIT:

And I seem to be running into a problem. I've added the following two lines to Squad_modularFuelTanks.cfg. This allows the menu to pop up, but it then states that "This fuel tank cannot hold resources" so I'm not sure what I am doing wrong.

@PART[mk2_1m_AdapterLong]
{
	//!RESOURCE[LiquidFuel] {}
	//!RESOURCE[Oxidizer] {}
	//!RESOURCE[MonoPropellant] {}
	MODULE
	{
		name = ModuleFuelTanks
		volume = 500		type = Fuselage
	}
}
@PART[mk2_1m_Bicoupler]
{
	//!RESOURCE[LiquidFuel] {}
	//!RESOURCE[Oxidizer] {}
	//!RESOURCE[MonoPropellant] {}
	MODULE
	{
		name = ModuleFuelTanks
		volume = 300		type = Fuselage
	}
}

Edited October 12, 2014 by Blu_C

[Camacha]

So, I am confused. What does this do exactly? It seems there is a fair overlap with RealFuels. If this the tanks configuration part of that mod?

[Blu_C]

Real Fuel and MFT were originally the same mod but were split into their separate mods, so there will seem like there is overlap.

Real Fuels allows players to make use of real fuel sources with their own characteristics.

MFT allows players to reconfigure tanks to use a different type of fuel from the game (and several supported mods), but otherwise uses the same abstract fuel sources in the vanilla game.

[Eskandare]

For the record, that's what we tried, for .24, and it didn't work.

And .25 is about 1/4 as stable.

(we = modders; MFT did not have a giant warning, but TACLS sure did and that didn't help any)

I see... So basically everyone is tired of idiots complaining when they haven't read the disclaimer.

I sure wish squad would make Win ksp x64 work. It's interesting that Linux manages it better.

[taniwha]

And I seem to be running into a problem. I've added the following two lines to Squad_modularFuelTanks.cfg. This allows the menu to pop up, but it then states that "This fuel tank cannot hold resources" so I'm not sure what I am doing wrong.

I'll take a proper look later today when I've got some time.

It's interesting that Linux manages it better.

This is because 64-bit Linux is properly 64-bit (the long int type is 64-bit: same as pointers), but 64-bit Windows is half-baked (long is only 32-bits) and there is some bad coding in Unity (casting a pointer to a long and then back to a pointer). These problems can go unnoticed for a very long time if memory usage never approaches 2GB. Why 2GB and not 4GB? Signed 32-bit values are -2G..2G, unsigned are 0..4G, and signed values are used for offsets, though getting an offset > 2G is much rarer than getting an absolute address > 4G.

[NoPersona]

I'll take a proper look later today when I've got some time.

This is because 64-bit Linux is properly 64-bit (the long int type is 64-bit: same as pointers), but 64-bit Windows is half-baked (long is only 32-bits) and there is some bad coding in Unity (casting a pointer to a long and then back to a pointer). These problems can go unnoticed for a very long time if memory usage never approaches 2GB. Why 2GB and not 4GB? Signed 32-bit values are -2G..2G, unsigned are 0..4G, and signed values are used for offsets, though getting an offset > 2G is much rarer than getting an absolute address > 4G.

Half baked? It is well known since the release of 64 bit Windows that the compilers follow a LLP64 model where the Linux community decided on LP64. That is Windows is long long and pointers are 64 bit, Linux is long and pointers are 64 bit. Microsoft chose LLP64 for a very good reason, so that when companies started moving towards 64 bit, nothing changed in their build process. There are lots of companies that like to build with warnings as errors, and this would have been a breaking change with a sudden load of warnings, treated as errors, that brought the build down.

Now the problem with calling it half baked is that there are well known standard types that come with the compiler like size_t, intptr_t, uintptr_t, ptrdiff_t and the whole stdint.h header that include typedefs that name the size of a variable (like uint64_t). So there is nothing half baked here, the Windows compiler follows a well established format. The size of the types are published and well known and the C/C++ standard doesn't actually dictate the size of the types past how big they are in relation to each other, with char being the smallest.

So if you want to blame and find fault with anyone it is the Unity devs not using types like size_t, which are always guaranteed to be the same size as void*, instead using platform dependent types like int or long.

[Eskandare]

I'll take a proper look later today when I've got some time.

This is because 64-bit Linux is properly 64-bit (the long int type is 64-bit: same as pointers), but 64-bit Windows is half-baked (long is only 32-bits) and there is some bad coding in Unity (casting a pointer to a long and then back to a pointer). These problems can go unnoticed for a very long time if memory usage never approaches 2GB. Why 2GB and not 4GB? Signed 32-bit values are -2G..2G, unsigned are 0..4G, and signed values are used for offsets, though getting an offset > 2G is much rarer than getting an absolute address > 4G.

Yes that makes sense since windows was built off the same platform since Win 3.11. Just as a side thought, what I don't understand is why Mac OSx is still x86 when it (supposedly) based more off of unix platform.

Half baked? It is well known since the release of 64 bit Windows that the compilers follow a LLP64 model where the Linux community decided on LP64. That is Windows is long long and pointers are 64 bit, Linux is long and pointers are 64 bit. Microsoft chose LLP64 for a very good reason, so that when companies started moving towards 64 bit, nothing changed in their build process. There are lots of companies that like to build with warnings as errors, and this would have been a breaking change with a sudden load of warnings, treated as errors, that brought the build down.

Now the problem with calling it half baked is that there are well known standard types that come with the compiler like size_t, intptr_t, uintptr_t, ptrdiff_t and the whole stdint.h header that include typedefs that name the size of a variable (like uint64_t). So there is nothing half baked here, the Windows compiler follows a well established format. The size of the types are published and well known and the C/C++ standard doesn't actually dictate the size of the types past how big they are in relation to each other, with char being the smallest.

So if you want to blame and find fault with anyone it is the Unity devs not using types like size_t, which are always guaranteed to be the same size as void*, instead using platform dependent types like int or long.

That, I didn't know.

Edited October 13, 2014 by Eskandare

[NathanKell]

OSX has been x64 for a good long time; it's the Unity client (that runs KSP) that is x86 only for Mac.