Beiträge von JakobT

xyz ist einfach nur mein classObject.

Ich habe auf deinen Rat hin mal aus xyz.playerOnFoot einfach ne local var names playerOnFoot gemacht, und siehe da, schon geht's. Ich versteh nicht warum, aber das Resultat ist das was ich wollte.

Danke für eure Hilfe.

Tja, danke für den Hinweis, aber selbst wenn ich's in der update() mache erscheint nichts. Ich muss zugeben, ich bin ein wenig ratlos.

Hallo zusammen,

ich versuche zur Zeit einen HelpButtonText zu erstellen, der nur angezeigt wird wenn man nicht in einem vehicle ist. Die Abfrage dafür läuft in der update() function:
[lua]if g_currentMission.controlledVehicle ~= nil then
xyz.playerOnFoot = false
else
xyz.playerOnFoot = true
end[/lua]

Die Variable funktioniert einwandfrei: ich benutze sie in der update() noch für etwas anderes, was 1a klappt.

In der draw() function hab ich dann addHelpButtonText, addExtraPrintText und addWarning versucht, doch nur bei letzterem wird auch was angezeigt. Wenn man nicht gerade nahe einem vehicle ist und das "Einsteigen: Taste E" angezeigt wird, scheint g_currentMission.showHelpText auch false zu sein. Selbst ohne eine if xyz.playerOnFoot then-Abfrage wird rein gar nichts angezeigt, was mich zu der Frage bringt ob das engine-intern so geregelt ist dass, wenn man onfoot ist, das helpMenu nur angezeigt wird wenn man nahe eines vehicles ist.

Log gibt keinen Fehler. Hat jemand ne Idee? Danke im Voraus.

Ich bekomm mit dem sowohl Static Actor errors (die m.E. aber nicht aus der i3d kommen) wie auch unlogged CTDs beim Savegame laden.

Bin durch Ausschlussverfahren auf den TMK gekommen nachdem ich um's verrecken nicht mehr in mein Savegame reinkam. Nach und nach alle vehicles rausgeworfen, nur noch den TMK drin gehabt, CTD. Im laufenden Spiel neu kaufen und benutzen funktioniert aber einwandfrei.
Dass die Static Error actors nicht direkt von der i3d kommen denke ich weil die üblichen Fehlerursachen (ungescaledtes static child eines scaled parents) nicht vorhanden sind. Ich hab auch nichts Außergewöhnliches in den Attributen in der vehicles.xml entdecken können.

Hat jemand den selben Fehler bzw. evtl. sogar eine mögliche Ursache?

Zitat von Malte98

die heckklappe darf bei dem tebbe eigendlich nicht aufgehen zum streuen macht man in echt auch nur die schibewand

Danke für den Hinweis. Zunächst wusste ich das erstmal nicht. Dann ist mir aber ingame aufgefallen wie blöd das mit dem ParticleSystem aussieht wenn die Klappe geschlossen ist. Das soll kein Hieb gegen Maurus sein, sondern eher gegen die LS-Engine.
Ich habe den obigen Code also nun geupdated, mit folgender Änderung: die Öffnung der Klappe kann vom User gesetzt werden, via "Fruchtumfahrung ein" (Klappe auf während des Düngens) und "Fruchtumfahrung aus" (Klappe zu während des Düngens).

[Reserved for updates]

Hallo zusammen,

ich hab ein paar kleine Zusatzfunktionen bzw. -snippets für Courseplay geschrieben, die dazu führen dass Stefan Maurus' Tebbe HS180, sein Fuchs Güllefass und bassaddict's Universal Bale Trailer (besser) mit CP funktioneren. Wer möchte kann sich das einbauen, ich beschreibe weiter unten was zu tun ist und wie der Code funktioniert.

Ich möchte aber zunächst ein paar Sachen betonen:

