Andy

Hallo, ich habe erst gedacht, ich hätte in meiner Arbeitsversion einen Fehler gemacht, aber dann habe ich festgestellt, dass diese Lücken auch in meiner Demo-Version im Katalog entstanden sind, was natürlich deren gesamte Abfolge infrage stellt. Offensichtlich ist die Straßenbrücke ohne weiteren Kommentar aus dem Katalog entfernt worden. Definitiv nicht witzig! Ich habe die Anlage deshalb zurückgezogen.

Hallo, je später die Nacht, desto verrückter die Ideen. Momentan hätte ich das Problem, dass ein Eckhaus nicht zu der Ecke paßt, wo es hinkommen könnte, weil es da nur gespiegelt hinpassen würde. Wäre es kompliziert, im Modelleditor etwas einzurichten, dass man sich das Modell selektieren könnte, dann im Modelleditor um die eine oder andere Achse spiegeln und danach unter den eigenen Modellen ablegen könnte, sodaß bei Verwendung für die anderen bei Ansicht kein Fragezeichen auftauchen würde? (mit den letzten Vorschlägen will ich V5 gewiß nicht hinauszögern...). Gruß Andy

Hallo Neo, beim Tag/Nacht-Wechsel ist die Nacht doch ziemlich lang, da kann man so viel nicht zeigen. Läßt sich das Tageslicht morgens und abends noch ein wenig verlängern? Und 'Scheinwerfer aktivieren' ist für die Nacht gut, tagsüber sieht's aber saublod aus. Ist da eine automatische Abschaltung möglich? Per Programm kommt man ja nicht ran. Gruß Andy

Hallo Neo, wäre es noch möglich, bei den Samples einen Faktor unterzubringen, der die Abspielfrequenz modifiziert? (beim Objekt!). So könnte man sich unterschiedliche Plings für Signalgeräusche erstellen, oder auch leichte Unterschiede in Lokgeräuschen etc. Gruß Andy

Great henricjen! Looks like a V100 in a plate armor, don't add rockets regards Andy

Hallo @Robbinwood, die maximale Belastung erreichst Du (glaube ich), wenn Du in der 2D-Ansicht alles ins Bild nimmst (siehe Beispiel). Da fällt bei mir die FPS schon auf 7.0 runter. Obwohl man normalerweise andere weniger belastende Ansichten wählt, hat man so einen ganz guten Referenzwert. Da nun alles im Bild ist, kannst Du nun mal auf FPS doppelklicken und dann auf Polygone (sortiert!), wodurch Du siehst, was denn nun die belastenden Elemente sind. Aber ich denke, Du kannst die Anlage so lassen. Sowie man normale Ansichten wählt, 'normalisiert' sich die FPS schnell. Schöne Anlage! Gruß Andy

Sehr gut Frank! Durch den großen Außenradius des Dummygleises fängst Du Ungenauigkeiten ausreichend ab, prima Idee!!! Und bleibt genau, ohne dass sich etwas aufaddiert. Außerdem ein sehr schönes Beispiel für die Anwendung des Trigger-Tricks! Gefällt mir sehr gut!!! Nur wenn eine solche Drehscheibe voll genutzt wird, befürchte ich trotzdem Performance-Probleme. Wenn Brummi die entsprechenden Lokschuppen fertig hat, empfehle ich Loks, die im Schuppen bei geschlossener Tür sind, auf unsichtbar zu schalten, da Loks ja doch etliche Polygone mitbringen. Gruß Andy

Hallo @Henry, ich habe mich bewußt sehr zurückgehalten in der letzten Zeit, aber ich muß hier doch einmal Bedenken einbringen. Ich glaube nicht, dass hier eine Gesamtansteuerung möglich ist und zwar aus dem einfachen Grund, dass Unsichtbarkeit nicht das Problem übereinander liegender befahrbarer Objekte löst, bei denen keiner mehr weiß, wie das Fahrzeug reagiert. Würden wir also demzufolge nur eine einzige Drehscheibe nehmen und das gesamte Modell um eine halbe Stufe weiter drehen, würde uns die Ungenauigkeit wieder ein Schnippchen schlagen (alte Beispiele: Rolltreppen/Aufzugsproblem). Ich lasse mich gerne vom Gegenteil überzeugen, aber ich denke, auch für dieses Thema hier ist Warten angesagt. Gruß Andy

