Beiträge von Sven777b

das Bewegen der Kollisionen und Cylinder übernimmt nicht toggleAnimatedParts sondern Cylindered. Die neue Version bietet lediglich eine Schnittstelle zu Cylindered indem man angeben kann isMovingTool="true"

Eine Kollision kannst du sowieso nur dann bewegen, wenn es sich dabei um eine eigene Komponente handelt. Du müsstest also erstmal die Kollisionen auslagern und mehrere components erstellen. Am besten du schaust dir das bei einem klappbaren LS11 Standard Grubber an - zB der von Vogel&Noot. Dort siehst du auch wie das mit den movingTools funktioniert, da es bei diesem Grubber ebenfalls angewendet wird (die originale Spezi animatedVehicle macht nämlich das selbe)

modelleicher: ich hoffe du verstehst das ganze nicht als wilde Kritik an deinen Videos. Ich respektiere natürlich die Arbeit die du dir gemacht hast und finde das auch ganz toll. Meine Kommentare sind eher als Tipps oder Anregungen zu verstehen was man evtl. anders machen/sagen könnte.

Bzgl. der Räder.. spätestens beim 3. video wo die Räder von vornherein skaliert waren, hätte ein Fehler beim Laden des Traktors kommen müssen. Ausserdem werden die Räder nicht nur beim Laden berücksichtigt sondern sie werden permanent aktualisiert. Skalierte Räder haben ein unvorhersehbares physikalisches Verhalten - das kann zu seltsamen Effekten führen die man später möglicherweise nicht mehr ihrer eigentlichen Ursache zuordnen kann.

Genau wie die performance Geschichte ist es sinnvoll manche Dinge von Anfang an zu berücksichtigen auch wenn man es erstmal einfach halten möchte - so vermeidet man möglicherweise zukünftige Fehler. In der Fahrschule bekommst du beigebracht was du an deinem Fahrzeug alles zu warten und zu prüfen hast - noch bevor du überhaupt ein eigenes Auto hast , geschweige denn fahren kannst. Aber manche Dinge sollte man den Leuten nunmal von Anfang an beibringen - denn auch Kleinigkeiten wie ein läppischer Liter Bremsflüssigkeit können bei 200kmh den Unterschied zwischen Leben und Tot ausmachen. Unterschätze niemals den Konsequenzen einer einzelnen Handlung.

Bezüglich der Performance hatte ich deswegen auch extra erwähnt dass dies vor allem bei MP Anbindung wichtig wird. Glaube mir - ich habe für LS11 schon mehr als genug (weit über 20 Spezis ) gesehen , die via Update() Routine Syncronisierungen 30x pro Sekunde auslösen. Da reicht ein solcher Mod um den MP lahm zu legen und dann wundern sich die Leute warum sie die Hälfte der Maschinen nach dem Sync nicht sehen können oder warum ihre Log voll ist mit "Packet not received"

Wie gesagt - nur Ansatzpunkte und Hinweise. Ich möchte wirklich nicht kritisieren - ich weiss wie aufwändig es ist so ein Tutorial zu entwerfen - erst recht als Videotut.

zum zweiten Video kann man wenig sagen , da es im Grunde die Informationen des ersten Videos wiederholt.
Der Verweis auf gdn ist sehr wichtig - es wäre evtl. sinnvoll auf die Strukturen einer solchen (typischen) Befehlsreferenz hinzuweisen.

Sehr amüsant der Ausflug in die Grundlagen der Mathematik Brüche haben automatisch immer vorrang - abgesehen davon hat bazillus natürlich recht - x*0.7 wäre die einfachste und gemeinhin üblichste Lösung. Entspricht der Formel W = G * P / 100.

- zum Thema "Float" ... "Fliesskomma-Wert" war das Wort das du gesucht hast - und Prozent heisst in englisch percent.
- die Wahl zwischen Float und Int trifft man primär aus Gründen der Präzision. Bei Integer Werten wäre (10/2) == 5 immer true. Bei Float ist (10.0/2.0) == 5.0 nicht unweigerlich gegeben. Die Fliesskomma-Präzision ist begrenzt und hinter dem Komma gibts noch viele Stellen... Wers nicht glaubt kann im LUAEdit oder auch in einem LS Script mal die Funktion eingeben:

local x = 0.0;
for y=1,1000 do
  x = x + 0.3;
end;
print(x);

Spoiler: das Resultat ist nicht 300