• Die Änderungen führen dazu dass CP (und teilweise auch die Mods selber) seine Multiplayer-Fähigkeit verliert (es sei denn ihr tauscht untereinander eure CP-Dateien aus, wovon ich mich strengstenst distanziere!).
• Ich werde nicht die gesamten fertigen Dateien zur Verfügung stellen. Die jeweiligen Autoren haben allesamt lange und hart an ihren Projekten gearbeitet, und daher halte ich es für 1. frevelhaft da jetzt gänzlich veränderten Teile online zu stellen, und 2. zumutbar dass ihr die Mods sowohl von den Originallinks runterladen als auch selbst verändern könnt.
• Ich habe das ganze mit CP v2.99 gemacht, da das die Version ist die ich primär benutze. Die Änderungen müssten in v3.12 quasi genauso funktionieren, aber ich habe es nicht getestet.

Tebbe HS180 Miststreuer von Stefan Maurus (v2.1)
Der Tebbe funktioniert eigentlich 1a mit CP. Folgende zwei Funktionen habe ich aber hinzugefügt:

• Die Klappe wird entweder automatisch geöffnet und geschlossen (wenn "Fruchtumfahrung" auf "ein" gesetzt ist) wenn der Tebbe anfängt zu streuen bzw. wenn er aufhört (leer ist); oder sie bleibt gänzlich zu (wenn "Fruchtumfahrung" auf "aus" gesetzt ist).
• Die Rückwand fährt automatisch auf eine vom User eingestellte Stufe (1, 2 oder 3) und wird geschlossen wenn er aufhört (leer ist). Der User kann (muss) diese Stufe über die Courseplay-Arbeitsbreite eingeben: 1m = Stufe 1, 2m = Stufe 2, 3m = Stufe 3. Ich habe mich aufgrund von 3 Faktoren für 1, 2 und 3 entschieden:
  
  
  • Es ist simpel und an sich intuitiv. Man kann schneller zwischen den einzelnen Stufen wechseln.
  • Ich wollte nicht die Illusion aufkommen lassen man könne dadurch die wirkliche Arbeits- (Streu-)breite des Gerätes einstellen. Sondern "nur" die Rückwändstufe (die dann die Arbeitsbreitenveränderung, den Mistverbrauch etc. mit sich bringt).
  • Die Courseplay-Default-Arbeitsbreite ist 3m. Damit wäre das dann schon von Anfang an gesetzt.

  
  

• Die Zeilenangaben stimmen jeweils wenn ihr den Code bis dahin so wie angegeben eingebaut habt.

An dieser Stelle Respekt und Danke an Stefan Maurus für sein einfaches und sauberes Scripten. Hat die Sache relativ einfach gemacht.

Einbau:
Zunächst lassen wir CP wissen dass der aktuelle Miststreuer der Tebbe HS180 ist:

mode4.lua - Z56 (unter "local is_ux5200 = workTool.state ~= nil and workTool.state.isTurnedOn ~= nil")
[lua]local is_tebbeHS180Maurus = workTool.flapopen ~= nil and workTool.setDoorHigh ~= nil[/lua]
Danach frägt CP ob es quasi an ist und gefahren wird etc. Dann folgt die Abfrage ob das Gerät die UX5200-Spritze ist, ergo gehen wir in den else-Bereich darunter.

mode4.lua - Z74 (nach "else", vor "if isFoldable")
[lua]
if is_tebbeHS180Maurus then
--Klappe, gekoppelt an CP-Fruchtumfahrung (true false)
local flapOpenBool = self.realistic_driving
if flapOpenBool ~= nil then
if type(flapOpenBool) == "boolean" then
workTool:setFlapOpen(flapOpenBool)
end
else
workTool:setFlapOpen(false)
end

--Rückwand, gekoppelt an CP-Arbeitsbreite (1 2 3)
local doorOpenStage = self.toolWorkWidht
if type(doorOpenStage) ~= "int" then
local doorOpenStage = tonumber(self.toolWorkWidht)
end
local doorOpenStageValid = false

