Beiträge von JakobT

Dann glaube ich du gehst das zu kompliziert an (oder ich übersehe was). Meine Vorgehensweise wäre die folgende:

• world direction der shovel node nehmen (local dx,_,dz = localDirectionToWorld(self.shovelTipReferenceNode, 0,0,1);)
• Rotation dieser direction nehmen (local yRot = Utils.getYRotationFromDirection(dx, dz);)
• setRotation(self.pivotNode, 0, yRot, 0);

Die x und z rotation brauch dich ja eigentlich nicht interessieren, da loadVehicle da eh nichts mit anfangen kann. Da du vorhin den Hang angesprochen hast, wären die x und z rots natürlich schon interessant, zumindest wenn du sie forciert setzen willst. Aber das kannste dir ja an dem Punkt aufm Terrain ausrechnen.

Vorweg: ich muss zugeben ich versteh das Problem nicht 100%ig, bzw. was das eigentliche Ziel ist. Du willst dass die child node immer die selben richtungen wie die shovelTipReferenceNode hat, plus 5 Grad? Du willst die pivotNode gleich setzen zur shovelTipReferenceNode?

Was mir jedenfalls auffällt ist dass dx, dy, dz world directions sind, setRotation() jedoch lokale (radians) erwartet. Vielleicht ist das gewollt, dann beziehe ich mich auf meine Aussage dass ich das eigentliche Ziel nicht verstehe

