Oho Neue Gesichter das freut mich
Eher nicht 
. Ich lese derzeit alle Stories regelmäßig mit, antworte aber eher selten, lasse aber immer wieder mal ein "Like" da, wenn es mich berührt hat. Inzwischen muss man ja aufpassen, dass man den Stand der Dinge bei den einzelnen Geschichten noch auseinanderhalten kann. 
Schöne Story, nur ein kleiner Fehler: Der LKW ist kein "russisches Gerät", sondern ein deutsches... Naja, Ost-deutsches. Ein IFA-W50
SirSim: Ja - siehe hier: Problem mit Mist beim Kuhstall
BernieSCS Mir sind beim US-Hofpack auch noch zwei kleinere Fehler bei der Kuhweide (SCS_FEETLOT) aufgefallen.
Ich habe mir die ähnlich wie SirSim hier im Screenshot mehrfach verbaut.
Fehler 1: Die Futtertrigger (Forage) sind nicht in der gekennzeichneten Triggerfläche, sondern bereits außerhalb der Kuhweide im platzierbaren Bereich.
Fehler 2: Da ich die Idee mit den aneinandergereihten Weiden gefallen hat, habe ich mir die in zwei Reihen a' 4 Weiden zusammengestellt, mit Futterweg in der Mitte. Habe auch keine Änderungen an der XML o.ä. durchgeführt, d.h. alles Standard - 50 Kühe pro Weide. Dafür habe ich dann eine Reihe mit den 4 "europäischen" Kuharten gemacht - pro Weide eine Sorte und in der zweiten Reihe das gleiche mit den Brahman Kühen.
Nachdem ich mir dann ein paar Kühe gekauft hatte, musste ich allerdings feststellen, dass die Kühe sich auf den Weiden "vermischen". d.h. man findet in einer Reihe dann die unterschiedlichen europäischen Kühe gemischt (also z. Bsp. schwarz-weiss gefleckte, braun weiss gefleckte etc. auf jeder Weide), obwohl ich die wirklich getrennt habe und diese auch laut Eintragung in der XML getrennt sind. Die Hauptarten (Brahman bzw,. Europa-Kühe bleiben allerdings getrennt. Bin mir auch nicht sicher, ob die (Ver-)Mischung der Kühe nicht ein Giants Problem ist, da ich nicht weiss, ob die Definition von Dir in der Animation / Weidenbereich eingestellt werden kann.
Beide Fehler sind allerdings nicht weiter wild - wollte es nur mitteilen, falls Du nochmal über das Pack schaust...
VG
Andre
Hallo DecanKane ,
habe mir Deine Map mal angeschaut - echt klasse, was Du da geschaffen hast. Da kann man mal große Maschinen ausgiebig testen.
Zwei kleine Fehler sind mir bei der Map noch aufgefallen - hoffe dass dies hier der Supportthread ist.
1. Fehler in Feld 5:
Schwierigkeitstufe Mittel (einfach neues Savegame erstellt / genutzt.
Wenn Du bei Feld 5 in den südlichen Bereich zur "Land-Insel" gehst, dann hast Du nördlich von der Insel einen Bereich, welcher von Feld 9 stammt. D.h. da findest Du einen Bereich mit Kartoffeln, obwohl auf Feld5 keine Kartoffeln angebaut sind.
Der Bereich ist von beiden Feldern belegt - wenn Du daher auf Feld 5 arbeitest, siehst Du das eventuell nicht gleich. Daher (falls Du die Stelle nicht findest, gib mal folgende Befehle in dieser Reihenfolge in der Console ein:
gsSetFieldFruit 5 wheat 1 plow 3 1 1 1 1
gsSetFieldFruit 9 potato 7 plow 3 1 1 1 1Durch die Befehle setzt Du erst auf Feld5 Weizen an, Status "gesäht" mit voller Düngestufe etc.
Anschließend das gleiche mit Kartoffeln auf Feld 9 mit Erntestatus ("Kraut entfernen")...
Wenn Du nun anschließend die Minimap mittels ESC öffnest und auf Wachstum wechselst, findest Du im grünen Feld 5 mit Wachstumsstufe 1 ein rotes Viereck mit Wachstumsstufe 7... Wenn Du dort hingehst, findest Du auch den doppelt belegten Bereich - Setzt Du den ersten Befehl für Feld 5 erneut, dann wird der Bereich erneut überschrieben mit Weizenansaat....
2. Fehler - im Norden zwischen Farmhaus Richtung Feld 2 (Richtung Westen).
Bin dort langgelaufen, man kommt dort an einen Teich. Da bin ich dann als Fußgänger "hineingefallen" - d.h. war auf einmal "unter der Karte". Ist man erst mal da drin, kommt man nicht mehr heraus... Es sei denn man tabbt in ein Fahrzeug hinein...
VG
Andre
... und zum Abladen die normale Funktion zum Abladen (Standardtaste: i) nutzen, nicht "Hier abladen" Funktion mittels STRG+i.
Danke für die Info und das Bild @gunthaa . Das macht es verständlich. Mit dem Unterschied zw. GE und "Live" Bild meinst Du sicherlich das LOD Unschärfesystem, was die Bauteile beim Livebild im Hintergrund unschärfer macht und damit weniger Polys berechnet werden müssen. Denn sonst habe ich keine direkten Unterschiede erkennen können.
Aktuell steht ein 4-Zylinder im Werk
Bei dem Traktor sieht man sehr gut, dass der Schriftzug direkt als Modell auf- /angebracht wurde. Dadurch kommt das ganze vor allem bei Screenshots etc. sehr gut zum tragen und sieht sicherlich besser aus, als wenn mit einer entsprechenden Textur / Bumpmapping etc. gearbeitet wurde.
Stellt sich mir nur die Frage, in wieweit dies ggf. im Spiel evtl. aufgrund der durchzuführenden Berechnungen dann zu Performanceproblemen führen kann, wenn man mehrere Fahrzeuge und andere Objekte im Sichtbereich hat. 
P.S. Soll aber keine Kritik an Deiner Arbeit sein, nur eine Überlegung hinsichtlich Useability.
Ich bin derzeit auf der Hofbrunn (V1.9) unterwegs, eine etwas angepaßte Steinbrunn mit ein paar netten Gimmicks / Details, welche sich sicherlich auch gut in eine Geschichte integrieren lassen.
Direktdüngung.... ob es das mal als Mod geben wird? 
Ich würde ganz pragmatisch mit der Fehlersuche umgehen und folgende Tests durchführen:
1. Tritt das Problem nur im Multiplayer auf, d.h. was passiert bei gleicher Map + gleichen Mods installiert in einem Single-Player Spiel?
2. Tritt das Problem mit gleichen Mods bei Verwendung einer Standard-Map auf? Funktioniert es hier im Multiplayer, oder nur im Singleplayer?
3. Tritt das Problem auf Deiner gewünschten Map beim Spielen ohne weitere Mods (ausser CP als Mod) bei Deiner Karte im Multiplayer auf? Funktioniert es ohne weitere Mods im Singleplayer?
Sind also insgesamt 5 Testläufe um festzustellen, ob es am CP selbst, am Multiplayer, an der genutzten Map oder an anderen Mods liegt. Ohne die bei diesen Tests erzielten Ergebnisse und ohne Log.txt bleibt es nur beim Glaskugelraten.
Die Erkennung zur Generierung von Kursen kann man mit der Dreschersuche nicht vergleichen. Zur Erschaffung von Kursen wird "einfach" der Feldrand genutzt und anschließend "stur" mathematische Formeln verwendet, um die Fahrlinien zu berechnen. Bei der Drescher-Findung hingegen wird versucht, ein Areal mittels Raycast auszuwerten, um festzustellen, ob sich in diesem Areal ein Fahrzeug vom Typ Drescher befindet. In Deinem Fall erkennt CP einfach nicht, dass der Drescher sich im gleichen Feld (Areal) befindet wie der Abfahrer.
Um das genauer zu verdeutlichen, mal ein Beispiel, was ich "aus Faulheit" häufiger nutze - funktioniert sowohl in LS17 als auch in LS19. Ich habe 2 Felder, sagen wir mal Feld 1 und Feld2, welche durch einen breiten "Grasstreifen" von einander getrennt und als separate Felder auch definiert sind.
Beim Pflügen der beiden Felder muss ich nun für das Pflügen CP das Feld für den Rechner angeben. CP erkennt den jeweiligen Feldrand, berechnet die Bahnen und die Fahrzeugkombi fährt diese dann stur ab.
Nun das Gegenstück - Dreschen. Ich fahre nur den Abfahrerkurs für Feld 1 ein. Hier definiere ich kein Feld, sondern fahre nur so, dass das Ende des Kurses innerhalb von Feld 1 liegt. An dem Punkt (Kursende) wo der Abfahrer anhält, versucht CP nun ständig festzustellen, auf welchem Gebiet sich der Abfahrer aktuell befindet und ob sich ein Drescher im gleichen Areal aufhält. Diese Erkennung wird so lange durchgeführt, bis man dem Abfahrer mitteilt, dass er wieder seinen definierten Abfahrkurs fahren soll. Also wie gesagt, Abfahrkurs für Feld 1 erstellt - keinen für Feld 2. Auf beiden Feldern fahren nun Drescher - sowohl auf Feld 1 und auf Feld 2. Den Abfahrermodus stelle ich so ein, dass dieser "am nächsten passenden Wegpunkt" weiterarbeitet, also nicht "am aktuellen Wegpunkt" oder gar "am ersten Wegpunkt" - das ist wichtig, weil darüber entschieden wird, ob CP den Erkennungsmodus abschaltet und stur einen festen Wegpunkt sucht.
Nachdem der Abfahrer am Kursende angekommen ist und in den Erkennungs- oder Suchmodus wechselt, schalte ich CP für diesen Abfahrer ab und fahre ihn einfach in Feld2. Dort schalte ich den Abfahrermodus wieder ein. Die Erkennung (Dreschersuche) wird wieder aktiviert, der eigentliche Abfahrtkurs ist völlig egal. Bei korrekter Definition der Felder und automatischer Dreschersuche wird der Abfahrer jetzt einen der auf Feld2 befindlichen Drescher finden und entladen, bis er seinen definierten Füllstand erreicht hat. Was auf Feld 1 passiert, interessiert diesen Abfahrer bis zur Abfahrt nicht mehr. Ist der Abfahrer voll, sucht er den ersten, eigentlich den 2. Abfahrerpunkt und berechnet die kürzeste Wegstrecke dahin. Er fährt diesen an und folgt dem Kurs. Nach dem Abladen fährt er dann wieder auf Feld 1, da dort der Kurs endet und wird nun wieder im Feld 1 Areal nach einem Drescher suchen. Somit brauche ich keinen separaten Abfahrerkurs für Feld2 einzufahren.... Ich muss nur sicherstellen, dass der Startpunkt des Abfahrerkurses an einer Stelle liegt, der von jedem Punkt beider Felder auf direktem Weg ohne Hindernisse erreicht werden kann.
Ich hoffe, ich konnte das Verhalten verständlich rüberbringen. Es geht also beim Abfahrer nicht über Feldgrenzen / Feldränder, sondern um eine Areal-Erkennung vom aktuellen Abfahrer und ob sich der Drescher im gleichen Areal befindet. Wird von CP nicht erkannt, dass es sich um das gleiche Areal handelt, dann kann der Drescher nicht gefunden werden - egal ob Du den Drescher automatisch zuweist, oder manuell auswählst. Dies kann durch fehlerhafte Felddefinition passieren, durch einen Bug in der verwendeten CP Version, oder auch durch andere (i.d.Regel Fahrzeug-) Mods, welche eingesetzt werden, auch wenn diese nur im Spiel vorhanden und nicht aktuell von CP gesteuert werden, also alles, was die Arealerkennung stört.
Was wird denn im CP Menü unten angezeigt, wenn der Abfahrer auf dem Feld ankommt und dort ein paar Sekunden / 1 Minute wartet... Immer noch "kein Drescher in der Nähe", oder "warten bis Füllstand erreicht"?
Was passiert, wenn Du den Endpunkt der Route weiter mehr ins Feld hinein packst oder mal testweise an eine andere Seite?
Was passiert, wenn der Abfahrer am Endpunkt der Route wartet, Du dann CP für diesen Abfahrer disablest, ihn weiter in die Feldmitte fährst und dann wieder CP aktivierst? Dann müsste er ohne zu wahren wieder mit der Erkennung beginnen...
Ich kenne die Marschen leider nicht, aber ich hatte mal so ein Problem in zwei Ausprägungen auf einer anderen Map.
Bei einem Feld lag es daran, dass der Mapper ungenau gearbeitet hatte und man, obwohl laut visuellem Eindruck auf dem Feld man tatsächlich neben dem Feld wartete... daher keine Erkennung. Im zweiten Fall lag es an einem aus zwei Feldern per Pflug zusammengelegten Feld. Hier dachte CP man wäre auf Feld 1 - der Drescher war aber im ehemaligen Feld 2....
Wäre mal ein paar Tests wert.
@gunthaa Erst mal Danke - ich hatte das nicht gefunden und kannte es nur von ein paar Maps, wo es fest verbaut war.
@RubberDuck76 : Ja, hast Recht, da steckt viel mehr drin, als nur das reine Auffüllen - mit Infos / Dialog etc.
Mir schwebt da eher eine "Basisvariante" vor, welche man ggf. als eigenen placeable mod bauen könnte. Es zeigt auf den Wassertrog und hat einen "erweiterten" Triggerradius, damit der - sagen wir mal "Wasserbedarfs-Trigger" (Filltrigger des aktuellen Troges im Triggerbereich) erkannt und bei Bedarf und geöffnetem Absperrventil bedient wird. Also als Typ eine "BuyingStationPlaceable", mit eingebauter "HandTool" Funktionalität, so wie es in der Wasserstation für den LS19 für Fahrzeuge umgesetzt ist.
Oder geht dies nicht, da der manuell zu aktivierende "Verfügbarkeit-Trigger" des möglichen Mods gar nicht mit dem Bedarfstrigger der Tränke zusammenarbeiten kann?
Edit: Oder sollte ich die Frage eher bei LSMC stellen, da die beiden Erbauer - sowohl Water Trough Addon von GTX als auch Hasco für die Wasserstation dort zugange sind?
Edit2: Habe die Frage jetzt mal bei den Machern der beiden Erbauer der Ausgangsmods im LSMC Forum gestellt, werde Euch dann hier auch über das Ergebnis informieren. Ist ja hier mein "Homebase" Forum, wo ich i.d.R. als einziges Forum neue Beiträge eröffne.
Hallo zusammen,
habe da eine Idee / Frage, da ich nicht weiß, ob das generell möglich ist.
Im LS17 gab es auf manchen Maps verbaute Tiertränken, welche entweder per Wassertransport (Standardmethode) befüllt werden konnten, aber auch ein Wasserrohr / Wasserhahnanschluß hatten. Somit konnte man an dem "Wasserhahn" Trigger einfach den Hahn aufdrehen und die Tränke wurde befüllt. Nach der Befüllung wurde das Absperrventil automatisch wieder abgedreht / geschlossen. Ich weiß aber jetzt nicht, ob dazu ein spezielles Script genutzt wurde.
Nun gibt es ja im LS19 bereits Mods für den Wassertransport (als Tank dargestellt), wo man zur Entnahme von Wasser ebenfalls einen Wasserhahn aufdrehen muss (Trigger). Daher stellt sich mir die Frage:
Wäre es möglich, ohne zusätzliches Script einen Wasserhahn Mod zu erstellen? Die Idee ist, dass man diesen ohne Collis erstellt, sodass er überall platzierbar ist. Als Modell ein Rohr was aus dem Boden kommt und dann wie ein umgedrehtes "U" gebogen wird, d.h. mit dem Ende wieder nach unten zeigt. Daran ein Absperrventil (-rad), welches einen Trigger zum An- und Abschalten hat. Wenn man nun diesen Mod an einer Tränke verbaut und die Tiere brauchen Wasser, dann hingehen und den Trigger aktivieren - es "fließt" Wasser aus dem Rohr in die Tränke. Ist die Tränke voll, wird das ja durch den Trigger signalisiert und die Befüllung stoppt, d.h. das Absperrventil wird geschlossen. Alternativ dazu kann man das Absperrventil auch vorher manuell schließen.
Die Frage ist nur, ist sowas möglich? Oder braucht dies ein extra Script? Wäre doch sicher eine nette Idee für die Modder und universell bei allen Ställen einsetzbar, oder?
VG
Andre
Die eine Warnung kommt von der Map: Farmland-Ids not set for all pixel in farmland-infoLayer!
Die Warnung "Raw audio format" für die Datei cpClickSound.wav kommt von Courseplay, weil sie noch eine unkomprimierte WAV Datei für das Klicken im CP Dialogmenü verwenden. Kann ignoriert werden.
Die anderen zahlreichen Warnungen bzgl. aiCollisionTrigger sind definitiv von Courseplay, sie kommen beim Kauf / Konfiguration / Verkauf von Fahrzeugen im Shop oder in der Werkstatt, da dabei die Trigger gesetzt bzw. entfernt werden. Werden in die Log geschrieben, weil CP diese in der Developerversion in der Log notiert, können aber ignoriert werden.
mcweis : Lass ihn doch erst mal - das wird schon. Bei Lea und Jim im LS17 ging der Text / die Story am Anfang auch "nur" als Beiwerk durch, um die Bilder zu erklären. Nun, nach ein paar Monaten - ist die Story im Vordergrund und die Bilder unterstützen diese. Sowas braucht Zeit, Übung, Phantasie und Talent... daher wird die Story hier noch etwas brauchen, aber auch das wird - da bin ich mir sicher. Sind halt schon ziemlich verwöhnte Leser hier. 
JoHu31 : Nicht aufgeben... das wird schon.
Lea Torash Hast Recht - mir ging es darum, wie es im wahren Leben gemacht wird, da sich das Spiel ja daran orientieren sollte. Werde mal schauen und es im Spiel etwas umstellen (also erst nach dem Pflügen Kalk ausbringen). Beim Säen verwende ich i.d.R. eh die Condor15001, welche gleichzeitig grubbert und säht. Ist meine Lieblings-Sämaschine.
ja - nur ist Google Earth noch zu ungenau... es gibt genaueres Kartenmaterial in 1' (1 Minute Bogengrad) Auflösung (bei Google waren es bisher immer 3'). Und noch genaueres bei den Landesämtern, dort allerdings in einem Format, für welches man nur schwer passende Bearbeitungstools bekommt.
Ja, mir geht es wirklich um die Größe der "Spielwelt", also wäre dass dann ggf. 2x2 km, wenn die Angaben von mcweis korrekt sind. Hat damit zu tun, dass ich mir das mal genauer anschauen möchte mit realen Daten, um reale, passende Höhenkarten zu erstellen oder ein TUT dafür zu machen. Es gibt ja genügend Material dazu, ist halt dann nur eine Sache, wie genau man das Thema beleuchtet. Mit entsprechend realen Höhendaten könnte man beim korrekten Verhältnis die Karte so vorbelegen, dass sogar die Straßen zur Original-Welt passen, ansonsten wären die dann bei einer falschen Angabe halt zu schmal oder zu breit...