- ich finde es gut das du von vornherein mit englischen Variablen begonnen hast - das sollte man generell beibehalten. Dies macht man nicht nur wegen der Internationalisierung - also das auch andere Scripter damit klarkommen , sondern es hat auch den Vorteil das die englische Sprache keine Sonderzeichen wie äöü oder á und dergleichen besitzt - diese Zeichen sind in Variablennamen verboten. Wenn man gleich englische Bezeichner verwendet, umgeht man diese Problematik vollständig.

- mich wundert das dir nicht aufgefallen ist das dein Traktor einen Fehler in die log hätte werfen müssen - wegen der skalierten Räder.

- ich würde in einem zukünftigen Tut auf die Verwendung von Utils.getNoNil hinweisen. Insbesondere wenn die aus der XML ausgelesenen Werte für mathematische Operationen verwendet werden.
Utils.getNoNil(value, default);
Wenn der Wert value == nil ist - was zB passiert wenn man ihn in der XML nicht angegeben hat, dann wird er durch den Wert default ersetzt. So vermeidet man einen Crash des Scriptes.

hab zufällig gerade das Video entdeckt. Nur mal ein paar Anmerkungen zur Ergänzung - kann sein das einiges inzwischen schon geklärt ist oder später auftaucht. Ich schaue gerade die Videos an und notiere mal chronologisch was mir auffällt...

- update(dt) wird auf einem Durchschnittlichen PC 20-30x pro Sekunde ausgeführt. Abhängig von der Rechenleistung und der Anzahl der Mods.
- updateTick(dt) wird nur ca. 2-3x pro Sekunde ausgeführt abhängig von der Multiplayer-Verbindungsgeschwindigkeit. Im SinglePlayer läuft updateTick fast genauso schnell wie update.
- draw(dt) wird 50 bis 60x pro Sekunde ausgeführt - abhängig von den aktuellen FPS (draw wird 1x pro Frame ausgelöst) Die Laufzeit der Draw Routinen beeinflusst damit auch maßgeblich die maximalen FPS - da sollte wirklich nur rein was nötig ist (Bildschirmausgaben)

- die Sache mit dem elseif wurde von bassaddict bereits angesprochen. Ich würde hier ebenfalls auf else setzten - zum Einen um Fehler zu minimieren - denn eine elseif-Variante hat einen unbekannten Ausgang (wenn weder die erste noch die zweite Bedingung zB aufgrund eines Schreibfehlers erfüllt würde) und kostet unnötige Performance da ein zweiter Vergleich notwendig wird.

- die Lösung im update() Bereich ist ineffizient und sollte von Anfang an vermieden werden - in diesem Beispiel ist der Performanceverlust minimal , bei größeren Spezis oder gar MP-Anbindungen kann soetwas böse Folgen haben.

Erklärung: du prüfst erst auf Tastendruck und setzt entsprechend die Variable self.wheelScaleState. Anschliessend skalierst du basierend auf eben der genannten Variable deine Räder. Bei einem oneRun Script kein Problem. Aber hier wird die update() Routine mehrfach pro Sekunde durchlaufen und du skalierst damit unnötigerweise mehrfach pro Sekunde die Räder - auch wenn es der selbe Wert ist, wird das Rad doch skaliert. Sinnvoller wäre es hier den Skalierungsvorgang direkt in die if-Abfrage des Tastendrucks zu integrieren um sicher zu stellen, dass das Rad nur skaliert wird wenn es notwendig ist.

if InputBinding.hasEvent(InputBinding.TASTE_TUTORIALWHEELSCALE) then 
  self.wheelScaleState = not self.wheelScaleState; 
  if self.wheelScaleState == true then 
    setScale(self.wheelToScaleLeft, 0.7,1,1); 
    setScale(self.wheelToScaleRight, 0.7,1,1); 
  else 
    setScale(self.wheelToScaleLeft, 1,1,1); 
    setScale(self.wheelToScaleRight, 1,1,1); 
  end;
end;

- Wichtig wäre darauf hinzuweisen dass das was du im Video als Beispiel getan hast prinzipiell falsch ist. Denn die repr-Node eines Rades darf nicht skaliert werden - weder im GE noch im späteren Spielverlauf. Wenn du die Räder im Spielverlauf skalieren möchtest, solltest du die driveNode dafür verwenden. Also eine tiefer liegende Node - ansonsten gibt es probleme mit der Physik.

- Ergänzend würde ich - um Redundanzen zu vermeiden - einfach auf die direkten Variablen der Wheels - also self.wheels[2].driveNode und self.wheels[3].driveNode zurück greifen anstatt eine eigene Variable dafür zu verschwenden. Allerdings ist mir durchaus bewusst dass dies nur zu Beispiel-Zwecken diente.

