Andy

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.

Hi André, this is the easiest solution to the problem. It's this 'event pack' filtering the optional variables. First switch: Initializes the system, sets the 'object' indirect to the 'switch' Traject1 and feeds that one with a functions name. It also feeds 'return', because in each more switch 'return' gets given to the parameter 'par'. More switches: always feeds 'par' with 'return' and switches 'object'. 'object' contains Traject1, and that one's function is 'get section'. The other events are each for one possible variable in Traject1. With the _Trigger-trick all switches may be possible, so we filter it with a 'Typ' defined in 'Traject1' and the function (here 'get section'). Then the approbiate object variable gets picked depending on the content of 'par' and is given to 'return'. regards Andy traject.mbp

somehow that looks pretty familiar just like here too @metallix that's the one I explained to you. That's not possible. The concept is pretty interesting, but forced to wait. I'm just glad that those things happen more and more. Still hope that this will be a fluffy place again. regards Andy

I'd be glad if someone could tell a solution, I'd need it too. Perhaps, if you can describe the whole situation more detailed, we can find another workaround. So far, the only solution is a pack of events looking like this: event: train enters track condition: variable got value: _Trigger2.canton value: section_1 action: _Trigger2.next section = $itinary.section_1; event: train enters track condition: variable got value: _Trigger2.canton value: section_x. action: _Trigger2.next section = $itinary.section_.x; ... Andy btw: you don't need to write $((_Trigger2.data)._Name). , _Trigger2 is enough.

Unfortunately for an indirect access you can just peek the name of an object, but not the name of an object variable. So this leads to nothing:

Wieso muß ich hier Beispiele bringen? Habe ich den Thread angefangen? Das eine Beispiel, dass ich aufgezeigt habe, zeigt, daß aufgrund der Ereignissteuerung herkömmliche Logikgatter hier im Gegensatz zu einer Maschinensteuerung verloren sind. Über Abwärtskompatibilität können Dir streit_ross und opax was erzählen. Ich habe hier die ganze Zeit nichts anderes gemacht, als mitzuteilen, dass ich mich auf V5 freue und kriege seitdem ständig nur in den Arsch getreten. Als Moderator eines professionellen Produktes solltest Du dringend mal eine Standortbestimmung machen. Gruß Andy p.s.: Leute, die wirklich programmiertechnisch ein Problem haben und annehmen, ich könnte es lösen, können gerne versuchen, mich in Zukunft über PN zu erreichen. Wenn ich nicht reagiere, könnte es an der ignore-Liste liegen. Den anderen werde ich meine Anwesenheit ab sofort im Wesentlichen ersparen.

sind keine bunten Buchstaben drin, gell? und alles in einer langweiligen Schriftgröße.

Hä? Wieso verkompliziert sich da was? Weil Du jetzt die + Taste länger suchen mußt? Wenn Du bislang nur was von einer Walnuß gehört hast, juckt dich der Sinus doch gar nicht. Klar, manche sagen dann, "das kenne ich nicht, sowas kauf ich mir aber nicht!" Man braucht auch die Wurzel-Taste nicht, wenn man den Logarithmus und die Gegenfunktion hat. Interessanterweise gibt es mehr Taschenrechner, die die Wurzelfunktion haben, aber den Logarithmus nicht. Und wieso wird die Berechnung ohne Erweiterung des eigenen Wissens unmöglich gemacht? Es ist doch umgekehrt. Du kannst jetzt die Wurzel ziehen, ohne zu wissen, wie das manuell geht. (ich denke, das hast Du auch eigentlich schreiben wollen) Du kannst hier auch was posten, ohne zu wissen, wie das Internet und z.B. http funktioniert. Und Du brauchst nicht mal einen Führerschein dafür. Müßten die Leute heutzutage noch DOS benutzen, hätten sie erheblich mehr Wissen darüber. Gruß Andy