Nicht lästern FF, sonst bringe ich jemanden dazu ChinaTown zu bauen und bei Dir etliches zu wünschen @kdlamann Hast Du für das Holz und die Dachschindeln als Texturen echte Bestandteile des Photos genommen, denn die sind ja sowas von passend! Das sieht ja wirklich bald 1:1 aus. Grüße Andy

Hallo Toni, naja, im Prinzip könnte man ihn ja auch an einen Traktor hängen. Sowie er mit einer Straße in Kontakt kommt, wäre die Fahrzeugeigenschaft für das Ereignis 'verläßt Straße/Gleis' schon wichtig, sonst gibt's Auffahrunfälle. Gruß Andy

funny, MBS is just short for ModellBahnStudio, that's the german title of that what you call Standard-3D

FeuerFighter hat mir ja mit den Westerngebäuden und der Kaserne mal eine Pause gegönnt, aber jetzt stehe ich wieder vor dem Problem. Wo stelle ich das noch hin? Gruß ANdy

Geht mir doch auch so. Ich hätte MBS schon vor Einbau des 'Kippschalters' auf englisch umstellen sollen, dann hätte der auch anders geheißen. Ich hab's dann vor Abspeichern der EV gemacht, um mal zu sehen, was dabei herauskommt und das ist doch okay. Der Exporter ist zumindest nicht hängengeblieben. Vielleicht können wir André ja dazu bekommen, an einer französischen MBS-Version mitzuhelfen. In der Liste der verfügbaren Sprachen ist gewiß noch ein wenig Platz. Aber dann muß der Exporter nochmal kräftig auf Unicode-Zeichen abgeklopft werden. Ich bin Dir jedenfalls unendlich dankbar für die Strukturklammern! beste Grüße Andy

Hi André, naturally, some more things came up over time. There are lots of thoughts about smooth event sharing. Lately this thread was of interest regarding how much events can be handled safe with no negative effects for the graphic. One result of the thread was: better don't switch too much lights at the same moment, use very small delays. Another thing is about splitting tracks/streets in lots of small pieces to handle curves in rising zones. If you make too short pieces, enter track events could be lost if the vehicle is too fast. And it really costs performance if you got too much objects of a certain type when you use the trigger-trick. Neo knows about that and we're in good hope, that there will be options in the new version that will solve the one or other critical situation. So about collecting this special stuff: there are plans that we will also have a user-wiki with the new version. Let's wait for that. So far (at least in the forum) only very few people come to those critical situations at all. Writing about without being asked causes heavy flaming from the i-dont-like-variables-fraction... The most innovative EV-using layouts are probably those of BahnLand and fzonk, but perhaps the most creative ones are those of koriander - who is still programming 'old-style': If you're in trouble with the EV again, BahnLand, fzonk and me (at least) will help for sure. regards Andy

Hi André, be assured, that's all a question of practising! But first - you have to have another design! Your flowchart can't be reflected the way you did - i.e. var1 gets set two times, so any request if var1 > 5 gets in fact passed two times. see it? Event handling is, as if a lot of users access the same site. Lots of things happen simultaneously. Whatever goes linear now, has somehow to be capsuled. In a machine you use 'step chains' for that, and so is my sample. It is like you number the different elements of your flowchart and then program the path through it. Please be aware, that I use the alternate action too. (if condition is not fullfilled - you can select that in the action part of an event!) There would even be a little more effort needed to make the sample safe, right now very fast switching would always set step=1 again, interrupting the chain and restarting. Do you get the idea? regards Andy logic2b.mbp Result of BahnLand's XML-Processor: Projekt: Logic2b Gruppe: Ereignisse { Ereignis: bascule Auslöser: Switch gets toggled Switch='Kippschalter' Position='Any position' Aktion: Set variable Name='VAR1' Value='1' Aktion: Set variable Name='step' Value='1' Ereignis: step1 Auslöser: Variable is changed Name='step' Value='1' Bedingung: Variable has the value Name='VAR1' Value='1' Negate='0' Aktion: Set variable Name='step' Value='+1' Sonst: (Bedingung nicht erfüllt) Aktion: Set caption Caption='Label A1' Text='???' Ereignis: step2 Auslöser: Variable is changed Name='step' Value='2' Aktion: Set variable Name='VAR1' Value='+5' Aktion: Set variable Name='step' Value='+1' Ereignis: step3 Auslöser: Variable is changed Name='step' Value='3' Bedingung: Variable has the value Name='VAR1' Value='>5' Negate='0' Aktion: Set caption Caption='Label A1' Text='YES' Sonst: (Bedingung nicht erfüllt) Aktion: Set caption Caption='Label A1' Text='NO' } Variable: step '0' Variable: VAR1 '0' *** Ende *** @BahnLand: schönes halb und halb deutsch/englisch aber man sieht, was gemeint ist.