die KollisionMasks sind Bitmasken - sie werden vom Spiel mit AND verknüpft um zu entscheiden ob eine Kollision stattfindet oder nicht.
Das heisst:
Bei Objekt A sind in der Kollisionsmaske 1 und 23 angehakt
Bei Objekt B sind in der Kollisionsmaske 1 und 24 angehakt
Bei Objekt C ist nur die 23 angehakt.

Objekt A kollidiert mit Objekt B wegen der 1
Objekt A kollidiert mit Objekt C wegen der 23
Objekt B kollidiert aber nicht mit Objekt C

ich hoffe das ist verständlicher.
die 1 ist das Terrain , 13 ist der Spieler , 21 bis 24 sind Traktor,Drescher,Hänger,Arbeitsgerät (die genaue zuordnung müsste ich nachsehen - hab aber grad kein LS zur Hand)
und weiter hinten gibt es noch ein paar. Man kann sich einfach die Masken der Standardfahrzeuge ansehen und unter berücksichtigung der oben genannten Punkte seine Schlüsse ziehen.

CPU´s in der sog. "Boxed" Variante haben einen eigenen Lüfter dabei, der im Allgemeinen vollkommen ausreichend ist solange man nicht unbedingt an den Taktraten rumspielt.

Das Netzteil sollte man auch nicht vernachlässigen. Rechne damit das Board und CPU unter Last locker 170 bis 240 W ziehen. Dann die Grafikkarte mit 150W unter Last sowie Festplatte und DVD. Du hast also eine Last von 400W (ohne USB Geräte) - das Netzteil sollte diese Grundlast gut weckstecken können. Wobei die 550W Empfehlung von Nismo20V optimal gewählt ist.

Berücksichtige auch , dass (sofern du keines hast) ein geeignetes Gehäuse zu beschaffen wäre, was schnell mal mit 100€ zu buche schlägt.

Desweiteren solltest du bei dieser Variante einige Kenntnisse und handwerkliches Geschick mitbringen oder jemanden an der Hand haben der sich mit sowas auskennt. Denn ein PC ist kein Lego-Technik... da kann man als Laie ne Menge falsch machen was sich teils erst Monate später zeigt (erinner mich dunkel an den einen oder anderen Kumpel der über die mangelhafte Haltbarkeit moderner Elektronik geschimpft hat - um später erklärt zu bekommen das er zuviel Wärmeleitpaste aufgetragen hat und 2 Kabel verkehrt herum steckten und der Arbeitsspeicher dank cleverer Kabelverlegung in einer Wärmeblase brutzelte.. ) aber ja ich weiss schon - hat ja jeder voll den Plan und schraubt schon seit 30 Jahren Rechner zusammen

<movingTool index="42" attacherJointIndices="2" componentJointIndex="0" anchorActor="0" rotSpeed="20" rotAcceleration="80" rotMax="5" rotMin="-80" axis="AXIS_FRONTLOADER_ARM" invertAxis="true" mouseAxis="AXIS_FRONTLOADER_ARM" invertMouseAxis="true" speedFactor="0.3">
   <dependentPart index="0>42|1" />
   </movingTool>
   <movingTool index="42|0|1" attacherJointIndices="2" anchorActor="0" rotSpeed="100" rotAcceleration="300" rotMax="145" rotMin="5" axis="AXIS_FRONTLOADER_TOOL" invertAxis="false" mouseAxis="AXIS_FRONTLOADER_TOOL" invertMouseAxis="false" speedFactor="0.3">
   <dependentPart index="0>42|0|0" />
   </movingTool>

ersetze bei beiden Einträgen attacherJointIndices="2" durch attacherJointIndice="1"

unter attacherJointIndices gibt man die attacherJoints an, die bei der Bewegung des entsprechenden movingTools mit aktualisiert werden sollen. Gemeint ist hierbei der Index in der XML.
Du hast 2 AttacherJoints im Abschnitt <attacherJoints> deiner XML
index 0 : die Heckhydraulik
index 1 : der Frontlader
daher musst du 1 angeben. Der originale FL von dem du die Einträge hast, hat auch eine Fronhydraulik, weshalb dort der Index 2 war.

erstmal vorweg... evtl. mal über die Worte von 3xitus nachdenken denen ich voll und ganz zustimme. 70% der Notebook-Besitzer die ich kenne, währen mit einem PC besser bedient. Preis/Leistungstechnisch ist das Notebook definitiv um vieles schlechter als gängige PC´s. Viele kommen mit dem Spruch das sie ja auch mal mit Freunden auf Lans zocken - Leute dafür wurden Shuttle-PC´s erfunden. Und ein PC nimmt nicht wesentlich mehr Platz weg als ein Notebook - ihn kann man ja sonstwo im Zimmer aufstellen.

