WinkAllKerb''

pmed ya + yup yup i hate convex colliders too xD edit: (& can't wait for a "crew manifest" like things to be a stock feature so this kind of hatch could be an intermodule insteed of being required on each habitat or command pod should save lot's of rockets height)

Just wanted to share this while waiting for an official release with a larger set of parts. This should come in replacement/addition of my actual Welded stock part. (big img & small txt sry http://i.imgur.com/rB1NWLc.jpg A few thing are missing, or need to be fixed but not that much (a few mesh hole, may be reasign some uvmap, improve textures, some missing door etc., a few anim mesh details here and there too like some axis, improve collider cause i was lazy on the face count for testing ... ). temp download for live testing: http://www.4shared.com/zip/2wOhY8So/WaLiKe-1.html enjoy. (all right reserved until first spaceport official release) EDIT: now need to work on the storage cube modules: wheels, landing legs, various utilities and science etc.

Been away from KSP for a while but after a really quick check (vab + launch pad) all parts seem to work. but they re not updated for the science tree and will probably never (in fact i m slowly upgrading them to something else, not really an update http://forum.kerbalspaceprogram.com/threads/59951). I m working on something kinda different right now using what i have learn from this (not in it's final stat may change a lot): temp test download http://www.4shared.com/zip/ETzLebmt/WaLiKe-2.html (include the habitat but not all the inter chassis and slotable boxes) http://www.4shared.com/zip/LlAADzyz/WaLiKe-3.html (without the iss textured habitat but include the 5 inter chassis and some test slotables boxes) i have much less time to spend modding actually unlike this summer but here the first shot of an intermodule wich should be part of a much bigger project (licence won't be the same as actually) i have in mind and on paper. (i m still testing a lot of thing so this part will probably change) any return concerning the texturing or else welcome (this is my very first attempt ever with texturing and bump map so ...) idea is to provide many cubic module (weight and size standardized) to slot in the way you want (even a Kerbal xD), wheel, landing, various utility, science etc + some structural, habitat, command pod in the same spirit. edit: WaLiKe for Water-Light-Kertilizer (should be a mix of life support + ressource collect/refine to use, first i focus the parts i'll see for the plugin side later) i do believe kerbal are some kind of plant being and require CO2, fertilizer, light, water etc insteed of food, O2... Herbal Space Program inside in some way for sure ... and HPS are already stock parts so

xD @grey, not sure 'koan' usually mean something at all especially when they are spelled with an english as bad as mine, but dare win shake spear evolution of this thread from a rorschach point of view is kinda interesting. It's a WAK a(like) mole story: When H meet H'it result in a big bang He laugh wich could sound weird @ first but this old story is made from ashes and will also return to ashes without any lie senses hidden in it. Let's try a /yawn i heard it's communicative. (N.A.: all word in this post, that are made from letters wich themselves are derivative of some older caracters and ideo/picto-gramm that evolved for thousand years are under the license of almost everyone forgotten who, yes i do aggree memory lacks are sometime convenient to make word your own) I got a chicken in the garden and it's eggs breakfast time, or may be i have an eggs and then a chicken ... bah nevermind let's focus the break fast.

Jefferson is pretty young, you can't write anyithing, this thread, thoose posts, some source code without copy past(e), or at least rearranging it, using some letters and caracters, i paid my licence for using caracters i have some dictionnarys at home. So yes headhunter you must be allowed to use letters and caracters in some way. As Grey said all modding aspect are pretty easy what miss the most actually are fair doc to get faster in + all supiscion and tackle around the modders forum(s) wich from a "vet." player point of view stink like ... but i can understand thoose who are all scary of each others. NoMrBond will probably react to this etc ... Speaking of EA & Maxis, i love the fact Ocean Q. sailed away to sea if he can work on some indies plannable natural disaster simulation. some Jule Vernes sub'visions are so true ... To cross post an answer of what's PoleCatEasy said in one of his thread: dunno if the gaming industry lost it's soul, or intend to sink as many players ones as possbile. DaMn that's a lot of lost soul sacrified on hypocrisis hostel, we all know who take advantage of this and where it lead ... WAK before things turn too bad once again, wich in case of ksp will be a terrible waste, but hey it's just a player able to mod advice rearrange this advice the way you want it's not under any licence ...

great work polecatz, tetris graphics are basic but it's one of the funniest game ever on the other hand some game with great graphism are craps so ...

no it won't, just a better knowledge of blender and unity is helpful to get the best from {model} so i ll give this a try, it s just an alternate path of combining classic 3dmodelling with {model} edit i m exploring while waiting for 0.22. Fact is i m not totally satisfied using config edit only to create the part i have in mind, some part got way to much imbricated tris and texture inside them uselessly calculated, working on basic material (existing stock part) i note created is sometime painfull figuring out a few things , include all functiuonnality/module i want too, doing certain kind of specific weld while reducing parts count, self made basic material will be better for this but one of my main concern remain to keep things light regarding memory with not too much texture at all. Thing is i don't know how the hardware/software/driver manage this if it's better to have a few bigger texture shared or not within parts with all the Uvmap on thoose texture, or some little ones shared or not too, it all depend how the temp object is managed by respective cpu and ram and the mapping process but i just know nothing about this and it s a bit hard for me to explain exatcly what i have in mind in english. Stock part 3dmodels frame and textrue may change like it happen once, wich mean lot of work reworking each edited config. Self made basic material should minor this aspect too.

http://www.4shared.com/zip/gzDTBP2B/mmbtest.html Just sharing a [wip] test file including, ksp and blend file, if any "benchmark" guru is kind enough to test it and give feedback regarding feeling around the memory use // with the uv mapping and texture sharing as i don't know much about this. (i plan to shares texture within all set's part example the door one, sas one, monocolor one(s) wich will be 1x1, and the gold one and i dunno not really know if mapping this way is interesting regarding processor and graphic card memory use) this is an early first shot with some things to adjust. - UvMap(s) size and there transform will change and be improved (this is mainly conceptual) - textures quality/details level/size and mapping will change - some nodes animated or not are missing - a few tris normal are oriented the wrong way - two small tris are not mapped at the right place - Collider are not opti and some missing - 3dmodels details may change (especially the animated bottom mesh for the wheels) - some vertice location will be improved/removed regarding tris count and mapping (same with all the useless edge my concern here was mainly to test mapping and anims) This part is an example of what the MMB interchassis modules are turning into.

definetly a nice addition to any tuto, example files always nice to help understand things (could save lot of time finding mistake while learning).

Testing a few thing around this i should share a part in the next day: (just need to fix a few anims and nodes wich is a bit painfull cause i m new to blender and unity and shortcuts knowledge miss me xD) I splitted/merged/overlaped the UvMap/objectsFaces with some specific pattern/transform amongst the layers: so some different faces(even if there own geometry are different) that don't require detail use the same small 1x1 monocolor texture mid detail use 128x128 or 256x256 and higher detail use a few 512x512. Dunno how this split within the cpu proc and graphic proc regarding the hard/soft mapping process just need to fix a few more thing to test it properly and see if it help with some of the memory aspect. (+ the texture used for this part will be used for other part via this uvmap splits/tranforms/'pre planning' that can be shared amongst different models, i intend to reduce the number of texture of a parts sets this way as most of the set's parts will be build with some {model} cfg to take advantage of this "contents" sharing possibility, it all has to do with some uvmaptransform that allow to overlap some differents faces geometry 'within a'/between 3dmodels with the same texture but not sure yet if there is a true gain in perf) I wonder if doing so help memory a signifiant way too once in flight.

adobe cs2 even if it's now a bit old it's still a very powerfull suit and it's now "free downloadable" (google it for detail around the little mess with this "free" release) from adobe site.

xD TMS, i got a new thing you can add to the little draw: piloting in a game is cheating piloting itself, ask ayrton senna he could explain what true piloting is ... else ask the wall ... else keep believe your not cheating too not using mechjeb simulating piloting in a game wich is not the fact, the fact is that the first thing you cheat, not using mechjeb and believe your not cheating, is yourself xD. GO hard for real buy a formula one car ! ... = buy a mirror and watch yourself cheating too ... that's easy ... thoose mechjeb thread on and on are so dumb ... (*shrug*)

;) (10 char)