if doorOpenStage ~= nil then
if doorOpenStage == 1 or doorOpenStage == 2 or doorOpenStage == 3 then
doorOpenStageValid = true
end
end

if doorOpenStageValid then
workTool:setDoorHigh(doorOpenStage)
else
allowedToDrive = false
--"Rückwand-Stufe muss per Arbeitsbreite gesetzt sein (1, 2 oder 3)"
self.global_info_text = courseplay:get_locale(self, "TebbeHS180DoorStage")
end
end
[/lua]
Der Code macht folgendes:
[lua]
if is_tebbeHS180Maurus then --wenn das Gerät der Tebbe HS180 ist
--Klappe, gekoppelt an CP-Fruchtumfahrung (true false)
local flapOpenBool = self.realistic_driving -- Neue Variable, frägt die vom User eingestellte Fruchtumfahrung ab
if flapOpenBool ~= nil then -- wenn die Fruchtumfahrung existiert...
if type(flapOpenBool) == "boolean" then -- ...und sie boolean ist
workTool:setFlapOpen(flapOpenBool) -- setze die die Klappe auf den eingestellten wert (true bzw. false)
end
else -- andernfals
workTool:setFlapOpen(false) -- schließe die Klappe
end

--Rückwand, gekoppelt an CP-Arbeitsbreite (1 2 3)
local doorOpenStage = self.toolWorkWidht -- Neue Variable, frägt die vom User eingestellte CP-Arbeitsbreite ab [toolWorkWidht = sic!]
if type(doorOpenStage) ~= "int" then -- wenn die CP-Arbeitsbreite nicht im Integer-Format ist
local doorOpenStage = tonumber(self.toolWorkWidht) -- konvertiere sie ins Integer-Format
end
local doorOpenStageValid = false

if doorOpenStage ~= nil then -- wenn die CP-Arbeitsbreite existiert ...
if doorOpenStage == 1 or doorOpenStage == 2 or doorOpenStage == 3 then -- ... und wenn die CP-Arbeitsbreite entweder 1, 2 oder 3 ist ...
doorOpenStageValid = true -- ... dann ist alles okay mit der CP-Arbeitsbreite und wir können fortfahren
end
end

if doorOpenStageValid then -- wenn alles okay mit der CP-Arbeitsbreite ist
workTool:setDoorHigh(doorOpenStage) -- öffne die Rückwand auf die per CP-Arbeitsbreite eingestellte Stufe
else --andernfalls
allowedToDrive = false -- halte an, schalte den Streuer aus

--* folgendes ist optional *
--* EXTRA-INFO ZUR NACHRICHT-EINBLENDUNG WEITER UNTEN *
--"Rückwand-Stufe muss per Arbeitsbreite gesetzt sein (1, 2 oder 3)"
self.global_info_text = courseplay:get_locale(self, "TebbeHS180DoorStage") -- und verkünde die Nachricht dass hier was nicht stimmt
end

end
[/lua]

So, jetzt weiß er was zu tun ist wenn er zu streuen beginnt. Nun noch die Aktionen beim aufhören (wenn er leer ist). Wir gehen ist den workSpeed = false Bereich:

mode4.lua - Z128 (nach "else", vor "if isFoldable")
[lua]
if is_tebbeHS180Maurus then
workTool:setFlapOpen(false) --Schließe die Klappe
workTool:setDoorHigh(0) --Setze die Rückwand auf Stufe 0 (= geschlossen).
end
[/lua]

Optional: Nachricht-Einblendung wenn die Rückwandstufe nicht stimmt
base.lua - Z66 oder irgendwo in dem Bereich wo die ganzen self.locales-Dingers angegeben sind.
[lua]self.locales.TebbeHS180DoorStage = g_i18n:getText("TebbeHS180DoorStage")[/lua]

moddesc.xml - in den l10n-Bereich

