etheoma

When you put it that way I do agree that KSP batteries should no be able to release even like 100th of there charge in 1 second, but as long as you have plans in the works for high capacity capacitors I don't really have a problem with batteries not working at all, and the leakage would mean you would at least have to have batteries to keep the capacitors topped off. That's the solution I would like at least so that both batteries and capacitors are useful, Capacitors with lower capacity, lose charge over time but can discharge extremely quickly were as batteries have higher capacity, do not lose charge at least as quickly "because I do think batteries should lose charge over time" but cannot discharge or charge more than like 500th of there charge per second. Although batteries should last like 3 - 5 years from 100% charge to 0%, where as I would like to see capacitors lose there charge in like an hour maybe 4 hours.

Well atleast for the test fusion reactor in the the UK they do actually use a battery bank to store energy from the grid for tests so... Its more because the energy demand is so high that it would put a strain on the infrastructure. But at the same time if you have enough energy to power the reactor you have enough energy to power the reactor, if you want to raise the bar for initiating fusion that's fine but artificially creating a way in which you can't do it is not realistic because I might have a battery bank of 100k or something like that which should easily be able to start a fusion reaction, especially in a large array of fusion reactors it would be easy to have enough electric charge to start 1 then activate the rest. Do what you want but I wouldn't use realism as the excuse, game play sure that's a valid reason but realism it is not. Having enough electric charge the reactor for 30 seconds or even 1 minute would effectively have the same effect and is somewhat realistic as although as keep the reaction going should not take that much power starting the reaction should require a large amount of power because at first you have to heat the fuel to 10x the temp of the sun after that though the energy produced by heats inside the reactor is enough. And I should say that a fission reaction is not enough to create those kind of temps. Modern fission reactors only run at around 300C and proposed molten salt reactors would only run at 650C. You would need to turn this into electricity and focus the energy to start a fusion reactor so not being able to start the fusion reaction from electric charge makes no sense what so ever as long as you have enough of it, in fact the only real way to store enough energy to initiate fusion reactor portably would be with high capacity capacitors or high output batteries AND an constant energy source. As I said Game play is a valid reason but realism is not. Also I should mention there are solutions for high capacity capacitors graphene capacitors are one root which you could output enough energy for just about long enough that would be compact and light enough to actually do it, obviously there is a higher leakage than batteries but really its the only way to do it.

The KTEC solid generator doesn't work unless you have another generator or reactor, and you can't use electric charge if you had enough to start it up which you could do in the old KSPI so I assume this is a bug. Anyway something else I noticed while testing is that the radiators are not compatible with NuFAR I assume its because of the transformation. Not something that is of high priority right now I know as getting the core mod working 100% on its own is your first priority but I thought I would mention it anyway.

Oh and just encase you thought I was using the old 1.5 tweek scales for that I wasn't, its just that with 1.5 tweek scales you can scale down the Reactors to there proper size, that and the github instructions still say tweekscales 1.5. Those bugs are with tweekscales 2.1, and just encase you are not ignoring me are you its just everyone else got a reply. Because I did put in quite a bit of time testing all of this and if you are ignoring me I would rather not waste my time. No hard feeling if you are I just wont bother any more, I don't want to sound like a whining b**** but its just if I'm doing this to be helpful not to cause you hassel if I am it would be best for both of us if I stopped.

Ok to add to the previous bug report I add that the OMEGA Fusion Reactor and "Sethlans" Particle Bed wont scale down past 1.875m when tweekscales says its 1.25m. I wouldn't mind not being able to scale down the OMEGA Fusion Reactor and "Sethlans" Particle Bed past 1.25 but 1.875 makes it kind of useless, Also a smaller bug is that as default the Small Molten Salt, Omega Fusion and "Sethlans" Particle Bed reactors as well as the small electric generator come out at 1.875m, this isn't a big problem at all for the Small Molten Salt reactor and the Electric generator as you can just rescale them down to 1.25 or what ever you want but for the other two it is. And my bad I didn't release you had changed the fusion reactors to only work with Direct conversion Electric Generators. One other thing could you change water's name in KSPI because it interferes with Tac Life Support and you can easily accidentally burn up all your water which will probably mean the death of all your kerbals, Maybe H2O.