Die Problematik der Wärme-Entwicklung kenne ich zu gut. Mein (altes) Notebook - Siemens Amilo D - ist bekannt dafür das es schnell zu heiss wird. Es schaltet sich ab einer gewissen Temperatur einfach ab. Ich habe mir dann ein CoolingPad mit 3 Lüftern zugelegt. Dabei sollte man jedoch auch berücksichtigen das die Dinger nicht gerade leise sind. Das sind 3 80mm Lüfter da drinnen und die machen ordentlich Druck. Das hat die effektive Spielzeit im BF2 (hab ich damals viel damit gespielt) etwa um 20% erhöht .- geht aber gewaltig auf den Akku - also nur was für den reinen Netzbetrieb. Ausserdem ist so ein CoolingPad unhandlich zum Transport.

Ein echt gutes Ergebnis habe ich dann dadurch erreicht, dass ich mein Notebook aufgeschraubt und gereinigt habe. Das war auch bitter nötig. Im Inneren wird die Luft teilweise durch Luftkanäle geleitet - die Hälfte davon war durch Staub abgedichtet. Ausserdem habe ich den Grafikchip-Lüfter durch ein wesentlich effizienteres Modell getauscht. Allerdings sollte man dazu sagen, das ich früher bei Siemens Nixdorf (Fujitsu Siemens) gearbeitet habe und mich daher mit diesen Notebooks auskenne. Das ist definitiv nichts für einen Laien - es sei denn man findet eine detaillierte Arbeitsanleitung im Internet (zu manchen Notebooks gibt es das als Video oder Bildershow). Nicht vergessen das man dadurch definitiv die Garantie verliert und das beim auseinander nehmen eines Notebooks immer das Risiko einer Beschädigung besteht, einfach weil Notebooks nicht dafür gedacht sind und viele Dinge mit Plastiknasen eingeclipst oder teilweise sogar verklebt/verschweisst werden.

ich hatte es auf der GC in den Händen. Klar ist die Grafik nicht PC-Standard - vor allem weil eben nicht soo viel Vegetation untergebracht werden kann. Dafür ist aber der 3D Effekt ganz witzig. Für mich wäre es allerdings nicht wirklich eine Alternative - ich bleibe beim echten Computer - dem PC

.tobj = texturobjekt - ist bis 18WoS Convoy eine Textdatei gewesen. Seit 18WoS Haulin / ETS / GTS ist es eine Binärdatei welche lediglich die Pfade zu den Texturen sowie die Farben der Materialien enthält.
.pmg = Prism3D Geometry - ist das eigentliche Modell - dazu gehören aber noch
.pmd = Prism3D Definitions - die konfigurationsdatei
.pmc = Prism3D Collisions - die Kollisionsboxen und
.pma = Prism3D Animations - die Animationsdaten.

PMG kann derzeit ausschliesslich mit der registrierten Version des ZModeler2 geöffnet werden.

Anmerkung: Export geht auch mit der kostenlosen Version - das einzige was die Vollversion bietet ist der Datei-Import.

Technisch korrekt wäre ja das Mod. Ganz einfach weil ein Mod keine Person ist und somit vom Genus her sächlich.
Ich verwende dennoch den männlichen Artikel "der Mod" weil es sich so eingebürgert hat.

Korrrekterweise muss man auch sagen das der Mod nicht von "die Modifikation" kommt , sondern von "the modification".
Die Engländer machen es sich einfach und haben generell keinen Genus in ihren Artikeln - bei der Übernahme dieser Worte wird meist willkürlich ein Artikel gewählt der gut dazu klingt. Abgesehen davon handelt es sich bei dem Mod zwar ursprünglich um eine Kurzform , aber letztendlich ist es ein eigenständiges Wort geworden.

Man könnte sich genauso gut fragen warum "der Radio-/Rundfunk-empfänger" üblicherweise als "das Radio" bezeichnet wird.
Oder warum aus "der Zeitmesser" oder "der Chronograph" plötzlich "die Uhr" wurde.
Und da wäre zB noch "das Keyboard" oder "die Tastatur".
Und um im Fach zu bleiben natürlich der Traktor bzw. die Landmaschine - also das Zugfahrzeug :p