<text name="TebbeHS180DoorStage">
	<en>Door must be set via CP work width (1, 2 or 3)</en>
	<de>Rückwand-Stufe muss per CP-Arbeitsbreite gesetzt sein (1, 2 oder 3)</de>
</text>

Und das war's. Wenn ihr alles richtig gemacht habt öffnet er jetzt beim Streu-Anfang die Klappe und setzt die Rückwand auf die von euch über die Arbeitsbreite angegebene Stufe, und schließt beide wenn er leer ist und zum Auffüllen fährt.

Fuchs Güllefass von Stefan Maurus (v1.1)
Das Güllefass ist deutlich simpler einzustellen als der Tebbe-Miststreuer. Wir wollen nur dass der Schwenkverteiler beim Düngen aktiviert wird. Leider muss man dafür auch den Code des Fasses selber minimal verändern.
Die Zeilenangaben sind für die original mode4.lua (ohne den Miststreuer eingebaut).

Einbau:
Zunächst öffnen wir die Schwenkverteiler.lua des Güllefasses und kommentieren das if self:getIsActive() weg

Schwenkverteiler.lua - Z72
[lua]if self:getIsActive() then[/lua]
wird zu
[lua]--if self:getIsActive() then[/lua]

Schwenkverteiler.lua - Z97
[lua]end[/lua]
wird zu
[lua]--end[/lua]

Das hat zur Folge dass der Schwenkverteiler auch aktiv sein kein wenn man nicht im Fahrzeug sitzt (was ja bei CP oftmals der Fall ist).

Dann zurück zu CP.

mode4.lua - Z56 (unter "local is_ux5200 = workTool.state ~= nil and workTool.state.isTurnedOn ~= nil")
[lua]local is_fuchsMaurus = workTool.setAllumer ~= nil --ist das Arbeitsgerät das Fuchs-Güllefass?[/lua]

mode4.lua - Z74 (nach "else", vor "if isFoldable")
[lua]
if is_fuchsMaurus then --wenn es das Fuchs-Güllefass ist
workTool:setAllumer(true) --aktiviere den Schwenkverteiler
end
[/lua]

mode4.lua - Z99 (nach "else", vor "if isFoldable")
[lua]
if is_fuchsMaurus then --wenn es das Fuchs-Güllefass ist
workTool:setAllumer(false) --deaktiviere den Schwenkverteiler
end
[/lua]

Das war's.

[infobox]Die Dingers für bassaddict's UBT kommen später. Die Basissachen gehen, für den Rest muss ich noch ein wenig testen. Daher mein reserved post.[/infobox]

Zitat von MR2

Vielleicht ist es eine doofe Frage aber hast Du beim aufzeichnen des Kurses auch abgekippt ?
Nur um es auszuschliessen !

Das muss man bei Courseplay - im Gegensatz zu früher (LS09) mit dem Abfahrhelfer - nicht machen. Über/durch den Trigger fahren reicht.

@xpsdriver: Was eventuell sein könnte ist das direkt neben oder bei dem Chafftrigger noch ein anderer Tiptrigger ist, der im ... ich nenn's mal Einzugsbereich des Courseplay-Trailers ist. Dadurch könnte CP denken du willst bei dem anderen und nicht dem Chafftrigger abladen. Da du aber nicht drüber-/durchfährst lädt er auch nicht ab.

Das ist nur ne Theorie, ich hab das nämlich öfters mal gehabt wo Trigger sehr nah beieinander waren und dadurch nicht abgekippt wurde.

Zitat von DoseCola

achso
dazu musst du soweit ich weiss in der XML nen Eintrag löschen aber ich hab keine Ahnung welchen, da ich nicht weiss wie des heisst

Warum antworteste dann die ganze Zeit wenn du's eh nicht weißt?

Zitat von Spichek

Eingabaut ist es ja, ich will es ja nicht mehr haben. Ich möchte wissen, welches Script das ist und wie ich es deaktivieren bzw. entfernen kann.