Seems to me the PDF is somewhat corrupted. I tried downloading it in different browsers, but always get a 0 kb file (although file-upload states it's supposed to be 0.39 MB).

Die Beschreibung der Shader-Parameter sind im Shader selber als Kommentar niedergeschrieben.

So, nochmal n bisschen Senf. Hatte den Thread verpasst, da GC am Mittwoch.

1. Bzgl. getn: #tableName ist identisch zu zu table.getn(tableName) (shorthand), sollte aber tunlichst benutzt werden da v5.2.
# gibt den höchsten numerischen key n zurück, für den tableName[1 bis n] ~= nil ist. Sprich: 1 - 6 und 24 existieren als key, dann geht 24 nicht da 23 nicht existiert. Daher getn = 6. Wenn kein passender key gefunden wird, wird 0 zurückgegeben.

2. Bzgl. iteration bei nicht-sequentiellen keys: next() ist immer für sowas gut. Nimmt auch nen Startindex als Argument, kann man also prima zum Durchschalten benutzen.

JoPi98: beim Einfügen der spec sollteste aber auf jeden Fall vorher abfragen ob der vt die spec nicht schon hat (entweder weil's ein DLC-Fahrzeug ist, oder weil die spec schon von einem anderen Script eingefügt wurde). Sonst bekommste da doppeltes Zeugs.

Das Script hängt sich auf weil ich ein "end;" vergessen hab. Im obigen Post aktualisiert.

Interesse hab ich nicht wirklich. Abgesehen davon dass ich nicht wirklich Zeit hab, hab ich auch sehr wenig Erfahrungen mit Animationen. Bei Fragen und Scriptfehlern an sich kann ich aber schon aushelfen.

• Es ist immer praktischer wenn du Scripte als LUA postest, und XML als XML. Macht beides deutlich lesbarer.
• Mit dem InputBinding an sich scheint nichts verkehrt zu sein, aber du benutzt nicht existierende globals in der update(). Muss lauten:
  [lua]
  function Seitenschwader:update(dt)
  if InputBinding.hasEvent(InputBinding.Doppelschwad_input) then
  if not self:getIsAnimationPlaying(self.DoppelschwadAnimationName) then
  local direction = 1;
  if self:getAnimationTime(self.DoppelschwadAnimationName) == self:getAnimationDuration(self.DoppelschwadAnimationName) then
  direction = -1;
  end;
  end;
  self:playAnimation(self.DoppelschwadAnimationName, direction, nil);
  end;
  end;
  [/lua]
  Ich denke der InputBinding-Fehler könnte daher kommen dass der variable-Fehler nicht geprinted wird, dadurch die update() nicht zuende läuft.
• Auch solltest du auf jeden Fall abfragen ob die Animation mit dem jew. Namen überhaupt existiert. Safety first!

Edit: script updated

Das heißt du hast einen nicht existieren InputBinding-Index benutzt. Poste nochmal das komplette script, und auch die InputBinding-Auszüge aus der modDesc.

Specializations brauchen immer bestimmte Grundfunktionen, die vom dem Haupt-Spiel-Script gerufen werden. Giants hat da wahrscheinlich vergessen gegen nil abzufragen, daher die Fehler. Es werden Funktionen gerufen die bei dir nicht existieren. Also: Funktionen einfügen (können auch leer sein), dann sollte's gehen.

Benötigte Grundfunktionen:

• load()
• delete()
• mouseEvent()
• keyEvent()
• update()
• updateTick() (bei ner Spec, nicht einer eigenen Class)
• draw()

Edit: Ein Minütchen zu spät - Fiat hat's schon korrekt gesagt.

Released.

Sorry Stefan, hatte deine Frage übersehen. Die Auswahl ist auf Traktoren begrenzt (Zielpunkt ist immer deren rootNode). Einzelne Geräte empfand ich als eher überflüssig.

Following camera
v0.2

Hier ein kleines Script das dem Spieler erlaubt, automatisch einem Traktor zu folgen. Nicht physisch, sondern per Kamera. Der Spieler wendet sich dabei immer dem ausgewählten Traktor zu. Optional kann auch der automatische Zoom aktiviert werden, der ... nunja ... automatisch zoomt.

Das Ganze ist mehr eine Spielerei, kann aber Prima z.B. für Videoaufnahmen benutzt werden, da alles viel weicher und genauer läuft als würde man manuell die Maus bewegen.

Lange Rede, kurzer Sinn:

-- Jakob

Update: v0.99 released.

Changelog:

• add safety check against improperly created BunkerSilo triggers (w/o movingPlanes)
• add warning sign if silo is fully fermented but the cover plane hasn't been removed yet
• fix scrolling functionality/zooming inhibit for vehicles with 'InteractiveControl' spec

@Moderatoren: bitte diesen Thread in 'Published User Mods > Sonstige' verschieben. Danke.

So, released.

Zitat von Johny 13

könnte man noch einbauen das es zwei verschiedene silo arten gibt also mais und gras silage je nach dem was man rein kippt??

Zitat von softy2

Also was Johny13 dazu anbrachte, ist gar nicht so verkehrt.
Es nervt wirklich, immer seperate Grass silo´s zu schaffen

Das hat beides absolut nichts mit dem Hud zu tun. Ich verändere nichts am Silo oder dessen Funktionalität. Wendet euch damit bitte an upsidedown.

BunkerSilosHud

Nachdem ich das Projekt Anfang letzten Jahres angefangen habe ist es irgendwie untergegangen. Inzwischen hab ich es aber relativ fertiggestellt und habe vor es auch zu releasen. Dieses Jahr zumindest noch.

Das BunkerSilosHud zeigt die Füllstände der Bunkersilos and, deren Status, die Verteilung der einzelnen movingPlanes usw. Es wird auch die zusätzlichen Features die upsidedown z.Z. baut, also quasi das Verrotten/Verschimmeln und die Verdichtung der einzelnen movingPlanes, unterstützen.
Desweiteren werden die Füllstände der Gülletanks angegeben. Hier werden zusätzlich zu den Standardtanks (Kuh/BGA) auch Marhu's Schweinemast und skydancer's ManureLager unterstützt.

Die einzelnen Silos und Gülletanks können individuell über ein userAttribute in der Map benannt werden (i18n-unterstützt). Diese Namen werden auch als XML-Eintrag in der vehicles.xml des Savegames gespeichert. Das hat an sich nichts mit dem Hud zu tun, sondert diente mir damals nur zur direkten Erkennung, welches onCreateLoadedObject denn nun welches ist. Und so hab ich's drin gelassen.

Die Bedienung funktioniert via Maus (Button-Click oder Scrollen)

Beispiel-Screenshots:
[expander]

Befüllbares Silo (vor Verdichtung), halb voller Gülletank

Befüllbares Silo (nach voller Verdichtung)

Fermentiertes Silo (semi-verfault)
[/expander]

Die Position ist momentan unten links (wie die PDA - die automatisch ausgeblendet wird), wird sich aber wahrscheinlich noch ändern.

Konstruktive Kritik willkommen.

Hm sorry, da schein ich mich vertan zu haben. Muss wohl an ein anderes Gerät gedacht haben. Ich untersuch das mal bei Gelegenheit.

Update: ich habe das Problem gefunden (Sprayer:draw() wird beim Zunhammer nicht aufgerufen) - aber noch keine Lösung dafür.

Zitat von Erik-37

ich bekomme beim zuhammer fass nicht das gülle hud angezeigt

Das liegt daran das der Zunhammer weder die Fillable noch die Sprayer spec hat. Nur eine handvoll specs unterstützen fillType hud-Anzeigen.

Danke, aber das hat alles so geklappt. Hatte nicht realisiert dass die matchen müssen.

Released / (en)