@FreeThinker Isn't it best to change all the dependencies to the lastest versions before doing all this bug fixing well I'm basically just talking about Tweek scales, because as you are almost certainly aware the most recent version of tweakscales completely wrecks this. If it works out best the other way for you I have no complaints it was just a suggestion.

K I'm actually going to do some decent testing now and not describe the problem in so much detail and do it in a list you might want to come back to this post because I might add more after you read it. -Antimatter Initiated Reactor, Microwave Beam Powered Receiver / Micro, Deployable / Phased Array Microwave Transceiver, IR Telescope does not node attach without Non-Strict Pat Attachment Orientation Checks. -Large Fusion Reactors and Antimatter induced Fusion reactors seem broken -Also some smaller bugs are that some reactors don't show the proper scale in tweek scales. Everything else seems to be working ok, I didn't test mining or collection of any sort so that needs to be tested but everything else I think has been tested.

No Plane, No Pipe, No Life! But just btw guys if you replace the firespitter.dill and in the cheat's menu you get up by pressing Alt+F12 if you turn on Non-Strict part orientation check. B9 will work for the most part, although cargo bays are probably out unless you use FAR which should render the interior of the cargo bay without special instructions due to how NuFAR works. Also I would assume all the air breathing engines will be broken but its not that bigger of a deal.

Humm I'm re-looking over the spec's for unity 5 and it looks like it will take care of the multi threading for you and prioritize things which will take longer to get it done in the same frame... But ehhhhhh... I dunno... U4 physics has left a bad taste in my mouth and my trust in there new physics engine being able to properly prioritize tasks is lacking and it looks like there still not going to allow you to mess with that so *shrugs* One can hope it works flawlessly and Squad ports KSP to U5 One can also hope I win the lottery, and date a super model. I was just about to say you don't do all your compiling on a laptop do you but I suppose FAR isn't that big so it shouldn't take that much horse power to compile relatively quickly. I was also going to say that CPU's haven't really changed much over the last 4 years but that's only true for desktop CPU's as CPU's have had leaps and bounds in TDP reduction and power draw reduction and for a laptop that REALLY affects performance. Ok I'm going to stop not before I completely nerd out over computer hardware which isn't all that relevant.

Question: are you using pure stock? If so: That shouldn't be happening, and its not RAM that's your problem. If not and you are getting to around 3GB with mod: if your getting this crash when you have cycled in and out of the editor into flight and back again repeatedly all you need to do is reduce your KSP RAM utilization first if you haven't use the Active Texture Management mod with the aggressive version you can get your KSP RAM utilization down by maybe 50% if your using a lot of large textures, more commen is a 20 - 30% reduction but that more than enough to allow KSP head room for the small memory leak of the Editor --> Flight --> Editor leak which isn't really that big. A ok target for RAM utilization is around 2.4GB 2.6GB is pushing it and you will get crashes if your going in and out of the editor a lot I mean 20 - 30 times. If your already using the Active Texture management system then I suggest deleting particular parts you never use, for example I never found my self using the massive parts in B9, personally my self I managed to keep the memory utilization in KSP down enough with ATM so I just left them because they weren't doing and harm. the final solution is just cutting down on the really RAM heavy part mods and just taking from them what you absolutely need and getting ride of different sized versions of the same thing and using Tweek scales to rescale things as needed, also where you can use procedural parts use them because there much more RAM light, something I would like to see from B9 in the 1.0 version is to move to procedurally generated parts and just having pre-sets rather than totally different texture models. Obviously not everything can be done that way, but a lot of things could and not look any worse for it. Extendible cargo bay rather than 3 different sizes models extensible fuselage's and Fuel tanks etc. And not only would that decrease RAM usage it also increases the amount of flexibility of B9 which improves game play which is a WIN WIN. Only thing is developing it but there are a lot of moders who do procedurally generated parts which I'm sure one would be willing to help / collaborate.