Was du suchst ist die lanes.lua. einfach in der moddesc auskommentieren - fertig.

Edit: Martl war schneller.

Danke für die cannabisförmigen Blumen

Ich hatte vor ner Weile noch ein bisschen am Tool rumgebastelt, namentlich Codeoptimierung, daraus entstehende Performanceverbesserung und ein kleines Designupdate. Außerdem eine FAQ-Section mit m.E. allen nötigen Infos. v0.3b im OP.

Edit: forum staff: wieso ist dieser Thread in der Tutorials Section gelandet?

Sollte das jetzt wirklich das Problem bzw. die Lösung sein frage ich mich - mal wieder - warum eben diese Textur bei mir in ner anderen Map funktioniert. Auf gut deutsch: ich hasse nicht-absolute Lösungen

Ich habe in den Kommentaren zur Map bei MH gelesen dass jemand den selben Fehler hatte und ihn durch das Austauschen der meadow-Textur gefixt hat (Link). Ich habe momentan keine Zeit das zu testen, aber mir fällt dabei auf: Die von der Map benutzte Textur hat nur Grafiken für die Stufen 4 und 5. Ich bin mir nicht ganz sicher ob das was ausmacht, oder ob die Engine dann auch für die Stufen 1 bis 3 den Teil der Textur für die Stufen 4 bis 5 benutzt. Theoretisch könnte das allerdings erklären warum Stufe 1-3 ingame nicht angezeigt werden würden.

ABER. Ich habe dieselbe meadow-Textur auch schon mal in einer anderen Map benutzt, und da gab es keine Probleme von wegen Nachwachsen, oder zumindest dem Sehen der einzelnen Stufen. Insofern ist das für mich gerade eine mentale Zwickmühle.

Zitat von bassaddict

Nein, das Gras nicht. Nur der Mais auf dem Feld nebenan. Ich hatte zwischenzeitlich die mapfruits rausgenommen, wollte deswegen zur Sicherheit noch eine Stufe abwarten, da ists aber vorher schon abgeschmiert.

Ah, ich dachte schon; hätte mich gewundert.

Zitat von bassaddict

Du hast es geschafft die Map in 10min zu optimieren? Das kann ich mir beim besten Willen nicht vorstellen. Damit man da wirklich optimiert und die Fehler behebt gehen locker 3-4 Stunden drauf.

Naja, natürlich nicht alles. Aber die groben Feher zumindest kriegt man recht schnell weg. Map_Fruits (die ich persönlich immer seperat hab und je nach Map aktiviere und deaktiviere), sugarbeet, die static actors, die fehlende map01_sat-Referenz. Klar bleiben da dann noch kleinere Fehler, die aber a) das Spielen nicht unermesslich mindern und b) mir wahrscheinlich eh erst auffallen während ich die Map spiele.

Zitat

Ich werd da nachher aber auf jeden Fall nochmal ein bisschen rum probieren, vielleicht finde ich ja eine Lösung.

Würde mich freuen. Ich bin momentan noch wegen etwas anderem in Kontakt mit dem Autor, werde ihn dementsprechend auch nochmal darauf ansprechen.

Zitat von bassaddict

Optisch ist die Map ziemlich gut, aber technisch ne totale Katastrophe.
[...]
Wozu man diese mapfruits.zip braucht kann ich überhaupt nicht nachvollziehen. Da sind nur die Standardfrüchte drin. Und die Zuckerrüben sind falsch eingebaut, Wenn die überhaupt funktionieren dann nicht richtig. Soviele Früchte unnötig ins Spiel einfügen kann nie gut sein.

Du hast natülich nicht unrecht, sie ist vom Aufbau nicht gerade optimiert. Aber ich benutze lieber eine Map dir mir optisch gefällt und die ich selber ein wenig fixen muss (das mit den Zuckerrüben, den map_fruits etc.) als andersrum. Und das ist wirklich nur ne Sache von 10 Minuten (bis auf den Gras-Fix, anscheinend).