Another interesting thing is the is, that there is still a difference between the 'cycles' and the 'ticks' that you get from the event-com-port. Here's the log: TICK: 0.000 <- Tick is the time in secs where you get a 'receive' 210;Kippschalter;0; <-- the switch, first number is the event code, 210 is switch switching 60;VAR1;1; <- code 60 stands for Variable set TICK: 0.016 60;VAR1;6; 60;A;1; TICK: 0.031 60;A;2; 60;A;3; <- very very interesting that you get this in the same tick as the last one! Didn't expect that. But this maybe just depends on how much time is left in the tick frame, because it's even possible that things come a tick later that belong together. But it is also possible, that this cycle was continued immediately because the EV caused an internal event (setting of variable), which doesn't come from the layout. However, the sequence itself isn't disturbed by that. (btw - When a text gets set, there is no event notification. Some things are missing, like setting a speed or a noise too.) regards Andy

Here's one more and hopefully this time you get it: I added a second variable A, which gets incremented in both events check2/3 and the value is shown on the right side in Label1/2. Now, again, see what happens, READ LINE FOR LINE SLOWLY! The switch sets V = 1 (there's a special appendix in the end about it, just assume now, the event VAR gets set happened!) now the 1st pass, calculating the logic: reset check: variable gets set and is 1 -> TRUE check2 variable gets set, but is not >5 -> FALSE check3 variable gets set, and is 1 -> TRUE NOW THE 2nd pass performing the actions: reset check is true, ACTION: var gets +5 and is 6 now! my new one: A get +1, is 1 now, shown here check2 is false - NO ACTION!!! check3 is true - ACTION, Label4 gets the text NO, Label6 gets the value of var, which is in fact 6 now. my new one: A gets +2, is 2 now, shown here FOR THAT CYCLE WE ARE THROUGH NOW! So far - so good. And why do get Label3 and 5 texts now at all? I marked one thing bold. This one sets variable A again now, so in the next EV cycle this has an effect too. Again the first pass: reset check, variable got set, but is not 1 anymore -> FALSE check2: variable got set and is now >5 -> TRUE check3: variable got set but is not 1 -> FALSE and again pass2 for the actions: reset check: false, nothing happens check2 is true: ACTION! Label3 gets text YES, and Label5 shows the value of A, my new one: A gets +1, is 3 now and that is shown here check3 is false: no action! because var didn't get set anymore now, nothing happens anymore. system is stable. The problem with your flowchart is: it is not splitted in two passes. The theme here is EV vs. 'normal' program linearity. And there's simply a difference. I had to learn that too! Don't ask me for reasons, I didn't made that - but why the heck is it so hard to understand those two passes? It's more that a 'normal' programmer is not really willing to accept that. But believe me - once you jump over the fence, you can live with that. So - after you did understand it now, you surely will understand too, that in fact one more EV-cycle is needed: for the beginning switch! it sets VAR to 1. But in that cycle all other events will be given a FALSE in the first pass, because on 'incoming' var wasn't changed, so no action will be launched. So my explanations happen truly in the next cylce, when the setting of var is on the event-list. Last thing to know is: Event and total logic result of its conditions are combined in the first pass! regards Andy logic2a.mbp

Ah yes, I already modified the crossing, reducing it to 2 states, activating 2 routes for each state That way it fits to the system.

Link , please translate BahnLand's final explanation. Did you try your own sample? In position 0 the crossing switch is 3 after switching, in position 1 it is 0 in position 2 it's the value it should have, no switching in position 3 is comes out 2. So it doesn't stop at the desired position, it switches 3 times. Three identical events, three times identical behaviour - it's like Brexit voting. What should I say more?

