Topic: Wie krieg ich Waren in das Schiff????????????????

Hallo an alle, die die Lösung wissen :-),

ich habe einen Hafen gebaut und eine Werft. Die Werft hat gerade ein Schiff gebaut und jetzt baut sie das nächste.Kann eigentlich sein, dass wenn die Werft gerade ein Schiff baut und kein Material hat, das Schiff auch wieder kaputtgeht (die % werden weniger, das Schiff wird kleiner?) Find ich,( wenn es so gedacht wäre) ziehmlich blöd. Aber jetzt zu meiner eigentlicher Frage: Wie krieg ich Waren und Arbeiter in das Schiff???????????????????

Danke schonmal.

Ego non stultus sum;sed ingentem ingenium habeo.

Top

Quote

wl-zocker wrote:

Es gibt zwei Möglichkeiten:

• Du brauchst zwei Häfen im gleichen Gewässer (auf "konventionelle" Art zu bauen). Dann zerstörst du alle Straßen zwischen den Häfen (einen lässt du mit deiner Wirtschaft verbunden). Wenn du jetzt am anderen Hafen etwas baust, werden die benötigten Waren per Schiff transportiert (funktioniert natürlich auch für Betriebe, die dauernd etwas brauchen, z.B. Bäckerei).

Ich hoffe, daß wird noch mal benutzerfreundlicher. Ist unpraktisch, wenn man die Straße zerb0mben muß damit man ein Schiff zu einer Adresse lenken kann.

(geht nur bei Entwickler-Versionen, nicht in build-17) In deinem Hafen klickst du auf "Starte Expedition". Dann werden alle benötigten Waren (das Baumaterial für einen Hafen plus Baumeister) zum Hafen transportiert. Ist alles da, wird ein Schiff gerufen. Dieses kannst du selbstständig steuern und an einer geeigneten Stelle einen Hafen errichten. Zu diesem werden dann wie im ersten Punkt beschrieben Waren transportiert. Klappt aber wie gesagt nicht mit build-17.

An diesen Punkt bin Ich gescheitert. War alles am Start, Schiff schaukelte Nähe Hafen und nix ging weder SP noch MP. Aber gut zu erfahren wie es ausschauen sollte wenn es denn geht. Ich fragte mich schon, ob hier&da noch etwas fehlt.

Eine Möglichkeit, beliebige Waren in das Schiff zu bringen (oder auch Soldaten) gibt es bislang nicht, würde aber auch noch nichts bringen.

Dies wäre bei passender Gelegenheit vll genauer zu erklären. Klingt so iwie irritierend bzw nicht überzeugend. Ich schätze das für einen reellen Nutzen noch ein Feature fehlt auf das du dich indirekt beziehst.

Zum Schiffebauen: Wenn die Werft kein Material mehr bekommt, sinkt ihre Produktivität wie bei allen anderen Gebäuden auch, kann sie arbeiten, steigt die Produktivität. Das Schiff wird meines Wissens nach nicht kleiner (eine Anzeige, die den Fortschritt des Schiffes anzeigt, gibt es noch nicht). Wenn eine bestimmte Zeit lang nichts an einer Schiff-Baustelle gearbeitet wurde, wird diese entfernt (egal wie weit sie ist).

..

Das macht schon Sinn, weil sonst würde z.B. ein halbfertiges feindliches Schiff ewig stören.

Dem kann Ich im Grunde zustimmen, aber wenn das Schiff so wie ein Soldat unabhängig von Construction-Progress noch einen Health-Status hätte, also die HP vom Soldier erbt, dann wäre für ein unfertigtes bzw beschädigtes Schiff eine (höhere) Decay-Rate hilfreich, um ein weniger sprunghaftes Verhalten zu zeigen. Wenn das Schiff unfertig ist, nimmt es schneller Schaden durch Wind&Wetter als wenn es fertig/heile wäre. Dadurch wäre ein plausibleres und auch weniger überraschendes Verschwinden des Schiffes gegeben denn man staunt schon wenn der Kahn weg ist und fragt sich ob der fertiggestellt wurde und gleich losgezogen ist zu neuen Ufern hin oder .... jemand hat den gemopst.