Zitat von bassaddict

Eine wachstumsstufe vom Feld nebenan hab ich gesehen

Das heißt bei dir ist es gewachsen? Das wundert mich jetzt ein bisschen. Warum geht's bei dir und bei anderen wiederum nicht?

Zitat von böserlöwe

Wenn ich die Zeiten für das Graswachstum richtig interpretiere, dann dauert eine Stufe nur 3 Stunden Echtzeit.
Bei 5 Stufen die angegeben sind, kommen da schon mal 15 Stunden Echtzeit zusammen die das Spiel auch laufen muss.
Wenn man so lange auch nicht warten will, sollte man daran vielleicht auch noch etwas verändern.

Richtig. Das hieße aber auch, dass man nach 3h die erste Stufe, nach 6h die zweite etc. sehen würde. Was zumindest bei mir nicht der Fall ist. Ich probier dennoch mal die Runterstufung auf 5 Minuten oder so was, einfach zum testen.

Ich kann das Problem bestätigen, habe es sowohl mit Original-Maschinen als auch anderen Mods (dem Eifok-Pöttinger-Zeugs) probiert - das Gras wächst auch bei mir nicht nach. Erklären kann ich's mir nicht.

Ich habe den Foliage Layer mal mit dem einer anderen Map probiert, wo das Gras auf jeden Fall nachwächst:

<!-- Homfeld -->
<FoliageSubLayer name="grass" densityMapTypeIndex="2" densityMapChannelOffset="4" numDensityMapChannels="3" materialId="956" cellSize="8" viewDistance="100" terrainOffset="0" objectMask="65520" distanceMapIds=";569;570;571;572" distanceMapUnitSizes=";128;128;128;128" separateAvailabilityChannel="false" atlasSize="2" plantThreshold="2" numBlocksPerUnit="1.5" width="1.1" height="1.3" widthVariance="0" heightVariance="0.2" horizontalPositionVariance="0.5" growthNumStates="5" growthStateTime="1.08e+007" hasGrowthAtlas="true"/>
<FoliageSubLayer name="grass_cut_long" densityMapTypeIndex="2" densityMapChannelOffset="8" numDensityMapChannels="2" materialId="490" cellSize="8" viewDistance="100" terrainOffset="0" objectMask="65520" distanceMapIds="572" distanceMapUnitSizes="128" separateAvailabilityChannel="false" atlasSize="1" plantThreshold="0.5" numBlocksPerUnit="2" width="1.8" height="0.5" widthVariance="0" heightVariance="0.1" horizontalPositionVariance="1.5" blockShapeId="468" useShapeNormals="true"/>
<FoliageSubLayer name="grass_windrow" densityMapTypeIndex="2" densityMapChannelOffset="10" numDensityMapChannels="2" materialId="116" cellSize="8" viewDistance="100" terrainOffset="0" objectMask="65520" distanceMapIds="571" distanceMapUnitSizes="128" separateAvailabilityChannel="false" atlasSize="1" plantThreshold="0.5" numBlocksPerUnit="2" width="1.5" height="1.25" widthVariance="0" heightVariance="0.1" horizontalPositionVariance="0.5" blockShapeId="468" useShapeNormals="true"/>