mechjeb allow me to eat some chips while playing; kinda the same with thread about mechjeb ... (oops i contributed in one mechjeb thread after resisting almost two month, shame on me ...)

clap clap & Cheers

Totally aggree with the 3 last posts, the more basic materials (aka different mod whatever there "quality" wich is something very subjective) you're able to choose within the more combination you can done from thoose basic materials, simple probality and stat law. KSP modding is amazingly open and that's a great thing. Thanks Squad. History proven many time any sort of Elitism'only' always finish with dead ends: "Kerbal Mode Elite Quit" - Münraker Kerman

licensing, and (all kind) of property is a pretty old story in human history i usually sum it this way: © is a combination of a "c" + a "o", after investigation around alphabetical and ideogram genealogia you can learn that the "c" we use in our occidental alphabet as for original meaning a "open house" and the "o" represent a garden wall around this house, this is something like as old as first ideogram used by human kind (so yup pretty old story): "i open my house to other and i protect it with a garden wall." nowdays wheels are used everywhere should we give something to neanderthal ? + garden wall are not that strong to protect some 'virtually inexistant anykind of property' xD combine thing together is an old human process, and licensing thing that belong to all in some way is imho kinda silly sometime. 400 years ago royalism ruled the world, nowdays greedy capitalism wich consist taking property upon thing that belong to everyone to generate self profit, what's next ? (what's before !? a yes i remind i take a club hit my neighboor and take what i want from him => neanderhtal® approach, as said very old story xD) i do love this kind of artistic and concept/design approach: These works are of Ukrainian Mark Khaisman to realize it just uses big brown scotch glue it on a sheet of plexiglass. He then plays the tape layers and transparency by illuminating his paintings from the rear. so when speaking of license thing can become very relative sometime, especially when we all made things based on someone(s) else things (does this artist has to pay something to the glue and scissor/cutter inventor ? it's like saying i would have to give money to bill gates each times i copy paste reassemble some existing things together, wich is sometime sadly the case in some way xD) most mods support come and goes it will always be like that and thoose kind of mod should use soft license, for mod that pretend to be future dlc with maintained support as long as ksp is supported too i can understand more protective licensing regarding our current commercial/business model else ...

yup i learned lot of thing from some of bac9 *.cfg file that use {model}. from the first tests i made: You could apply any texture even if the size is different from original texture size as long as it's a square image it's mapped correctly on to the part *.mu, so it's just a resize all img + overwrite without any need for rename while the *.cfg stay unmodified, it also allow a lot of others thing when the UvMap of a part is known from monocolor, to total new rendering, to different quality etc. MODEL { ... texture = "UnityATextureObjectOriginalName(*.mu file relative)" , "NewAppliedTexturePathAndName(whatever you want relative ;)" } just this in fact is kinda powerfull in itself but {model} are so much more (@lovely devs bis,ter,quar want more {models} parameter if possible whenever you have time for this ;o) EDIT: and here the related thing in each *cfg: PART { ... } MODEL { model = WakTiab/Parts/models/[COLOR="#800080"]cylindre[/COLOR] position = 0, 0 ,0 scale = 1, 1 , 1 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. texture = [COLOR="#800080"]cylindre000 [/COLOR], WakTiab/Parts/[COLOR="#800080"]models/cylindre000[/COLOR] // 256x256 } PART { ... } MODEL { model = WakTiab/Parts/models/[COLOR="#008000"]cylindre[/COLOR] position = 0, 0 ,0 scale = 1, 1 , 1 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. texture = [COLOR="#008000"]cylindre000[/COLOR] , WakTiab/Parts/[COLOR="#008000"]img/cylindre000[/COLOR] // 256x256 } PART { ... } MODEL { model = WakTiab/Parts/models/[COLOR="#0000CD"]cylindre[/COLOR] position = 0, 0 ,0 scale = 1, 1 , 1 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. texture = [COLOR="#0000CD"]cylindre000[/COLOR] , WakTiab/Parts/[COLOR="#0000CD"]img/random000[/COLOR] // 128x128 PART { ... } } PART { ... } MODEL { model = WakTiab/Parts/models/[COLOR="#FF0000"]cylindre[/COLOR] position = 0, 0 ,0 scale = 1, 1 , 1 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. texture = [COLOR="#FF0000"]cylindre000[/COLOR] , WakTiab/Parts/[COLOR="#FF0000"]img/random002[/COLOR] // 1x1 } the first example could be easily used for fast change a full set texture quality just by overwriting img with different size as *.mu and *.cfg (and so name and path) stay unchanged.

Thats aslo what actually bug me welding some stock parts, always has to spend way too much time figuring out how each part was modelled. Plus when you start complex welding thing with lot imbricating and/or superposition, you have a lot of "unused tris" calculated by the engine wich is not real good at all @ some point. And also it become real tricky and brainwashing with object with very specific properties (animation,iva, hatch etc.). Weld with {model} is a real powerfull tool, i ll try to see how i can use this with very basic 3dmodel and light/small.texture of my own that i intend to share between the part planning the uv mapping and texture and sub model assemble modularity @ first. Sound pretty nice for the memory use. I do believe the use of {model} need to be promoted regarding the exisiting popular parts sets that eat way too much memory. i also especially like the fact it's a very easy way to provide different "quality texture set" for a perticular "parts set" that could fit to almost everyone computer performance (1x1, ..., 128x128,256x256, ... 1024x1024) each part cfg* stay the same you just have to install the texture pack that will fit your computer.

some nice idea around welding And great use of lights.

It all depend both from "3dmodel tool" unit & scaling + unity scaling before the .mu you want to work with have been exported. Depending how the part has been initiailly made regarding this you can quickly get the multiplier/divider for {model ... scale = x,y,z ... } the way you want

Trying unity and blender since yesterday. But i m kinda stuck with this: So far i m able to make a single UVmap + a single Texture to work (like the green circle) but i m unable to figure out how to use multiple texture (like in the red circle) tried many tuto for multiple texture but none of them worked for unity and ksp export. Edit: nevermind, got it is related to the use of multiple 3dmodel from blender in a single gameobject unity hierarchy.

got almost the same matter a few day ago with welding stock part via config edit: i can confirm a decal of 0.5 seem to be ok, same for some rotation and scaling around the shared coordinate origins, different origin overlaps is very important as TT explained very well in his tuto The part in itself (watch for notes) PART { name = wak-mmb-command03 module = Part author = Squad, WinkAllKerb' MODEL { model = Squad/Parts/Command/[B]landerCabinSmall[/B]/model [COLOR="#FF0000"]model used for the hatch collider (must be the first model with a hatch in the hierarchy)[/COLOR] position = 0, 0 ,0.05 [COLOR="#FF0000"]slighty translated[/COLOR] scale = .75, .625, 1.125 [COLOR="#FF0000"]scaled not to interfer with internal/iva camera[/COLOR] rotation = 44, 0 , 180 [COLOR="#FF0000"]rotated to fit the model + not to interfer with internal/iva camera[/COLOR] // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Command/cupola/model000 // texture = model001 , Squad/Parts/Command/cupola/model001 } MODEL { model = Squad/Parts/Command/Mk1-2Pod/model [COLOR="#FF0000"]model used to fit the iva/internal camera origin (pos, scaling and, rotation have to be reported to the iva with transform[/COLOR] position = 0, 0 , 0.050 [COLOR="#FF0000"]translation[/COLOR] scale = .95, 1, .95 [COLOR="#FF0000"]scaling[/COLOR] rotation = 20, 0 , 0 [COLOR="#FF0000"]rotation[/COLOR] // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Command/Mk1-2Pod/model000 // texture = model001 , Squad/Parts/Command/Mk1-2Pod/model001 // texture = model001 , Squad/Parts/Command/Mk1-2Pod/model002 } MODEL { model = Squad/Parts/Utility/CircularIntake/model position = 0, 1.10 , 0.45 scale = 1.1, 1.33, 1.1 rotation = 20, 0 , 0 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Command/Mk1-2Pod/model000 // texture = model001 , Squad/Parts/Command/Mk1-2Pod/model001 // texture = model001 , Squad/Parts/Command/Mk1-2Pod/model002 } MODEL { model = Squad/Parts/Electrical/batteryBankLarge/model position = 0, 0, 0 scale = 0.9725, 1, -0.965 rotation = 0, 0, 0 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = ? , Squad/Parts/Electrical/batteryBankLarge/? // texture = ? , Squad/Parts/Electrical/batteryBankLarge/? } MODEL { model = Squad/Parts/FuelTank/MK1FuselageStructural/model position = 0, -0.5 ,0 scale = 2.387, 0.5 , 2.41 rotation = 0, -90, 0 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Utility/dockingPortLarge/model000 // texture = model001 , Squad/Parts/Utility/dockingPortLarge/model001 } MODEL { model = Squad/Parts/Structural/structuralIBeam1/model position = 0, 1.1, 1.1 scale = 0.33, 1.9, 2 rotation = 0, 0, 90 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Structural/structuralIBeam1/model000 } MODEL { model = Squad/Parts/Structural/structuralIBeam3/model position = 0, .35, 1.1 scale = 0.25, 1, 1.25 rotation = 0, 90, 0 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Structural/structuralIBeam3/model000 } MODEL { model = Squad/Parts/Utility/sensorAccelerometer/model position = 0, .9, 1.125 scale = 1, 1, -1 rotation = 0, 0, 0 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Structural/structuralIBeam3/model000 } MODEL { model = Squad/Parts/Electrical/RTG/model position = 0.20, 0.675, 1.1 scale = 1, 1, 1 rotation = 0, 30, 0 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Electrical/RTG/model000 } MODEL { model = Squad/Parts/Electrical/RTG/model position = -0.20, 0.675, 1.1 scale = 1, 1, 1 rotation = 0, 30, 0 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Electrical/RTG/model000 } MODEL { model = Squad/Parts/Utility/spotLight1/model position = 0, 1.325, -.175 scale = .65, .65, .65 rotation = 35, 0, 180 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Utility/spotLight1/model000 // texture = model001 , Squad/Parts/Utility/spotLight1/model001 } MODEL { model = Squad/Parts/Utility/ladder1/model position = 0, 0.275, -.975 scale = 1, 1, 1 rotation = 0, -90, -44 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Utility/ladder1/model000 } rescaleFactor = 1 node_stack_right1 = 1, 1.1, 1.1, -1, 0, 0 , 0 node_stack_left1 = -1, 1.1, 1.1, 1, 0, 0 , 0 node_stack_bottom = 0.0, -0.875, 0.0, 0.0, 1.0, 0 , 2 cost = 3550 category = Pods subcategory = 0 title = M.M.B. Peggy'12-s Command Module manufacturer = Dyogenn Kerman Shipyard Combobulator Parts Co. description = Wow !!! Every train need a locomotive same goes for the "Modular Mobile Base". Feel free to choose between our models, we guarantee no ears smoke. (Cost, Mass & Breaking Resistances include a 4 Strut Connectors equivalence) // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,0 mass = 3.65 dragModelType = default maximum_drag = 0.3 minimum_drag = 0.35 angularDrag = 3 crashTolerance = 9 breakingForce = 800 breakingTorque = 800 maxTemp = 2900 fuelCrossFeed = True vesselType = Base // --- internal setup --- CrewCapacity = 3 INTERNAL { name = PeggyInternal [COLOR="#FF0000"]customized iva[/COLOR] } MODULE { name = ModuleSAS } // --- Electric Generator setup --- MODULE { name = ModuleGenerator isAlwaysActive = true OUTPUT_RESOURCE { name = ElectricCharge rate = 1.5 } } // --- command setup --- MODULE { name = ModuleCommand minimumCrew = 1 RESOURCE { name = ElectricCharge rate = 0.4 } } MODULE { name = ModuleReactionWheel PitchTorque = 5 YawTorque = 5 RollTorque = 5 RESOURCE { name = ElectricCharge rate = 0.1 } } // --- Resource setup --- RESOURCE { name = ElectricCharge amount = 4000 maxAmount = 4000 } // --- Light setup --- MODULE { name = ModuleLight lightName = spotlight useAnimationDim = true lightBrightenSpeed = 2.5 lightDimSpeed = 2.5 resourceAmount = 0.04 animationName = LightAnimation useResources = true } // --- sensor setup --- MODULE { name = ModuleEnviroSensor sensorType = ACC } // --- Air Intake Setup --- MODULE { name = ModuleResourceIntake resourceName = IntakeAir checkForOxygen = true area = 0.008 intakeSpeed = 10 intakeTransformName = Intake } RESOURCE { name = IntakeAir amount = 0.2 maxAmount = 0.2 } } notice that the main hatch is the first one that is used to enter and exit + in game part eva menu, the other hatch from the second model can't be used to exit and not seeable in menu in game but when close to it you can enter The welded iva (very basic atm) INTERNAL { name = PeggyInternal MODEL { model = Squad/Spaces/PodCockpit/model [COLOR="#FF0000"]model used[/COLOR] position = 0, -0.05, 0 [COLOR="#FF0000"]translation including transform specific to iva[/COLOR] scale = 0.95, 0.95, 1 [COLOR="#FF0000"]scaling also taking care of the specific iva transform[/COLOR] rotation = -20, 0, 0 [COLOR="#FF0000"]same for rotation[/COLOR] } MODULE { name = InternalSeat seatTransformName = BottomSeat } MODULE { name = InternalSeat seatTransformName = RightSeat } MODULE { name = InternalSeat seatTransformName = LeftSeat } MODULE { name = InternalCameraSwitch colliderTransformName = focusLeftWindow cameraTransformName = LeftEyeTransform } MODULE { name = InternalCameraSwitch colliderTransformName = focusRightWindow cameraTransformName = RightEyeTransform } MODULE { name = InternalCameraSwitch colliderTransformName = focusLeftSideWindow cameraTransformName = LeftSideEyeTransform } MODULE { name = InternalCameraSwitch colliderTransformName = focusRightSideWindow cameraTransformName = RightSideEyeTransform } } So yup yup it all as to do with merging/rotate/scale InternalCamera&iva, main part, & hatch origin to get it work near 0,0,0 for position + taking care of any collider that can obstruct the hatch (some part with mesh collider kinda different from the model mesh in itself can be a little bit anoying regarding this: some conic part with a cube collider for example )

wish all popular mod owner say and do the same as you did so we could finnally play with lot of mod together without memory crash @ load + i could stop welding stock part with cfg edit

Yop Nuin, you can solve this with a cfg edit, either duplicate some part with side main node instead of top bottom or use some fictive node if you don't want to duplicate part, concept is like GPS you introduce a "n+1" equation to solve a "n" system ( to get 3d coordinate you need a 4th satelite that introduce time for relative sats pos between each others it's kinda the same in some way) (this for non square part, way easier for square symetric parts). (i don't get lot of time right now but i ll try to give a look for a cfg later today or tomorrow, if you can't wait check HSH mod around page 13 14 there some cfg example of fictive node to solve this kind of 2 'main' node vectoring link orient axis limitation) EDIT: (was in irl rdv hurry earlier sry you can find a *cfg files using an aditionnal fictive node here and for a screenshot of what it look like you can follow my sig from there. As explained in this file i spaced the fictives node for tuto purpose but best is to almost "merge" them @ a +- 1Exp(-n) ; (with n>10) or so value (i still not verified if it work if fictive node have there coordinates 100% merged with original nodes coordinates).