Hi André, about 1.) it's here really not easy to find the balance between efficiency and complexity. having some kind of a programmed 'engine' means after all that you waste time by calculating unused stuff. optimize it, and you will miss the one or other thing sooner or later, because usually such a MBS-layout is in work forever. try to make changes in optimized code, and you'll get crazy. murphy says you will be on the wrong side anyways... about 2.) those things are already explained, unfortunately not in the Wiki and just in german. To the user, things happen in one sequence, that's true, but at runtime, there's some kind of a splitting and that's why the behaviour is something different. Look at this, imagine the event happens, we just take a look at the conditions: 1.event: if (variable < 0) variable = 0; 2.event: if (variable=0) haveaction; with a variable less 0, you expect that the first action sets variable = 0, so that the condition in the 2nd event is fulfilled, you 'haveaction'. But MBS works another way! It first checks all conditions and you get with variable < 0: 1. true 2. false what happens now in this cycle is: the first line will set variable = 0; because it's 'true', but the second one isn't executed in this cycle anymore it's 'false'! You don't get 'haveaction'! Test it! That's why I say, with your three identical statements, the crossing switches three times at once, or not at all. Neither one time, nor two times! about 3.) first thing is, 0/1 and 2/3 are similar, not 0/2 and 1/3, my (first) fault: (I really have to checkout my layout for this!!! I smell an unspotted bug!) second thing is: you are right with the activated route. i never really spotted that using automatic switch correction on my trains regards Andy

Hallo Neo, könnte es nicht Sinn machen, Objekte auch mit der freien Kamera zu verknüpfen, sodaß man z.B. Schaltobjekte immer zur Verfügung hat? Gruß Andy

Hi Andrè, took a little time for the reply, but I'm still very busy analyzing the logfiles of my own layout (and creating helping programs for that) - and that's a lot. As you know, my concept follows a similar idea about premade trajects, still there are differences. I like your idea to attach special actions to a traject, this probably will later help to stop and wait for un/loading stuff, getting coal/water/fuel or processing the doors of an engine shed after using a turning platform. This is still hardcoded in my layout. It's an important thing for a flexible layout. There are more things one should think about, especially about timing. If you got a whole plan with more trajects for a train, what would you prefer? a) using a fix time to leave a station, b) wait for an amount of minutes, c) wait for another event, d) leave immediately after performing another attached manoeuvre. Remember, there's also the need to preserve paths and make decision what to do, if there's a reserved block on the way. So you got some similar options in that case. What we can do now, is to think about those things, collecting them. But makes no sense to implement that now. Those are the things that will change in the new version. Also, there's the good question if that should be an open discussion to create a highly flexible universal system that can be used by the most layouts and everyone who isn't a master of programming. I've always been roughly blocked writing about this, so gave it up before new things are available. So - we could plan a flexible data-system, but cannot be sure if that can be realized. The other thing is your 'crossing status'-problem. The 'switch-status' is no problem, that one is correct. But - for the 'crossing status' you use three event in a row to check about the status and if needed switch again. That one will not work the way you intended to have it! In the beginning of an ev-cycle, there's an important thing you have to know: all events are checked if they happen and if their conditions are fulfilled in kind of a locked state for events and variables and whatever needed. This also includes kind of multiplying events if you are using the 'trigger'-trick. Having that done the actions will happen for all things that got a 'true' now. That means: either the three crossing-state events will happen not at all, or all three at once, but never just one or two times. If you now make tables what can happen, you'll see the problem. In addition, I don't know if it is safe to assume that state '2' always switches the same path as state '0' and '3' always equals exactly '1'. regards Andy

Hi André, will take a little bit until I understand it. In the meantime: Do I need this missung custom texture? I guess it is some explanation text: switches & variables: I also came around that problem. not funny. regards Andy

Doch Reinhard, schau: @Neo,(laaangsam tippen). Gruß Andy

@henricjen tried it too, same effect of course, so I tried 'Install Addon'. It then said, that files comes twice, so I deleted the original io_scene_x-folder. Then installing from the Wiki's zip file worked - but it says, does it needs an upgrade to 2.8, so will not appear in the import/export list. That's @Neo's turn then. --- hab's auch versucht, natürlich mit dem gleichen Effekt. Deshalb habe ich 'Install Addon' versucht, worauf er doppelte Files angemeckert hat. Daraufhin habe ich den Blender-Ordner io_scene_x gelöscht und das Wiki-zip mit Install Addon eingebunden. Das funktionierte dann zwar, aber nun wird angemeckert, dass ein Upgrade für das Tool erforderlich ist, .x taucht also nicht in den Export/Import-Optionen auf. Chefsache. Gruß Andy p.s.: here's a link to a blog how to upgrade add-ons. Reading this, I doubt Neo can make that without an upgrade of the original .x-Exporter.