Richtig. Aber 'Anwendungsfreundlich' und 'mächtig' müssen sich nicht ausschliessen. Wenn Du dann wirklich statt 'RandomX' einen anderen Begriff einsetzen kannst, hinter dem sich ein sehr komplexes Skript versteckt, dass ein Programmierer geschrieben hat, aber ein Nichtprogrammierer niemals einsehen muß und das er nie verstehen muß, sondern nur dank einer Beschreibung weiß, was es macht, dann ist doch allen geholfen. Es fragt ja auch kein normaler User, welche DirectX-Befehle Neo verwendet hat, weil das ohne Belang ist. Hauptsache, die Lok kippt nicht um. Begriffe aus der Mathematik/Informatik mit der Sprachwissenschaft zu vergleichen, ist wie das Ding mit Äpfel und Birnen. Du hast für Negation drei verschiedene Möglichkeiten angegeben. Setze sowas mal in einer Programmsprache ein. Ja - es könnte jetzt dies oder das oder jenes passieren. Absurd. Mir färbt sich schon das Gesicht, wenn man 'numerieren' jetzt mit Doppel-M schreibt. Weil es von 'Nummer' kommt? Nein - es stammt von numero ab. Und in der Informatik ist z.B. Enumeration ein verwandter Begriff. Prinzipiell ist also die Schreibweise des Wortes 'gebunden'. Aber soweit reicht's bei den Dusseln, die für die Änderungen ermächtigt wurden ja nicht. Und wenn man dann fachlich was kritisiert, wird gejammert. Manchmal muß man mal auf den Tisch hauen, damit kein Schaden entsteht. Gruß Andy p.s.: Ach so, die Ampel - wie sieht denn nun die exakte Umsetzung dieser Diagramme in die MBS-EV aus?

Trabbi und Modellbau

Das kommt jetzt schon das zweite Mal und damit reicht es auch.

Wenn Du das postest, wird's streit_ross gerne lernen. p.s.: wenn ich mich wirklich was frage, dann wo z.B. Anfang der 70er Jahre die ganzen Gebührenzähler für die einzelnen Telefone der einzelnen Haushalte gestanden haben...

Ich vertraue total darauf, dass ihr alle noch neugierig genug seid für V5. Und ihr werdet auch alle umsteigen. Sicherlich wird's im Alter anstrengend zu lernen. So wie Benjamin heute in Sketchup eingestiegen ist, so schnell wird's nicht mehr gehen, bei mir auch nicht. Das machen die Augen schon mal nicht mehr mit. Aber da zieht einer den anderen über dieses Forum mit. Quängelt nicht rum, das wird gut, solange wir hier die positive Stimmung erhalten. Gruß Andy

Ich nehme an (und da befinde ich mich total im Bereich der Spekulation) dass die EV vom Prinzip her komplett erhalten bleibt. Lua-Funktionsaufrufe werden so laufen, wie heutzutage RandomX gerufen wird. Da steht dann halt was anderes und die EV guckt nach, ob es für das Kommando ein Skript gibt, oder ob's ein Tippfehler ist. Das war's. Mehr als abwarten geht sowieso nicht. Und Du Reinhold, kannst mir mal erklären, wie Du eine komplexe EV mit und-oder-nicht erstellen willst. Ist mir absolut unerklärlich, wie Du als Lehrer ein lebenslanges Lernen verneinen kannst. Ein echter Virus - der kann sich nach der Aussage eines alten Freundes so bilden, wie wenn man ein Haufen Metall in die Ecke wirft und plötzlich steht ein VW da. Und es soll auch Affen geben, die bei genügend Zeit das Gleiche wie Shakespear auf einer Schreibmaschine eintippen. Aber eine komplexe MBS-Anlage entsteht so definitiv nicht. Grummeln hilft da gar nix und bringt nur schlechte Atmosphäre.

Genau so ist es. Nur konnte ich mir den massiven Ausfall der betritt/verläßt-Meldungen nicht erklären, was aber eben den Grund hat, dass ein geschobenes Fahrzeug (also eins mit Geschwindgkeit 0) da gar nichts auslöst. Das ist natürlich absolut logisch - aber man wird so abgelenkt, dass man da nicht drauf kommt. Was man nach dieser Erkenntnis allerdings auch wieder zur Fehlerkontrolle nutzen kann, denn wenn ein Zero-Speed-Fahrzeug plötzlich auf einem anderen Gleis STEHT, dann ist's passiert. p.s.: Ich bin da auch weit davon entfernt irgendetwas zu kritisieren. Im Gegenteil, höchsten Respekt für Neo, dass er es geschafft hat, diese ganzen Problematiken unter Kontrolle zu bringen. Ich erwarte nicht mal, dass er jene geplante Optimierung wirklich umsetzen kann. Es gibt schlicht und einfach Grenzen des Möglichen.

Vielleicht schreibt ihr der @pfjoh mal eine PN zu dem Thema.