Die Sache mit dem stören kann Ich nach Erinnerung aber so nicht nachvollziehen, denn IIRC verschwand der unfertige Bau mir einmal weil Ich unvorsichtig nahe eine andere Baustelle eröffnete. War vll Zufall und Ich hätte es testen müssen, aber mir schien die ConstructionSite hätte die ShipConstruction einfach so ... schwups. Ich finde es im Prinzip aber schon gut bzw ok denn der Aspekt LifeTime von Units, Sites und Wares macht mir schon etwas Bauchschmerzen, normal aber bei mir für Spiele --- kenne kaum ein Spiel in dem nicht roher Fisch 1000 Jahre und länger haltbar ist weil das Zeug keine LifeTime erhalten hat und weiß wie man schimmelt und dergleichen. Ist schon witzig wenn iwo lange Fisch in der Sonne liegt und hundert Jahre später schon konsomiert wird. Bei Fisch klingt es iwie sehr witzig aber trifft auch auf andere Lebensmittel wie Mehl und Brot zu - sogar Wein ist nicht unbegrenzt haltbar.

Ich sage daher pro LimitedLifeTime für Biologische Erzeugnisse und ähnlich auch für Abiotische Erzeugnisse wie Schiff oder Site, aber so wie man eine Baustelle abreissen bzw abbrennen lassen kann (funzt sogar bei steinernen Gebäuden) wäre diese Option auch für Schiffe aus Holz verständlich, und darum betrachte Ich dieses Verhalten als erste Decay-Implementation für das Schiff bzw der SchiffsConstruction, welche das bereits erklärte Decay-Verhalten aufweist, aber wie erklärt auch verbesserungsfähig ist. Die Sache mit Decay ist: Ohne HP kann das Schiff nicht verfallen sondern nur tod umfallen oder aber rückwärts wachsen .. also an Substanz verlieren. Auch letzteres wäre als spezielles Decay für Sites/Ships in der BauPhase für den Spieler transparenter, wahrnehmbarer als es ihm hinterrücks einfach wegzuzaubern weil es ohne Vorwarnung einfach tod umgefallen ist. Ich erinnere mich auch in diesen Zusamenhang, an das SchiffsWrack -HQ (ohne HQ-Features), welches als gescheiterter SchiffsBau für den Spieler erkennbar eine Leiche hinterlassen würde. Die Sache mit schwups-weg ist sub-optimal für den Spieler. Ich würde keine zweite Klasse für "totes Schiff" nehmen sondern der gleichen beibringen todzusein um Probleme mit Referenzen zu vermeiden bzw das Handling zu vereinfachen. Das tote Schiff braucht einfach keine RohStoffe mehr zum WeiterBau und der WeiterBau läuft ohne Bedarf eines Wright nun von selbst gegen Null und wenn abgelaufen verschwindet es bis vll auf einen Rest der wie diese RiesenMuscheln solange verbleibt bis überbaut wurde oder ähnliches. Ich meine damit: wenn man nur noch einen Schatten im Sand finden kann und man mit dem MausZeiger drauf klickt muß da nit mehr QueenMary-II draufstehen sondern da ist nix mehr außer einen Schatten. Ein halbverfallenes Schiff mag ja noch traurig seinen vorgesehenen Namen nennen. Nun ja.. nun bin Ich schon beim GrabSchmuck und das Schiff steht noch bei Schrödingers Katze und wenn man nicht nachguckt fault es noch immer -- oder auch nicht - wer weiß das schon so genau, aber wenn man nachschaut ist es entweder noch da und kann weitergebaut werden oder es ist verschwunden.

Vielleicht könnte man kontrollieren, ob der Spieler, dem das Schiff gehört, besiegt ist.