I know I have said this kinda before but in an unreasonable and unattainable wish list which included such ridiculous things as using the double precision GPGPU to compute the voxels when KSP and unity doesn't even have the ability to tap into GPGPU for either OpenCL or CUDA. But on a more reasonable note but still very sketchy note is it possible if squad moves over to Unity 5 and manages to make a stable 64 bit build that you could up the voxel density or would the limitation be processing horse power at that point, if so how hard would it be for you to make FAR multi threaded. Completely theoretical and hard to answer because the system isn't in front of you and probably impossible to make a definite answer I know considering even if squad were to go over to U5 and develop a stable 64 bit build it seems from what your saying it would still be a problem to up the resolution by a significant degree due to how the KSP works. And ontop of that you still have to keep FAR somewhat reasonable in RAM as not everyone has even 8GB of RAM never mind 16GB, but I suppose if it came to that point you could make FAR adaptive based on how much system memory there is, but then you run into the problem of exactly the same craft behaving completely differently based on system spec's which is a serious problem, and thats not even getting into the time into even making it work for 1 size is hard enough. Ah there go my dreams of building a super computer and run KSP with an adaptive nuFAR on it XD 1TB of RAM Voxel me up baby. One last question and its something that you could actually answer if there was a stable 64 bit version of KSP how hard would you hit the RAM if you were going to do one size for all, if you were not limited by the KSP just usual system specs, would you be willing to exclude the bottom 10% 30%?

hasn't that been the case with every version though, as someone who runs a lot of mods and rides that RAM cliff edge quite regularly after going from editor -> Flight -> Editor etc always fills up the remaining RAM relatively quickly if your already at the limit. Usually happens because I'm being fussy about some particular thing little too much wobble MOUR STURTS different place of struts MOUR BOOSTERS!!! and so on. Na I don't iterate rockets that often any more, space planes are the thing that has me going back the editor 20 - 30 times or so, The active texture management mod allows me to get that down to 2GB - 2.4GB so I have the head room for that leak, well as long as I'm not just being plain pedantic. <--- edited that to say "plain pedantic with my craft" then I released it was a pun so I left it.

No you were right my bad I obviously wasn't looking at the right times, went from 1.9GB to 3GB... just closed it after that what's point. that is one hell of a memory leak. god squad is on a roll first they release in 1.0 heating and don't include indicators which is like a VERY BASIC no briner, then when they add indicators and they are broken as all hell... THIS IS SUPER HEALTHY SPACE, SQUAD OMEGA GOOD JOB! And I was willing to let them off before 1.0 but this was supposed to be the offical release and there releasing broken mechanics, tbh either they should have tested 1.0 to all hell or released 0.91 with all the new features then went 1.0 with just bug fixes and optimization 1.0 is for stability not features. Anyways a quick hack would be to update them only once every 2 - 5 seconds if your getting that hot any quicker than that and your going to blow up anyway, I assume its due to the high refresh rate that they pile on the memory so fast because the code and graphics behind them can't be too big.

That would show up in task manager right as the KSP.exe using more RAM than usual, because I'm pretty sure it was at 1.9GB but I would have to recheck to be sure give me a minute I backed up the broken version so it wont take me long. Although It is on a mechanic disk so... maybe it will take a bit to load, KSP on a RAM disk FTW. Although your probably right because before I added lots of parts that pop up heat indicators I was having no problems.

Anyways I'm getting content crashing when I get upto high mark numbers, its definitely some kind of conflict with another mod because I did a clean install of KSP and installed FAR and its dependencies and I can fly as fast as the heat will allow me, probably shouldn't mention it tell I have isolated the particular mod but its 2 am and yeh I wanna sleep I'll do the likely suspects tomorrow. And see if it is a conflict with FAR or whether its just an other mod but all the other mods I used were stable releases so it shouldn't be the latter but you never know.

But but, look it is writing down...

Well this is one ass that I could kiss XD

