msnbcorp

Hum, this, principia, Background Processing and few others like Deadly Reentry, but yeah, i agree !

Why gcc g++ are a problem for building in win64 ?

Hi, just to say, it would be good if you can integrate you're mod with ETT. Currently it's not playable with ETT, it break too much the career mods.

Hi, i'm not sure to know what is the problem and if it's about distant objet : i can't see myu skybox while in KSC. Don't know with what mod option i have to play with to have beautiful star on kerbin ground. If you have an answer i tak it thanks ! Oups my bad, it works, it's just very dark.

Hi, has someone any good cloud in high res ? I'm very tired of the crenelated cloud we can show in mid altitude ... and i have a good graphic card ^^. If someone have that, i take it

OK, thanks for the tips. My main problem in KSP is about grass actually. Grass and terrain around KSC is just HORRIBLE. So i test several option. The terrain for stock terrain enhancement was my first one. But, don't know what the author missed, its DDS files have lot of probleme under DirectX11. Really don't know why... Do you know a good terrain enhancement somewhere in DDS for Kerbin ? I don't care about high res, i have really good gpu

Hi, And if you want to only be applied on a sub-part of the planet ?

Ijust lookat this mods and i.... You are creazy and just realize my dream. Also little question. At the begenning they choose two bodies maths to have the mathematical analytical solution and ensure stability through time of the orbite. How do you ensure that moon doesn't crash on earth ? In how many years in game a deviation in orbit can be seen ? Bravo for this mod ! Plz do a 1.2.1 version ! We love you XD

Hum, unless a major problem exist with DDS, as it is the case under DirectX11 where some bug exist. Replacement texture of type DDS seems to cause weird bandlining stuff... not all of them but a large part of moded ones. (like in SVT for example) the solution is to transform it into png. It works but the absence of mip map make the texture weird at long distance, so the Texture replacer functionnality become important. Well, for the skybox it's an other problem, it's a png at first. So you say i have just to transform it into a DDS and to not do any integration of mipmaping my self and it's good ? Or i have to include pre-generated mip map of high quality ??

Yeah but in my message i analyse this possibility. It's a functionnal one but the communauty has choose to NOT use the FINAL keyword in mod config. Because it work and appear to be a good solution for one patch, but others will use it and very soon every body want to be the last and use FINAL. At the end, the alphabetical order win between all the final XD. It appears already in certain mods so it is categorized as a very bad practice. It must stay a keyword only used by final user.

OK, thanks for the answer, it sees to be valid but with multiple mods it could give a lot of copy-past for each cfg... I will try but i think i will try to see the code of MM for better solutions with multiple AFTER/BEFORE.

Of course it works but only in MY CASE because i choose to have this particular two plugins. The second and first are plugins, they are not mean to need one of them ! They only need the first one to run ! they just patch the same thing ! I should give the example because the plugins philosophy seems to be hard to understand ... I have a mod name SVT, it patch kopernicus on all the solar system. it just need Kopernicus to work ! And they should work with only kopernicus I have an other mod that patch the sun (lightFixer) on only one or two parameter. It also should work with Kopernicus only. These two mods are in conflict. The second one don't have to depend of the first one (!) . The theorically good solution in this thing are : First one -> no change Second one -> a routine that say [IF FIRST ONE DETECTED, THEN LOAD ONLY AFTER THE FIRST ONE] or [EXECUTE ME AS A FINAL PATCH EVERY TIME] or [EXECUTE AFTER {list of mods}] As AFTER don't "need" the mods to be loaded i guess, the third solution should work too. Well, the point it, nether of this solution are easily makable with MM. The first solution is generally, as i can tell, implemented when needed directly in the code of the plugin by conceptors, which is a bit ugly. And in the main case it's just not implemented and a potential wrong order of loading is juste let as it is. The second solution can be done with the keywork FINAL but it's prohibited by the communauty because every single patch want to be FINAL and there is no warning of MM about this... so alphabetical order win again ... The third one should work with a clever, not linear, manager... iot's generally the solution used in other software, combined with warning message. buuuut.... it's just not implemented... So alphabetical order win again ... Hum it could be done .... it's a classical sort algorithm, nothing difficult. The difficult part is to warn the player properly and to detect imcompatibility ^^. But it could be done, it's a classical subject on the net the multiple AFTER BEFORE problem. I will look at the code next week.

It's not bad practice, it's plugin practice. Some mods work like First->Second->Third. In that case there is absolutly no problem, MM was made to do this. Some other mods (FAR, texture replacer, Kpernicus etc...) the major one works as base for other mods. This give a star patern. Other1 <- First -> Other2 (representation whith only 2 but it could be 50) In a star pattern of plugin you can absolutly have a mods wo plug the entire solar system, for exemple, and an other which tune the sun only. And the fact that you want the second one active is not a bad practice ^^. The fact that the second one HAVE to work without the first one have also to be keepen. It's how plugins work. In that case, whith other software, the good practice is known, but MM doesn't seems to have it. The good practice is to have a complex manager that understand a mods which says : " On that point i want to be the last one", "On that other i want just to be after this one and this one". Of course it leads to conflict and the complex MM should warn the player about that. But it is clearly the good solution. The solution of MM with a linear search of each FOR, each BEFORE, each AFTER etc... is just the simplier one, not very clean. Some expert of MM have run into the problem and suggest only alphabetical order to contourn it and make an artificial order it's clearly not a clean one. It's an important missing feature of MM.

Thanks for the answer. With the lacking of RealHeat and FAR we all are in a realism hole in KSP, this is sad ^^

but but, it's seems fairly unlikely ... OK, let's assume you're right. This model is generated with a "tile-spacement" superior/not related to the one used for the standart ground, right ? edit : To continue my thought : Is it theorically possible to change the model of the KSC ? For example to extend it around and personalise the ground ?

Hum, and what happen when you upgrade ? it exist all configuration of the building ?????

OK, but KSC is not one building only no ? it's a compil ? So there is 7/8 part of KSC, yes ? with each a ground texture around ?

So let's me resume : the "not very green" textures around the building and roadway are part of the center itself (the building) ? And the standart one around is the classic PQSmod textures repeated on tiles ? Am i right ?

I think we can find a right middle about this. It's right that version checking have advantages and inconvenient. And i think it's wrong to complain to a mod creator, the fact that ksp mostly works on mods is mainly due to thelack of skills/times/good distribution of money etc... of the main devs... modder are just patcher here. However, the fact remain that the vast majority of ksp mods are NOT version locked. So maybe objectivily it's a good behaviour, may be not but here it only bring imcomprehension ... I think the AVC warning is sufficient for this purpose... Other subject : Little question about kopernicus : Is it possible to place building (and if yes, how ?) or/and personnal texture on ground of kerbin at specific places ? I wonder if it's possible to make a "hand drawing" big texture around KSC for the ground...

Tested Kopernicus on 1.2.1, seems it's completly broken.

There is a branch for 1.2 posted several pages ago. But it is not intended to be downloaded. Tested it on 1.2, it don't work and mess the control surfaces sooooo..... I think we have to wait, in pain.

Is this mod continued anymore ?

It should be good to add a AVC .version file ^^

Hop, figure out how to make a clean modification. You can rename the directory with a '0' before the name. As it seems it is the only way to not use Final keyword. So you can use with this the simple AFTER[Kopernicus] Also, i don't try but Kopernicus has a Kopernicus.component keyword which load after kopernicus. AFTER[Kopernicus.component] could be an other solution.

Hi, is the toolbar implementation bug fixed ? it seems not on my version ...