Ich frage mich warum ein Schiff auf anderer Seite der Karte plötzlich Feuer fangen sollte weil iwo anders auf der Map ein Spieler sein Territory verloren hat. Man könnte gleiche auch für die Gebaäude fragen aber wenn man im Spiel ein fremdes Schiff in den Wellen beobachtet und das Schiff urplötzlich Feuer fängt denkt man ... aha: da hat wohl ein Spieler irgendwo auf der Map sein letztes Territorium verloren. Aber iwie schon ein sehr seltsames Bild. Würde das Schiff vll mit Crew iwo an Land gehen und dann rumirren (irgendwie auch ein schräges Verhalten) wäre dies regulärer und würde das Schiff so oder so durch Decay irgendwann versinken, dann wäre das Problem ähnlich gelöst wie mit dem SchiffsBau, und würde ein herrenloses Schiff oder Gebäude erobert werden (können) --- dann würde das den größten Sinn überhaupt machen können. Praktisch wäre hier folgendes einfaches Verhalten wie Ich es in verschiedenen Spielen kennengelernt habe: Eine Side=independent, deren Einheiten bei Kontakt mit einen anderen Seite sich dieser anschließt. Dadurch ergeben sich neue spielerische Möglichkeiten für eine Campaign: man kommt in ein fremdes Dorf (independend) und zack hat man als Spieler ein paar zusätzliche Einheiten, Resourcen und Sites und die Story kann draus was stricken.

Im context Spezial AI-Sides wäre eine AI-Side für Piraten ganz nett, welche Gefahr vom Meer her bedeutet. Gegenwärtig könnten deren Schiffe nur lästig fallen, weil noch kein NavalBattle-Mode exisitiert, aber für die Einführung entsprechender spezieller Sites kein direktes Hindernis. Auch freie KaufMänner wären brauchbar, die Waren an und verkaufen..

Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too.

Top

Quote

wl-zocker wrote: Die Schiffe sind quasi eine Erweiterung des Transportsystems, das bisher über Straßen und Träger lief. Das Spiel entscheidet, welcher Weg schneller ist, und wählt dann diesen. Die einfachste Möglichkeit, einen Transport per Schiff zu erzwingen, ist, die Straßen abzureißen; auch, wenn es dann insgesamt länger dauert. Hast du z.B. einen Fluss und an beiden Ufern einen Hafen, werden die Waren wahrscheinlich per Schiff transportiert, da der Weg über die Straßen dann viel länger wäre.

Finde Ich aus technischer Sicht als BackGround interessant. Ich hoffe es wird noch benutzer-freundlicher.

(geht nur bei Entwickler-Versionen, nicht in build-17) In deinem Hafen klickst du auf "Starte Expedition". Dann werden alle benötigten Waren (das Baumaterial für einen Hafen plus Baumeister) zum Hafen transportiert. Ist alles da, wird ein Schiff gerufen. Dieses kannst du selbstständig steuern und an einer geeigneten Stelle einen Hafen errichten. Zu diesem werden dann wie im ersten Punkt beschrieben Waren transportiert. Klappt aber wie gesagt nicht mit build-17.

Ich habe es in r6729 (Windows) getestet, dort funktioniert alles wunderbar.

das ist eine klare aussage die ich vermisst habe. Es gibt im Djungle wirklich einen Elefanten den man finden kann.

Ich meine allerdings, dass jemand anders schon einmal geschrieben hat, dass es bei ihm nicht ginge (allerdings kann ich den Eintrag nicht finden). Falls du ihn auch nicht findest, schreibe doch einen bug report auf Launchpad.

acc

Eine Möglichkeit, beliebige Waren in das Schiff zu bringen (oder auch Soldaten) gibt es bislang nicht, würde aber auch noch nichts bringen. .... Ich wollte mit diesem Satz nur zum Ausdruck bringen, dass es keine anderen Möglichkeiten gibt, Schiffe fahren zu lassen. Du kannst also nicht zum Spaß Waren einladen und damit rumfahren.

