___

OK, for example you have two 73092 magnets in the set: just move them close enough to each other and they will automatically snap together as if you would putting two plates or normal bricks together...

The that no one menstioned here is also that the actual angle you are looking at your model (ehm, your plates) has big impact on LDD decision when it guess if you want to add that plate below or abow the actual one - try to rotate your model differently and try it several times (I know this can be real drag but that is the way LDD operates). Also another way would be - in case you rmodel is not too huge and diffficult - temporarily placing some reversed tiles underneath the plate you are adding your new plate onto, thus LDD will know that the only place where this new plate can be added is abow not below - hope you understand me.

So I will rather wait for your "final solution" for this problem when you are back home then...

You know, I am asking cos it'd be very good if there need to be just as little differences between WIN and MAC versions as possible so it'd be much easier to make. Isn't it therefor just a matter of rewriting this line: app.classpath=.:itextpdf-5.5.6.jar:xom-1.2.10.jar:lwjgl.jar:je-6.3.8.jar:lwjgl_2.jar:janino.jar:sunflow.jar ...into something like this one (I am only guessiong by the ".:" logic for the first .jar): app.classpath=.:bin:itextpdf-5.5.6.jar:xom-1.2.10.jar:lwjgl.jar:je-6.3.8.jar:lwjgl_2.jar:janino.jar:sunflow.jar or: app.classpath=.:/bin/:itextpdf-5.5.6.jar:xom-1.2.10.jar:lwjgl.jar:je-6.3.8.jar:lwjgl_2.jar:janino.jar:sunflow.jar ??? Or does it require some other changes in the script elsewhere? Please, correct me if I am wrong so i can finally add it to my initila message of this topic so every MAC useer in neeed can easily find it there.

Just a small question: are all those .jar files out of their BIN folder intentionally (so that it works only that way for MAC) or is it like that by mistake?

Aha, so if I understood it right all I have to do is I just copying whole .zip content (i guess without the __MACOSX) and updating my stuff inside Java folder there, right?

Wow, that 1st image is pretty impressive tho when you look more carefully you will see your minifigs are not put on the ground: I am suggesting you to go back to your LDD model, select all those minifigs and buildings that are hanging in the air and move them just a tiny bit - that way it all autoffsets to the base plane.

I am glad I could help you so you could make it right as you did. As for the roughness of the slope bricks: you can set the roughness strength if you find it too strong via "grainyslopes_strength" parameter in system() block of your .sc BTW for final render I am strongly suggesting using the higher "aa 1 2" value as it makes picture less jiggy and even the finest line will be intact and nice...try it 9took somewhat longer but the result is great!). Now time for bed - good night (02:00 at night here...)

Ehm, no, you have still 1024x768 as active resolution (the active resolution is the one without the leading sign "#") + fov 1 is too low, rise it to 10 or so and see what it does

