[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DDL-ML] Antw: Re: dtcl-tiny
Hi Markus, (für alle ach an die DDL-Mailing-Liste)
danke für Deine prompte Antwort, eine einfacher zu handhabende Version wäre toll !
Es ist schade, daß man unter Linux immer gleich selbst Programmierer sein muß um das nötige Systemwissen zu haben, nur um ein Programm zu installieren.
Aber auch Linux wird ja langsam immer userfreundlicher.
Meine Erfahrungen der letzten Wochen, zeigen, das es ein echtes Problem ist, wenn ein Programm 1. nicht bei der Distribution z.B. SuSE dabei ist und bequem mit z.B. Yast installiert werden kann und 2. div. Compiler, Libaries oder dergleichen die teilweise tief im System verankert sind, ebenfalls aktuallisiert werden müssen.
Oder ist es einfach ein Programmierer Problem, das immer direkt neueste Versionen o.g. Teile verwendet werden ?
Ich habe schon öfter den Tip bekommen die besseren Dekoder zu nehmen.
Es müssen aber alte (analoge) Fahrzeuge in größerer Zahl umgerüstet werden:
Problem bei einem "armen" Verein (und auch privat) ist halt, daß man die hohen Mehrkosten für einen besseren Dekoder mit der Anzahl der Fahrzeuge multiplizieren muß :-(
Wenn die Software (der Client) die (teurere ggf. unnötige) Hardware ersetzen könnte, wäre es doch toll und im Sinne von DDL.
Wir haben div. verschiedene Dekoder bei unseren Mitgliedern im Einsatz und müssen jetzt einige neue anschaffen, sind mit DLL aber noch im Anfangsstadium.
Unter diesen Gesichtspunkten wäre eine derartige Funktion, soweit sie realistisch implementiert ist, doch ein enormer Vorteil von DDL.
Verständlich das Deine Diplomarbeit im Vordergrund steht, deshalb nochmal extra Danke für Deine Mühe.
>>> Markus Pfeiffer <mail@markus-pfeiffer.de> 27.12.2000 14.31 Uhr >>>
Hallo Frank,
die angesprochenen Verzoegerungen setzen keinen bestimmten Dekoder vorraus.
Es werden einfach stufenweise Pakete im definierten zeitlichen Abstand
geschickt, anstatt sofort die neue Geschwindigkeit zu setzen.
Allerdings funktioniert das ganze momentan nur, wenn du nicht direkt
am Schieberegler verstellst, sondern den gruenen, gelben oder roten
Knopf (siehe Bild 1) zum Einstellen der defierten Minimum-, Average-
oder Maximum-Tempo anklickst. Man sieht dann auch, wie der Schieber
langsam von Stufe zu Stufe laeuft.
Ich bin noch am ueberlegen, ob ich dieses Verhalten auch bei direktem
Verstellen am Regler einbaue, aber dann habe ich eine zeitweise
Inkonsistenz zwischen dem Wert am Regler und dem Wert, der als
Kommando ausgegeben wird, was mir nicht besonders behagt.
Wegen der Qt-Versionsprobleme werd ich mich mal um eine statisch
gelinkte Version kuemmern, aber vorher muss ich kurz meine Diplomarbeit
fertigschreiben ;-)
Noch was, wenn du mich fragst: Kauft euch mal einen geregelten und
einen ungeregelten Dekoder und probiert beide mal aus. Wetten,
dass ihr keine ungeregelten mehr wollt...
Gruss,
Markus Pfeiffer
On Wed, Dec 27, 2000 at 11:34:46AM +0100, Frank Stimmer wrote:
> Hallo Markus,
>
> abgesehen davon, das ich Deinen Client wegen veralteter QT Lib und SuSE 6.3
> immer noch nicht zum laufen bekommen habe, mal eine Grundsatzfrage vorab:
>
> In dem Bild Lok-Konfigurationsdialog, Tab 3 gibt es die Einstellmöglichkeiten
> "Dynamic Acceleration & Breaking".
> Sind das Funktionen die einen bestimmten Dekoder voraussetzen (z.B. den
> Märklin 6090) und auf dessen Anfahr- und Bremsverzögerungsfunktionen
> zurückgreifen oder werden diese Fahreigenschaften über den Software
> Client auf allen (auch einfachen billigen) Dekodern simuliert ?
>
> Dies ist für uns eine entscheidende Frage, da wir etliche Fahrzeuge
> noch auf digital umrüsten wollen und so mit preiswerten Uhlenbrock Dekodern
> auskämen.
>
> Frank Stimmer
> Eisenbahnfreunde Gladbeck 87 e.V.
>