Ok beim letzten Beispiel habe ich getrickst, denn die Landmaschine und das Zugfahrzeug sind zusammen gesetzte Wörter bei denen der Hauptteil auch den Artikel bestimmt. Obwohl das Fahrzeug ja eigentlich auch eine Maschine ist. Man kann philosophieren wie man will - letztendlich kommt man zu dem Schluss das die Vergabe des Genus bei nicht-lebenden Objekten willkürlich durchgeführt wird.
Und rein akkustisch muss ich sagen das "der Mod" und "das Mod" für mich noch ok sind. Aber "die Mod" - nee das klingt mir zu sehr nach turk-deutsch.

zum Schluss noch ein wenig Verwirrung: pD. bauen wir keine Mods ... sondern wir bauen Extensions/Addons. Denn unsere Mods sind größtenteils keine Veränderungen des Spiels sondern Erweiterungen.

bei den meisten moderneren Computern sind Netzwerkkarte und Sound onBoard. Das heisst diese Treiber werden im Allgemeinen durch den Chipsatztreiber mit installiert. Dafür wäre es hilfreich zu wissen welches Mainboard du hast. Wenn du das nicht mehr weisst helfen Tools wie CPUz oder Everest. Vielleicht geistert ja auch noch irgendwo die CD/DVD zum Mainboard bei dir rum - das wäre die einfachste Methode. Sobald du wieder Internet hast , kannst du ja dann die Treiber aktualisieren.

in einigen Städten gibts "Handy-Kliniken" - bzw. Notdienste. Du solltest dort mal nachfragen ob die dir die Daten auf einen USB Stick retten würden. Die können ja vorrübergehend ein neues Display anstecken - sowas sollten die da haben. Bzw. die kommen sicherlich auch an den Speicherbaustein des Handys ran.

happened: 10 bezieht sich auf die Static Actor Moved Fehler - wenn der selbe Fehler mehr als 10x auftaucht , wird nur noch happened:10 geschrieben damit die Log nicht so groß wird.

Du hast da wohl einen Mod mit einem static actor fehler.

InsiderTipp: zum ein/ausblenden von Objekten gibts ne Minispezi setBlends.lua ( sorry ich weiss nicht von wem - ist mir aber häufig begegnet ) und alternativ mein BeleuchtungV3.1 - ist zwar keine Lampe - geht aber trotzdem an/aus

also als BF/CoD Alternative wäre definitiv Armed Assault 2 zu nennen. gibts mehr verschiedenen Waffen und Fahrzeuge als in den anderen beiden Spielen zusammen - ausserdem gibts ne Menge Mods dafür.

Für richtig Action kram ich aber auch gerne mal wieder das gute alte UnrealTournament raus - einer der schnellsten und actionreichsten Shooter überhaupt.

JustCause hab ich auch gern gespielt - einfach spassig und ein wenig anders als die anderen

der Wechsel auf 1:1 trennt endlich mal wieder die Modder von den Umbauern. Dann kommen vielleicht mal wieder mehr neu gebaute Mods statt die 1284. Version eines Traktors aus LS08 Zeiten.

was sich durchaus einrichten liesse.
was mich verwirrt ist die Tatsache das ich das XDisc selber verwende und dort das Gras nachwächst. Ich vermute aber dir geht es eben darum dass das Gras von einem Mähwerk geschnitten und nicht rasiert werden sollte. Da stellt sich mir die Frage ob es nicht sogar sinnvoll wäre das als global wirkenden Mod zu gestalten. Denn die LS Standardlösung (das Gras wird bis in den Erdboden abrasiert) finde ich generell doof.

technisch gesehen macht es keinen Sinn Silo/Silage (also das BGA Endprodukt) in einen Hänger zu laden. Allerdings gibt es einige Maps auf denen die Gärsilos auf dem Farmer-Gelände sind und nicht auf dem BGA Gelände - so das ein Transport notwendig wird. Es ist einfach präventiv schonmal so gestaltet das man diese "Frucht" aufladen kann für den Fall das es irgendwann mal sinn macht.
Natürlich kannst du zB den Silostar "tiefer legen" so das man mit dem asw direkt rein schieben kann , oder du verwendest alternativeTipping von SFM und schiebst das Zeug direkt vor dem Silostar ab, so dass du mit dem Frontlader nicht mehr so weit fahren musst (macht natürlich auch nur Sinn wenn die Gärsilos weiter weg sind)

ich schreibe das weil ich der Scripter bin. Und wenn du Hilfe beim Umbau meines Scriptes suchst, wäre es in meinen Augen das sinnvollste erstmal mich zu fragen - aber höchstwahrscheinlich kennen sich die anderen besser aus mit dem was ich geschrieben habe.