<!-- Referenz-Map -->
<FoliageSubLayer name="grass" densityMapTypeIndex="2" densityMapChannelOffset="4" numDensityMapChannels="3" materialId="1735" cellSize="8" viewDistance="70" terrainOffset="0" objectMask="65520" distanceMapIds="33;43;44;45;46" distanceMapUnitSizes="128;128;128;128;128" separateAvailabilityChannel="false" atlasSize="2" plantThreshold="0.5" numBlocksPerUnit="1" width="1.5" height="1.3" widthVariance="0" heightVariance="0.2" horizontalPositionVariance="0.5" growthNumStates="5" growthStateTime="3.6e+006" hasGrowthAtlas="true"/>
<FoliageSubLayer name="grass_cut_long" densityMapTypeIndex="2" densityMapChannelOffset="8" numDensityMapChannels="2" materialId="532" cellSize="8" viewDistance="70" terrainOffset="0" objectMask="65520" distanceMapIds="46" distanceMapUnitSizes="128" separateAvailabilityChannel="false" atlasSize="1" plantThreshold="0.5" numBlocksPerUnit="1.3" width="1" height="0.5" widthVariance="0" heightVariance="0.1" horizontalPositionVariance="0.8" blockShapeId="3" useShapeNormals="true"/>
<FoliageSubLayer name="grass_windrow" densityMapTypeIndex="2" densityMapChannelOffset="10" numDensityMapChannels="2" materialId="1322" cellSize="8" viewDistance="120" terrainOffset="0" objectMask="65520" distanceMapIds="45" distanceMapUnitSizes="128" separateAvailabilityChannel="false" atlasSize="1" plantThreshold="0.5" numBlocksPerUnit="1.2" width="1.2" height="1.45" widthVariance="0" heightVariance="0.1" horizontalPositionVariance="0.1" blockShapeId="3" useShapeNormals="true"/>

Klar gibt's ID-, Height- und Width-Unterschiede, aber das einzig markante wäre vielleicht dass Homfeld nur 4 distanceMaps hat. Warum das aber zu einem Nicht-Nachwachsen führen sollte weiß ich auch nicht. Und an sich ist das Nachwachsen ja auch nicht im Foliagelayer geregelt, sondern in der "registerFruitType"-Funktion.

Da haste natürlich an sich nicht unrecht. Ich habe das Setup so belassen weil's eben die ganze Zeit so war und (s)ich nur die Map verändert habe (hat).

Zunächst einmal habe ich ne andere Map probiert (Two Rivers), da ging alles wie gewohnt. Also lässt sich auf ein Map-spezifisches Problem schließen, oder?

Danach habe ich das mit Homfeld mal ohne Mods (bis auf die Map natürlich) probiert und mit einem neuen Spielstand. Hier ist ein anderes Problem aufgetaucht: das Hilfefenster wird nicht angezeigt. Was auch wiederum dazu führt dass ich nicht abladen kann (auch das Abladesymbol wird nicht angezeigt, was für mich heißt er erkennt nicht richtig dass der Trailer im Trigger ist). Log ist clean (s. Anhang), automatische Hilfe in den Optionen ist aktiviert.

Als nächstes die Mods reingemacht die von der Map benötigt werden (MapBGA, bestimmte Map_Fruits, MapWeightstationMod etc.). Siehe da, alles funktioniert wie es soll. Hilfefenster, abladen etc. Was wiederum bedeutet dass du recht hast, es muss ein Mod-Konflikt sein. Entweder ich hab nen Mod eingefügt und kann mich nicht dran erinnern, oder ... deus ex machina.

Ich werde als nächstes mal die Mods einfügen die ich im Savegame hab und dann nach und nach weiterkucken. Besten Dank erstmal. Zumindest meine Nerven können sich ein wenig entspannen.

Wie ich oben schon geschrieben habe, die Log ist sauber. Was ja auch mein Problem ist. Hab sie aber dennoch mal (unwesentliche Sachen wie Courseplay und FsIX gekürzt) angehängt im 1. Post.

Hallo zusammen,

ich habe momentan ein Problem mit dem Mapumbau der Homfeld-Map und stoße an meine eigenen Lösungsgrenzen.

Das Problem besteht momentan darin dass ich an keinem TipTrigger abladen kann. Der Abladen-Infotext wird angezeigt, ich kann es auch aktivieren, die Abladeanimation des Trailers startet auch, das war's dann aber. Es wird nicht abgeladen, kein PS, Trailer leert sich nicht, Silo-Füllstand erhöht sich nicht. Gleiches bei Verkaufstriggern.