Dazu fällt mir folgender Ansatz ein: Expedition geht! Nun nehmen wir einmal an, der Spieler könnte customized Expeditions definieren, zB 20 Sack Mehl für Mehl-Mission. Dann wäre nur noch das Keep-Verhalten der Missions-Definitions zu regeln, ob man diese Mission quasi from Template ein weiteres mal fahren möchte oder aber nach Gebrauch sobald nicht mehr als Def benötigt und Schiff fährt gedropt werden kann. Als ersten Schritt würde Ich als Expeditions-Alternative anbieten, das Port-Material an einen anderen Port abzuliefern. Ich hoffe die Mission hat die Missions-Ladung nicht als Special-Bit realisiert sondern die Ladung ist regulär als Ladung an Board und nicht als Ladung aber anders.

Ob es je möglich sein wird, "einfach so" Waren zu transportieren, weiß ich nicht. Ein Transport von Soldaten (und dann ein Angriff vom Meer aus) wird es evtl. geben.

Diese Option ist zu verlockend. Das Problem ist IMO daß die Landung bzw Units außerhalb von Territory/Economy/MilitarySite etc Verrengungen erfordert oder aber die zu Grunde liegende Engine wird geändert und bisheriges Verhalten wird nur aufgesetzt als spezialisierendes Rule-Set gehandhabt. ZB Sites brennen nit ohne Eco/Territory ab sondern bleiben stehen per Default und ohne Probleme und erst für Compatiblity-Issues wird vll das alte Behavior aufgesetzt ohne noch zwingend erforderlich zu sein.

Zum Schiffebauen: Wenn die Werft kein Material mehr bekommt, sinkt ihre Produktivität wie bei allen anderen Gebäuden auch, kann sie arbeiten, steigt die Produktivität. Das Schiff wird meines Wissens nach nicht kleiner (eine Anzeige, die den Fortschritt des Schiffes anzeigt, gibt es noch nicht). Wenn eine bestimmte Zeit lang nichts an einer Schiff-Baustelle gearbeitet wurde, wird diese entfernt (egal wie weit sie ist).

In r6729 gibt es inzwischen eine Prozentzahl, die den Fortschitt der Schiffsbaustelle angibt. Ich denke, ein Schiff, an dem nicht gebaut wird, wird nach 210000 Millisekunden (3,5 Minuten) entfernt (wenn ich die conf-Datei richtig deute).

nice to hear

Zum Rest deines Kommentars:
Schiffe sind relativ neu und es bedarf noch vieler Verbesserungen und Einführung neuer Ideen, bis das Feature vollständig entwickelt ist (wenn es das jemals sein wird).

Der iterative Ansatz war mir bekannt und wird auch von mir befürwortet.

Piraten/Seeschlachten/Lebenspunkte und Kaufmänner sind einige dieser Ideen.

Ich hab manchmal eine

Du solltest allerdings nicht vergessen, dass alle Entwickler nur in ihrer Freizeit an Widelands arbeiten, dementsprechend "langsam" werden neue Features eingeführt.

Mir bekannt jedoch muß jedoch von mir nicht (ursächlich) weiter berücksichtigt werden weil mich mich die EntwicklungsGeschwindigkeit (als Folge) auch nicht berührt -- Ich hab als erstes vor Jahren das aktuelle Release mit dem vorherigen Release verglichen hinsichtlich zeitlichen Abstand (stets ca. 1 Jahr) und den Umfang der Neuerungen am ChangeLog abgeschätzt und dieses als Abschätzung für das nächset Release genommen.

(das soll nicht heißen, dass sie nichts erreicht haben - im Gegenteil, das Spiel hat viele Facetten -, sondern dass Neuerungen eben ihrer Zeit bedürfen und so ein Feature nicht "von heute auf morgen" entwickelt wird).