Yeh dude totally not cool, calling a dev an ass even if they do deserve it is not cool. And ferram doesn't just to be clear. There doing this for free and you have absolutely no right to complain about the way they do things. You can make suggestions etc even argue a point if there wrong as long as you keep it civil and you know your stuff, but calling them an ass is way out of bounds. Even if a mod corrupts your save games or even somehow screws up your hole computer and the modder is rude about it you still shouldn't call them an ass, because it was free and you install it at your own risk. Anything else than just delivering the mod is above and beyond and should not be expected by any means, even installing it in a user friendly manner in the final release never mind in a dev version which isn't meant for general consumption, and any help installing it is above and beyond and again especially in a dev version.

Sorry didn't see that as I was working my way down the page, And I see your point I would be a little annoyed at the content flow of ITS BROKEN!!! HELPS PLEAS!!! if it was my thread. But my nature is to be helpful when ever I can but as I said I'm not having to put up with this all the time as I can just leave after I'm bored where as you have to sift crap to get to the actual stuff which would be relevant to actually developing / answering pertinent questions. reserved and understood, anything I can do to even make your job even 1% easier just consider it done.

B9 landing gear works and most of the parts work if you turn on Non-Strict Part Orientation Checks in the debug Toolbar in Cheats. Just encase you don't know it's Alt+F12 to get up the debug menu. Also you should download the fixed version of the Firespitter.dill, also the are some price fix and tech tree fixes if you poke around. Not really relvent to me because I'm not starting a Career mode until NuFAR and Deadly Reentry are in a release state.

Did you merge the Game data folder and do you have module manger and are you using 1.0 or 0.90 because the VoxelAeroPort is for 1.0 and VoxelAero is for 0.90, and are you going to github and going here https://github.com/ferram4/Ferram-Aerospace-Research/branches for FAR. Sorry these may sound like dumb questions but it has to be asked just encase. And no I don't think your dumb its just if no one has told you to do one of these things it can trip you up. And Yes Ferram someone already told him about the ModularFlightIntegrator.

Well the 1.0 maintenance version seems to, its been patch to work so it should do. - - - Updated - - - Ah wanna say nice work to ferram as NuFAR enables you to actually get more out of your plane/space plane by putting more time into it which is great. Although after updating to the most resent FAR version that seems to be less true now, but I understand that some people might not want to optimize there craft as much, and it was a little OP.

Hummm B9 Pwings and B9 Procedural fairings managed to get the wave drag area to 0.179 m3 and the max cross section down to 3.412 but the game keeps crashing every time I get upto 1.6k m/s, I'm running an 3 day old dev version so there have probably been changes to I'll just update and hope it doesn't undo all the work Oh and dw about the images I'm using Texture Management and it makes the some icons not work *shrugs* Oh yeah its an SSTO has enough deltaV to get to space... and dw the deltaV on the image is the air breathing deltaV not the closed loop deltaV... Yeah an SSTO that can go to jool and back again with stock part f*** yeah. No it only has 1202 DeltaV in the closed loop mode but with the speed I have gotten up to its enough for orbital injection and de-orbiting

The point was that the drag was going to be uneven and also would create drag at the top of the craft in the first lunch so that was kinda the point that it would be unstable, aerodynamic efficiency was just a nice bonus. if you look at the image the craft goes on for what I assume is the orbital injection stage. Also... it looks more neat that way so win win win.

You could use infernal robotics with some telescoping parts to extend out the landing legs when you need them like so. Yeah infernal robotics is another one I suggest if you want to be able to expand what you can do. and with NuFAR you should be able to make a fairing and open and close it with infernal robotics I think, Not 100% sure on that one, or even 70%. Edit; I said the pod might have difficulty with re-entry but I looked at the centre of mass and centre of lift and it looks good although you still have those big ass RCS thrusters / radial engines which will probably screw it up, but you have the fuel in the bottom and what are you using the fission reactor for btw because do you need a 1.25m fission reactor because if your just powering the ship you could go down to a 0.625 then you can fit it in the service bay actually bring your centre of mass way down.