Desweiteren ist mir auch aufgefallen dass solche Spezialabladeoptionen wie der TipAnywhere- oder der HeapTip-Trigger nicht im Hilfepanel angezeigt werden, geschweige denn funktionieren. Bei jeglichen Trailern.

Die Log ist so sauber als wäre Meister Proper vor Ort gewesen, keine Info geschweige denn Fehler oder Warnungen.

Ich kann nicht ganz genau sagen nach welchem Umbauschritt der Fehler eingetreten ist, folgendes habe ich aber in der letzten Zeit verändert:

• Map-Datei umbenannt von "Homfeld.i3d" zu "map01.i3d" (inkl. lua-Anpassung natürlich, sonst würde ich ja nichtmal ingame kommen), um ein PS mit dem MapFruitChangeTrigger benutzen zu können (siehe Punkt 2).
• Einen MapFruitChangeOutputTrigger mit PS hinzugefügt (der auch einwandfrei funktioniert).
• Das UserAttribute "appearsOnPda" vom Hof-TipTrigger entfernt.
  
  
  XML

  <Attribute name="fruitTypes" type="string" value="wheat barley rape maize grass dryGrass chaff"/>
        <Attribute name="isFarmTrigger" type="boolean" value="true"/>
        <Attribute name="onCreate" type="scriptCallback" value="TipTrigger.onCreate"/>

  
  

• Einen zusätzlichen manure-TipTrigger an einer Mistgrube hinzugefügt:
  
  
  XML

  <Attribute name="fruitTypes" type="string" value="manure"/>
        <Attribute name="isFarmTrigger" type="boolean" value="true"/>
        <Attribute name="onCreate" type="scriptCallback" value="TipTrigger.onCreate"/>

  
  

• Gülleverkaufsgrube vom MapTools-MapperKit hinzugefügt. Unverändert.
• Es gibt bei der Verkaufsstation "Raiffeisen" zwei Trigger, die beide "appearsOnPDA" auf true hatten. Beim zweiten die "appearsOnPDA"-Zeile entfernt.
• Es gab irgendwann davor noch einen Logfehler "Error: Missing priceMultipliersString user attribute for TipTrigger", den ich aber einfach lösen konnte (bei einem Verkaufstrigger fehlten die priceMultipliers).

Ich denke #5 und #6 kann man als Fehlerursache ausschließen. Ich habe geprüft ob irgendwo ein ScriptCallback falsch geschrieben war. Negativ. Ich habe es mit einem neuen Spiel versucht, um ne Savegame-Corruption auszuschließen. Selbe Fehler. Ich habe alle oben genannten Änderungen rückgängig gemacht. Fehler bleibt.

Die Tatsache dass nicht nur die TipTrigger, sondern eben auch diese TipAnywhere- und HeapTipTrigger nicht funktionieren lässt eher auf einen relativ globalen Fehler als auf einen bestimmten Trigger schließen, oder? Ich hab mich jetzt dumm und dämlich gesucht. Was mich aber am meisten ärgert dass eben nichts in der Log steht. Sonst könnte ich das Problem viel schneller finden.

Hat jemand irgendeine Idee wie so ein dann doch relativ extremer Fehler zustande kommen könnte? Besten Dank im Voraus.

Korrektheit des Pfads zum PS checken (UserAttributes). Denn das kann eigentlich der einzige Fehler sein den das (nicht vorhandene) PS hervorrufen kann. Ich hatte das auch ein paar Mal wo der Pfad einfach nicht zu 100% stimmte. Ich bin mir nicht 100%ig sicher, aber eine fehlende <Material>-Datei ruft soweit ich weiß keinen Fehler hervor.
Ansonsten: ist der Shader mit drin im PS-Ordner? Kriegst du nen Log-Fehler dass vlt zu viele Shader vorhanden sind (64 ist glaub ich max.)? Und generell, was sagt die log?