Ich erinnere mich an eine Andekdote bei der verschiedene Software-Haus-Chefs eingeladen wurden bei Xerox, unter anderem MS-Billy und Äpple-Steve, und man auf Basis eines SoftWare-Systems auf SmallTalk basierend den Besuchern eine grapphische Oberfläche präsentierte mit Maus-Steuerung welche diese Besucher sehr beeindruckte und offensichtlich auch sehr inspirierte siehe Windows etc. Es wurde ein Text-Browser im Fenster gezeigt, in dem der Text gescrollt werden konnte aber alles Pixel-weise gerändert wurde. .Einer der Besucher fragte ob man das Scrollen statt Zeilen-weise auch pixel-weise machen könnte. Der Typ der die Präsentation leitete setzte sich kurz an die Konsole des laufenden Systems, schrieb in wenigen Minuten etwas Code und kurz danach ging es schon. Ich möchte die Situationen definitiv nicht vergleichen und selbst wenn es sie theoretisch wären was würde es praktisch helfen - aber klar ist das ein Feature nicht seiner Natur nach Wochen oder Monate benötigen muß nur weil es ein Feature ist. Die Situationen aber sind gewiß nicht vergleichbar und das fängt schon an der SoftWare-Basis an und Smalltalk ist einfach nicht mit C++ vergleichbar hinsichtlich Flexibelität und EntwicklungsGeschwindigkeit. Ebenso könnte umgkehrt C++ mit Assembler vergleichen und sagen ein Assembler-Programmier ist einfach zu langsam. Ich möchte aber weder die Entwickler noch deren eingesetzten Mittel miteinander vergleichen aber ohne zu fragen warum es im einzelnen nicht ebenso schnell ginge wie im oberen Beispiel nur sagen daß es keine NaturKonstante ist wenn ein Feature lange benötigt bis es implementiert wurde. Ich drängel nicht, frage stets nach besser, bemängel nicht die bisherige Leistung nicht im Sinne daß zB nicht genügend Kaffee getrunken wurde oder mehr als 5 Stunden geschlafen anstatt am OpenSource-Projektzu arbeiten, stelle fest daß es ein eher konstante EntwicklungsGeschwindikeit gibt, mache Vorschläge wie etwas nahe der logischen Abhängigkeiten der Problemstellung gelöst werden könnte anstatt zu sagen macht mal iwie so daß die Software zu unvorstellbaren fähig wird, erkläre aus platter/naiver Spieler-Perspektive (ist nicht nachempfunden sondern straight: ich drück auf Button und dann hat es zu gehen - mir egal wie -- kommerzielle Angebote können es ja auch und Verständnis und Toleranz und Kenntnis der SachLage gehen mir tendenziell iwo vorbei troll), und umgekehrt aus strategischer Perspektive der Entwickler, leicht der ZielSetzung dem Spiel mehr SpielSpaß einzubauen, welche Features strategisch vorteilhaft sind um möglichst viel HandlungsSpielRaum im Spiel zu schaffen. Oben zB. die Vorschläge den Expeditions-Code zum Logistic-Code aufzubohren, Crew aufs Schiffs zu nehmen und div Hilfs-Funktionen etc der Engine aufzubürsten um möglichsten eine Kaufmann-AI zu ermöglichen welche die Steuerung seines Schiffs mit einfacher Handels-Strategy welche sinnvollerweise vor allem auf den Vorteil des Kaufmanns selber ausgerichtet sein sollte. Und ein erfolgreicher Kaufmann verkauft übrigens viel und nicht wenig was heißen soll daß der maximale Vorteil für den Kaufmann nicht darin zu finden ist daß er sau-teuer oder sau-billig ist sondern maximalen Gewinn einfährt. Vom Stand-Punkt einer Kaufmann-Gilder-Spieler--AI-Partei ist dieses wirtschaftliche Ziel schwerer zu realisieren, denn auf diesen Code-Level hat man vor allem die Optionen einer Gilde, eines Syndicates, Kartell mit Preisabsprache etc zur Verfügung - etwas was auf Level der einzelnen Kaufmann-AI garnicht zu implementieren wäre außer durch entsprechende Verhaltens-Regeln mit viel DrumHerum um dieses leisten zu können. Oberhalb aber leicht einfach den kalkulierten maximalen Preis der Kaufmänner als minimlen VerkaufsPreis der Kaufmänner zu bestimmen und damit Quasi-Kartell-Arbeit als Programmierer zu implmentieren. Warum auch immer mache aber aber häufig eher kleinere Vorschläge die in eine bestimmte Richtung führen oder führen sollen. ZB halte ich die Carrier-Code-Legacy für suboptimal und würde am ehesten auf den Expeditions-Code losreiten weil er mir derzeit am flexibelsten erscheint aber auch der modernste Teil in der Logistic ist. Dein Hinweis, daß die Schiffe quasi schwimmende WareHouses mit Carrier-Zentral-AI darstellen bereitet mir eher unwohlsein und als Erklärung warum das eine oder andere so schwierig ist ... Ich weiß ja garnicht was Ich sagen soll.. Ich würd die Carrier-Legacy nicht umschmieden sondern komplett kicken anstatt nur iwas drauf aufbauen zu wollen. Ich würd vll als Migrations-Pfad als Interims-Developer-Lösung quasi super-moderne Teleporter-Technik verwenden um quasi ab Site-Flag das Zeug am Carrier-Net zu bypassen um dann die Carrier zu droppen und mehr SpielRaum zu haben um den eigentlichen Carrier-Kram zu erledigen. Normal ist es wenn zB der Schmied seinen Gehilfen losschickt um HolzKohle für die Schmiede zu besorgen und umgekehrt vll auch produzierte Güter zum Kunden auszufahren (WareHouse?). Ich würde also versuchen mit den Schiffen den Carrier-Code zu bypassen und wenn fertig Schiff zurück als neue Carrier-CodeBase verwenden und die Carrier auf Land laufen wie LandSchiffe die nur eine Ware auf einmal transportieren können. Das gegenwärtige Transport-System und die Idle-Chains haben sehr starken Bezug zueinander. Ein wesentliches Problem besteht darin, daß ohne vorstellbarere Einheiten wie zB. Mass in kg oder Volumen in Liter bzw. Tonnen und m³ die Einheit Stück zu abstrakt ist um vernünftige/realistische Proportionen zu überlegen. ZB StoneCutter: Der geht lost zum SteinBruch, pickt mit Meißel etwas am Felsen und wenn er heimkehrt bringt er einen SteinWürfel mit. Zum HausBau wird 1..2 Würfel benötigt. 100 Carrier stehen entlang der Straße, reichen kurz 2 Würfel weiter und dann wird wieder ge-idelt und iwo wird ein großes Gebäude aus den zwei Würfeln errichtet. Solange man die Würfel für abstrakte Dinger erklärt die vll 1000 reelle Steine representieren sollen und woanders vll wieder etwas ganz anderes wie ... Zement muß man sich nit wundern daß es sehr schwer ist die MißProportionen deutlicher zu erkennen. Wenn man aber reallistische Einheiten verwendet so daß man nachrechnen kann und mit realisitischen Zahlen und Erfahrungen vergleichen kann (Moment .. sagtest du Burg mit nur 8 Würfel?) dann fällt es deutlich einfacher als mit den abstrakten Units. Auch das ist ein Grund warum ich für Güter und Worker etc um die einführung physikalischer Properties wie Masse und Volumen bitte, um dadurch es zu erleichtern sinnvollere Settings zu finden. So ein Worker kostet nit mal eine Flasche MineralWasser aber so ein groooßes Schiff kann soviel tragen wie 20 Worker. Ein Worker mit Muskeln trägt 100kg. 20 also 2t. Für ein so großes Schiff sind soweit mir verständlich 2t eher nur HandGepäck als Ladung. Mal ist es eine Maus und mal ein Elefant - aber die Einheit ist stets 1 und darum schwer zu vergleichen und interpretieren. Das Problem ist meiner meinung nach das zuviel versucht wird Features aufzupropfen anstatt sie im grundlegenden Design zu berücksichtigen. Das wäre so als würde man einen Karn mit extrem vielen Schrauben und Platten an einer SpannPlattenWand befästigen wollen und hätte Probleme mit dem Gewicht des Krans und baut dazu 20 externe Stützen an -- leiber anschrauben als wegwerfen.

Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too.

Top

Quote