Just comment out what you do not want and lt the one you want + lower the FOV value (the lower the value the closer camera to your model will be), for example like this: image { % 1:1 #resolution 100 100 #resolution 300 300 #resolution 500 500 #resolution 1000 1000 % 4:3 #resolution 256 192 #resolution 512 384 #resolution 640 480 #resolution 1024 768 resolution 2048 1536 % 16:9 #resolution 320 180 #resolution 640 360 #resolution 1024 576 #resolution 1280 720 #resolution 1920 1080 aa 0 1 #aa 1 2 filter mitchell } camera { type pinhole transform row %LDDCAMERA% fov 10 aspect %ASPECTRATIO% }

Ah, so you were talking about actual resolution of the rendered image (I thought your problem was that the model does not occupy much of the image)? OK, then all you have to do is go to Parameters tab in BlueRender and set your resolution there. In case it has no effect (you are using my MOD) then you have to open your .sc file, find the line saying "resolution" and manually change it (write) to whatever you want.

You have to change value for "fov" under camera settings in .sc file and/or change distance to model in LDD + in case you have used my MOD (I guess I see brick seams in your render which would suggested you did so) then you have to set your values manually in your .sc.

What exact version of LDD do you have? I guess magnets were added in latest update (tho it wa slike 1 year ago)...that is LDD v4.3.8 build 1564.2

Thank you so much - I am glad you like my addition to you beautiful "grabler" vehicle. BTW do you agree on the naming (691601 Grabler Space Rig) or do you suggest some changes to it (lately I changed the word "tractor" for more CS like word "Space" )? And of course if you have any new ideas that could be implemented please tell it here so we can get the best from it! I also added some more modularity to it (actually still finetuning it like TLG would most probably do: that is deleting not needed bricks astuff like that). And that brings me to some more: could you please teest some of it "abilities"? You know, LDD does not allow me testing for real physics so there may be some small flaws like some connections that would not hold the weight attached to it and stuff like that? If you agree I would PM you "building plan" so you could test it with real bricks...hm?

That sounds great - I'll be waiting for your PM.

I guess this is really very nice addition to the PlanetIce2000 subtheme.

I would like to ask you: can I put it in the initial message of this topic (and would do that everytime you update it according to my MOD releases in future) so that MAC users can find it easily everytime there is neew release (actually I would make separate WIN and MAC downloads)? Or even better (if it is applicable): could you please describe me in PM how you are doing that so I can do that myself automatically together with my "normal" WIN release, please? + of course, I put credit to you in that MAC download version. Please, can you show me how does your ground plane code looks (or even better: can you send me your .sc file)?

@SylvainLS, please, my friend - cool down as I do not want to be banned as it slightly starting go bite my nerves therefor I cannot be quiet - tho I wanted to - when you really do not understand what I am talking about saying what you are saying, yet I still I think you are kind person - please, let's be all just fine and somewhat positive... Just to point out some stuff you may not know : - first: it was me who suggested long time ago to @msx80 making this feature (besides many other useful things he already have included in original BR that you thinking are just there "like that" and that they probably were there always - no, many of them were not and some are not still) of separate .sc for every LDD project there is cos it has its logic so it is not me doing/suggesting something that is wrong, it is the opposite way that is BR GUI should rightly first check real value in actual .sc, then putting it inside parameters tab and if user change it writing it back to the specific .sc file - that would be the right behavior, why aren't you able understanding this is beyond me, really... THIS IS REALLY JUST A Parameter tab bug, period (this way values are never saved with respective sc file thus it completely negates one of the reasons for separate .sc to exist), so it is not my MOD that should/could write something somewhere into BR GUI cos it is only @msx80 who holds src to its BR part which is the only one that can actually manipulate with Parameters tab values...easy understandable I guess - secondly: where I am paving what eradication of variables? I think you have it messed up: I am not against variables, I am against SW NOT WORKING RIGHT with quite visible "logical" bugs in it (the fact something works as it does just does not mean it is OK when it is clear from the logical point of view of things that it is a bug in the SW that needs to be solved but only BR GUI author can, that is @msx80, so until he makes it I need to do it like I do by manually entering those values!) - thirdly: and you really still do not get it - once again: let's assume I have 10 different LDD projects - .lxf files - for which I want different values to be saved so when I return to them let's say after a month they'll be there just like I left them when i was working on them (incl. different colors for background, different rendered image resolution etc.), now tell me how your solution (or existing BR's Parameters tab behavior) solving this? I have temporarily solved that by returning to manual input of values, it has absolutely nothing to do with any kind of erradicting of any variables at all "(Oh, by the way, if merely pointing something that works but is not your preferred way is reason enough to bar me from using your work, why is it that the fact your preferred way isn’t the original BR’s one doesn’t bar you from using mx80’s work?)" Well, maybe one of the reasons could be that I actually pushed it much further than it ever was before and never touched his own work at all so what you are asking for is nonsense: all he did in SunFlow was adding some code in SCParser.java so it can parse .lxf file (that is what he told me in e-mail I think long time ago when I join in), his main work was/is BR GUI frontend, you know - remember: SunFlow (BR actual rendering engine) is free/OS JAVA code - in reality when it comes to BR (or better said it actual real rendering egine: SW's heart and brain if you will) the thing is - if you like it or not - it is me who is mostly working on the stuff these days/months, not Nicola (@msx80) as it looks his prime time work is mainly BluePrint yet I never said it is my cos it is not: all credit for existenc eof BR needs to go to him, not me BUT without me you would not have what you have now + I also suggested/pointed out many things to @msx80 that needs to be solved (but he probably have very little time cos there was no update of BR for a year or so)...wheres you only bitching here about things you do not understand quite right yet did not provide anything useful to community so far at all, hm (sorry, but this needed to be said when you slapping "giving hand")? + I never actually ordered you abandon my MODs I just point out that if you are not happy with it arguing with me about stuff you simply do not understand (or I am not able explain in full as english is really not my native language and I am pretty terrible at it, sorry) to use original BR and not spamming this topic with absurd posts where I am trying to explain the problem several times to you but you still comes back with the same stuff - I am a bit tired of it all, really" And also I would like to point out that if it would not be me you all would not have the fine tool you have now with all the stuff: please look back to previous version of BR before I join in and tel me if you see some difference... I hope this is really our last exchange of this kind cos else I would need to ask some admins to take control of this mess, really (it is not I am angry at you or that I cannot stand your point, not at all, I just have no mean or power to constantly explaining stuff you seem to not understand well, sorry - it really becomes some "word war" which I do not like at all). That being said I wish you good night hoping our communication will continue as normal.

It should work with any Color definition in .sc there is, so if you know the name of the material used for your Groundplane then just replace its vvalue with the HEX one.

Oh, if it is like that then there is something wrong here cos it was/is never saved here in my PC into that .ini file, strangely - I have to look at it later what's going on, anyway thanx for pointing this out for me (I would never knew that). Nah Once again you do not understand what I was saying: yes, it might be saved into bluerender.ini, but I am talking about having separate sc file for every LDD project when I need some having different values, so it really is as I said (tho I thought for a while a second before I did not notice something important): those saved values are saved UNIVERSALY AS ONE, NOT SEPARATELY which is the problem, so I was right after all. To specify it even further for you: you have 10 LDD projects and every one has different background and resolution settings: how do you save those for every single one separately? The way you are saying (the way BR normlay operates) saving it just for itself, for BR, not individualy, THEREFORE MY MOD SOLVING THIS BY MANUAL VALUES INSTEAD OF BR VARIABLES which in turn breaks Parameter tabs usage...I really hope we understand now and you are no longer wondering why I want overwrite .sc, BUT I never said anything about generic sccene.sc file: I just provide it right away as template so ppl can use my MOD right away (therefore it is modified tho it is universal sc for projects without separate sc file)

See, @SylvainLS, as to not become some ridiculous kind of "word fight" between you and me I will let you on your own "quest" as it looks we do not probably understand each other, namely: - this topic is about MY MODs, not official BR so, please, take that in your consideration when you are posting here as your advice will simply not work with one of the main modifications/intentions of my MOD "logic" even if you change those variables back to whatever you want (don't you still understand the main point?) = saving our values (incl. background) in .sc after you close it is merit here, not the fact one can turn back variables inside sc so the GUI works again cos whatever variable you set ppl will always have to set their background color and image resolution everytime they open up their previously modified LDD project (in BR)...please, understand this - it has nothing to do with "my kind of thinking", I guess it is more expectable to do I told my MOD do than doing something that this MOD is actually against (that is using Parameters tab for setting values as they are not stored with sc after closing BR) - it is possible combining these two BUT it is not recommanded for problems I already described several times (as you rightly noticed) - if you argue with the way BR works why don't you use its original content only? plase, do not push me using something which is working wrongly (namely parameters saving) cos although you may be right that "that's what people using the GUI expect" won't hold the water as I guess they also expect it to be saved for next time not reset to default values all the time, so I agree if it'd work as it should than yes otherwise not at all BTW from my point of view this debate is over as it looks quite unnecessary and repetitive as everything needed is described in the first post of this topic (incl. info about the stuff that is not working with my MOd like variables) and if not ppl can still ask here as they often do and I always tends to respond all their request almost immediately, so I see no prob here.

Very nice indeed!

Ehm, then how is it that in my LDD magnets work just fine?

No, you could not use HEX colors...UNTIL NOW! Yes, it is: how can be those values saved with respective .sc file for later usage? Nah... Once again: can you tell me how this answers/solves his question for HEX color value(s) as a Color together with my MODs??? No no, my friend - I know you actually mean it well (I feel it ) BUT you are wrong: although setting the color by the BR GUI Parameters tab would show him the HEX value of selected color IT WILL NOT WORK WITH MY MOD as I want those values (all in sc) being saved for later (as one normally expects) which DO NOT WORK WITH ORIGINAL BR (because of wrong principle itself - variable names inside .sc instead of real value(s)? no way...) - so as he is using my MOD it is useless advice for him (unless he edits back that variables instead of real values I set, of course )... And therefor I just released my new MOD that actually introduces real HEX value for Color...hope you will find it any useful. THERE IS NEW VERSION UPDATE (v20160127) at the top of this topic in my first initial message...

Of course: that value of "1 4 1" is nonsensical - allowed values are floats from 0 to 1...what color are you trying to achieve there? I would advise you to look at materials color values in bublible_materials.sc (inside Bluerender/bublible/sc folder) and use those as reference.