Jump to content

msnbcorp

Members
 View Profile  See their activity

  • Posts

    160

  • Joined

  • Last visited

 Content Type 

Everything posted by msnbcorp

  1. msnbcorp
    I use KSP++ and floodlight and Kampus. I will test it ^^.
  2. msnbcorp
    Hi, just here to report some installation bug. It seems that somehow there is a bad connection between CKAN and USItools. The good versions appears in the CKAN viewer (last version on github), you can install it without any glitch BUT when you try installing others usi mods it keeps saying : "Module USItools has not been found, this may be because it's not compatible with the current version of KSP". and if you install USI tools alone before it say that the version needed by USIcore is not the same as USItools. (it mark it as red highlight for incompatibility) Well, just to let you know
  3. msnbcorp
    I'm going to try it ^^. If you have some time, You should update your spacedock asyour CKAN is connected to Spacedock for versioning it is frozen on 0.9.9.6
  4. msnbcorp
    It's just some ideas, no pressure ^^
  5. msnbcorp
    And what about a simple solution like scaling the EC ? Like, the battery capacity is also scaled and here have 1000Ec ? In fact, it is same thing as describing the battery not as EC capacity but as "which capacity by step i can eat assuming other processes eat it". It could work fine. Of course it's imprecise, and lot of case could be more easy to use in warp that not in warp (charge-discharge non linear phenomenon) ... but don't think it could be notice (we notice what is difficult and kill the mission in warp but not imprecision that make the thing more easy...
  6. msnbcorp
    It's a managing system for power reserve that are kept from the primary network unless people activate it (but in a little amount). It's to avoid the terrible effect that occurs in warping when, for exemple, you need a little amount to deploy the thing that will get you the power . Very usefull to avoid inatention problem to destroy a complete mission. And a very common mod now. For the analitical solutions you are mostly risght, as you can't guess the income and outcome of current (could depend on lightning etc...) it could be difficult to summarize that... But, you should not have a problem in warping, as all variable (income and outcome) are scaled, you should be able to just use your non simplified equations without error. (as for the current charge test in stock indeed). Maybe you should also use Background processing for this too ^^.
  7. msnbcorp
    I guess it could be possible to solve equations to have exact analytic solutions depending of time. So no problem in warp time Little question : does your mod fit well with ampyear power management ? I don' think so, but asking ^^
  8. msnbcorp
    Maybe he has Scatterer installed too, that could play with cloud shadow... edit : i have made some experiment about the processing of EVE. It's a bit tricky ^^ but i managed to play with ^^. My question remain the same though. I didn't manage to understand where did the perlin noise apply. From the ground it's like there is no noise at all (replacing texture by an assymetric one make it clear that it's just a tiling of the detail texture) . But from space playing with UVnoise parameter seems to change the global repartition but don't know hoiw exactly. It play with transparency ? Position of the detail texture ? I guess it's the first one ... If i guess right is it like that -> main texture -> Multiplication with perlin noise -> Multiplication with a tiling of detail texture defined by detail parameters. Am i right ? At this point i succeed to make a thin layer of Cirrus using the Cirrus of old version or SVE for details and raw satellite data that give cirrus distribution upon earth in a day. The result is pretty good but the main texture is not very detailed (satellite data L3 pixelized), not a problem in space with large detaildist but ugly in the main menu . reeedit, and well, as i like (and works) in this domain of science, i have read some interesting thing to modelise beautiful cumulus. (like this : https://hal.inria.fr/inria-00537462/file/BN04_clouds.pdf).Pretty easy to implement ^^. In fact it could be very simple to use pre-generated 3D cloud if we simply make a loader in eve that load simple config file with position information inside as an improvement parameters for layervolume and then use it to display pregenerated cloud made by hand rather than implementing complex algo. Of course after that it could be necessary to have a very wide range of drawing particle but .... well, still an idea though. Just asking myself if it could be possible to have the same effect with multiple layer of 2D cloud that cut the pre-designed cumulus in several layer as there trigger the particle generation ...
  9. msnbcorp
    As i said ont he EVE topic, don't know why but it's a very specific bad interaction : So, well, don't know why but you're pre-release fix the symptoms ... Still try to test your beta though Our guessing in EVE is that it's due too to a specific version of EVE (only the last one cause the bug) . May be it's a starting point for you. Making the diff between the two versions could help you to understand what have changed that can interact with construct. I guess it's shadow or other thing like this about shadow and transparency on the facilities ... If it's due to bad routine interactions, may be you could try a separate process like Principia does ... it's a bit harder but then you code into C++ directly and so can launch whatever you want when you want ... edit : it seems that you are right about the order of loading, see this response of @Waz : So well, perhaps it is not the shadow but truely the order of loading. Because now EVE load at the begening of the game and before it was not the case. So conflict could occur here ... there is really no actions to force a mod to load AFTER on the loading screen ? An idead of a quick fix : just don't load at the screen menu, only ingame ? After all, who cares about KK running in the menu ?
  10. msnbcorp
    Thanks, in fact i figured it out myself before reading when experimenting. The strange point appear to be the repartition of cloud when you go from main texture to detail texture. It seems that the tiling effect come from here. I think you use kind of perlin noise for determining where goes the detail texture. (but i'm not sure of that point, in my memory, perlin noise have nothing to do in it's simple expression with the merging of 2d sub-texture in a coherent thing, how do you process this aspect ? I have view several conf about algo that does that but i don't think that you use modern imaging science for that ^^, like "image quitting") Or, maybe you just "and" the texture repeatitivly and apply perlin noise after ? If you use perlin noise for repartion of the texture, you should not have the tiling effect. There are good solutions for avoiding that without extending the subtexture. If it's the second case, it make more sense. Beside, the repetitive pattern seems to be too much repetitive, even for a bad tuned perlin noise. Even though, i manage to have good resolution from the ground without repetite pattern in your actual system. But it's hard ^^. And can not be done at low altitude (so my cloud layer is high ^^)
  11. msnbcorp
    I got that. Reading reading the code of EVE were very interesting ^^
  12. msnbcorp
    And, for me the main advantages : modern scatterer are based with DX11 in main, which fix some problems. Beside, you could take advantages of this section : Changing this parameter make thing way better. The terrain shadow of scatterer cas be used without introducing hard difference between planes.
  13. msnbcorp
    Hum i see, but you can install via CKAN the large mass of mod and leeave to manual install the rest no ? Beside, don't see why realism overhaul is important for RSS XD or even infernal robotics ...
  14. msnbcorp
    Isn't it possible te just do it in many steps ? Like a cloud layer visible from KSP but which fade quickly and can not be seen from low altitude ans an other layer in high altitude only here to have good rendering from high altitude... for example. I don't understand well the melting of PQS system and EVE. Release me of my doubts, the fading between the big general texture and the particule are not related right ? It's juust fade, but the generation of the cloud have nothing to do with the distribution of the cloud on the big kerbin1 texture, wich is only here for scaled space ? Am i right ?
  15. msnbcorp
    I will test
  16. msnbcorp
    I certainly don't get it, i have little experience. But i imagine this is due to the fact that in low orbit it render too much cloud or things like that when the cloud system is running yet and have not let place to the big cloud texture ? Or it's no that ?
  17. msnbcorp
    Understanding that, no problem. But the problem you mention is only a problem in high orbit when you have to deal with the global cloud texture, and it is a great work to produce this "kerbin1.dds" in so high resolution etc... no problem about that. And i understand that turn down the detail, but the result is better from the ground. I'm pragmatic ^^ one problem after one. How to deal with this result from low orbit when the global texture is not here again is an other story but i feel that it could be solve with the EVE tool without deleting the advantages of beautiful cloud from the ground. Here again, criticizing here is purely pramatic, not personnal.
  18. msnbcorp
    It's not necessary to take criticize as it is personnal. I just try to improve these aspect. I will see the problem in low orbit ^^. I didn't make it in the GUI ^^, but in the cfg.
  19. msnbcorp
    Hoo, thanks, i was missing that ^^
  20. msnbcorp
    Well, re-Hello every-one, do you remember when i came here to complain about my ugly cloud ^^ Well i manage to find the cause of my feeling and correct it VERY easily. And well it seems to be mainly the cause of strange choice in SVE. Don't really understant why theses choices. As i came here, I report here and then point SVE topic here. So the cloud first -> During my debugging i test SVE alone and ... WOOO, beautiful cloud ... far from the "you never get better" that i was told when i came with my screenshots here XD. So i analyse the difference in the .cfg and it appears that if SVE add layers it decrease drastily the detail level too. By default in EVE it's 30 and in SVE it's 10. Just to compare -> SVE parameter : EVE parameter in SVE Farrrrrrrrrrrrrrrrr better. I keep asking my self why, just why a mod designed to be "for high end computer" or "the most beautiful config to EVE" choose to set important detail parameter far lower than the stock EVE ... mystery for me...
  21. msnbcorp
    Small question, how to open the GUI ? forgot that ^^
  22. msnbcorp
    Yes sorry, it is already post in KK ^^ and as the bug is between the two mods i have posts on the two topics
  23. msnbcorp
    Ok, so well, keep the pre-release like that and make it a release as soon as possible. And thanks to the modders for these great works
  24. msnbcorp
    Well after some digging and experiment i managed to correct this problem. So if you have a 64bit-DX11 and want texture of SVT, here's the full solution i found. The main problem of SVT texture seems to be double : the DDS seems to have a problem with the shadow managing of unity somehow in this case in DX11 that create a common shadow problem name as Shadow ACNE and this effect remain a little even with the first problem corrected. So, the first part of the solution is to let unity do the conversion job by putting the texture in TGA (not PNG, PNG don't generate mipmap via unity). The only texture with visible problem i noticed here : https://mega.nz/#!cRMy0DKJ!locE5wM_3cglArbrGvkfM97zi28TJgcCiLC15Cbc3rg But if you find other strange effect later, just make the conversion in TGA. But, despite that amelioration it remains a little effect of shadow ACNE. I think it's due to the higher resolution of the texture. Luckily, classical solution of shadow acne is solved through shadow bias and normal bias. Two parameter that are implémented in ... Scatterer. But, not a chance, scatterer have strange effect on the plane change and shadow with terrain shadow activated. With some help i manage to solve it. Just change the shadowdistance in the config taken by scatterer (in config file of scaterrer in stock scaterrer only or in SVE config file with SVE i guess) and put it to a more default value : 5000. This value make the two plane identical. Don't really understand why, but it works. Now put the normal bias and shadow bias to a thing like 0.7 ANNNNND.... this WOOOOORK ! ! ! ! ! ! In short : - take this texture and put it in SVT/terrain AND delete the old .dds files corresponding. - find the .cfg of scatterer that you use (and install the last version of scaterrer of course ! ) in SVE/scatterer or whatever. - change shadowdistance variable in the .cfg to 5000 - put 0.7 of value like this in normal bias and shadow bias in the UI of scaterrer on the main screen of KSP. (right-alt+f12/f11) by default to open. - > ENJOY DX11 SVT
  25. msnbcorp
    Hum maybe it's the reason why it is not related to my last bug. But this remain that my observed bug don't happen with the pre-release... and is only related with interaction between "last version of EVE" + "release before pre-release of KK"
×
×
  • Create New...