Latest Posts

Topic: Einstellungen Soldaten

Dillinger76
Avatar
Topic Opener
Joined: 2018-01-07, 20:01
Posts: 37
OS: macOS Big Sur (Version 11.7.10 (20G1427))
Version: 1.2 daily
Ranking
Pry about Widelands
Location: Ellwangen
Posted at: 2023-12-31, 13:44

Hallo zusammen,

eine generelle Frage zu den Wirtschaftseinstellungen bzgl. der Soldaten - hier ist standardmäßig "10" eingestellt. Heißt das, dass 10 Soldaten sich in den Lagerhäusern aufhalten wenn alle Militärgebäude (je nach Einstellung voll) besetzt sind?

Sollte meine Kaserne immer aktiv sein? Ich habe bisher immer die Anzahl der Soldaten in den Wirtschaftseinstellungen auf 100 hochgeschraubt und nach einer gewissen Anzahl von Soldaten im Bestand die Kaserne gestoppt.

Ich habe bei meinem aktuellen Spiel das Problem, dass ich viele fast voll ausgebildete Soldaten habe, die ständig zwischen Lagerhäusern und (3) Ausbildungslagern hin und herlaufen. Dabei werden diese nur sehr schleppend besser. Mache ich generell etwas falsch?

Danke, Grüße und einen guten Rutsch ins neue Jahr, Dillinger


Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 17:07
Posts: 2005
OS: Debian Testing
Version: Latest master
Ranking
One Elder of Players
Location: 0x55555d3a34c0
Posted at: 2023-12-31, 15:42

Eine Einstellung von 10 bedeutet, dass sich nach Besetzung aller Militär- und Ausbildungsgebäude und ggf Kriegsschiffe noch mindestens 10 Soldaten in den Lagerhäusern aufhalten sollen. Falls du einen der Naval Warfare Builds benutzt, werden Soldaten in Garnisonen dabei nicht mitgerechnet.

Sollte meine Kaserne immer aktiv sein? Ich habe bisher immer die Anzahl der Soldaten in den Wirtschaftseinstellungen auf 100 hochgeschraubt und nach einer gewissen Anzahl von Soldaten im Bestand die Kaserne gestoppt.

Eigentlich nicht sinnvoll, du erzielst das gleiche Verhalten viel einfacher indem du die Wirtschaftseinstellung direkt auf die gewünschte Zielanzahl hochsetzt und die Kaserne normal laufen lässt.

Ich habe bei meinem aktuellen Spiel das Problem, dass ich viele fast voll ausgebildete Soldaten habe, die ständig zwischen Lagerhäusern und (3) Ausbildungslagern hin und herlaufen. Dabei werden diese nur sehr schleppend besser. Mache ich generell etwas falsch?

Anscheinend stehen nicht genug Waren für die letzten paar Upgrades zur Verfügung, vermutlich weil Gold mangelt.


Top Quote
Dillinger76
Avatar
Topic Opener
Joined: 2018-01-07, 20:01
Posts: 37
OS: macOS Big Sur (Version 11.7.10 (20G1427))
Version: 1.2 daily
Ranking
Pry about Widelands
Location: Ellwangen
Posted at: 2024-01-01, 18:19

Hi Nordfriese,

zunächst mal ein gutes neues Jahr und danke für deine Antworten.

Zum letzten Punkt: Ich hatte ausreichend Gold(barren) und Eisen(erz) - gegen Ende des Spiels ging es dann etwas schneller, dass die Soldaten fertig ausgebildet wurden. Ich hab nur nicht genau verstanden warum es sich zuvor "etwas komisch" verhalten hatte.

Viele Grüße, Dillinger


Top Quote
Teayo
Avatar
Joined: 2015-03-09, 21:11
Posts: 182
OS: Windows 11 Home 64-bit
Version: 1.2 from Juni (06) 2023
Ranking
Widelands-Forum-Junkie
Location: Deutschland
Posted at: 2024-08-13, 00:37

Ich habe ein paar Fragen und Anregungen zu den Soldaten Allgemein :

Fragen

  • Soldaten haben eine Anzeige über sich die anzeigt wie hoch Ihr Gesundheitslevel aktuell ist ,
    sowie welche Ausbildungslevel in den Bereichen "Leben" , "Ausweichen" , "Verteidigung" und "Angriff" der Soldat hat .
    Diese Status Anzeige kann man mit der Taste "L" einblenden und ausblenden .
    Die Bilder für die Anzeige welches Ausbildungslevel der Soldat in den verschiedenen Bereichen hat , sind auf die Größe 10px * 10px normiert .
    Gilt diese Normierung der Größe auf 10px * 10px für die Anzeige welches Ausbildungslevel der Soldat hat , für die Zoomstufe 1 ?
    Derzeit gibt nur Bilder für die Zoomstufe 1 . Sind Bilder für die anderen Zoomstufen ( 0.5 , 2 , 4 ) valide und können von der Engine genutzt werden ,
    wenn die Bilder im Namen entsprechend deklariert sind oder führt das zu einer Fehlermeldung ?
    Ich könnte dies selber herausfinden , jedoch bin ich momentan und auch noch für einige Zeit ( mehrere Wochen ) nicht an den Punkt angekommen ,
    das dies mir als wo mögliche Fehlermeldung ausgegeben werden könnte , da vorher andere Fehlermeldungen mir angezeigt werden .

    Für den Fall das Ausbildungslevel Bilder für Soldaten für verschiedene Zoomstufen valide sind , folgend die entsprechend sich daraus ergebenen Bild Größen :
0.5 =  5px *  5px
  1 = 10px * 10px
  2 = 20px * 20px
  4 = 40px * 40px
  • Mit der Taste "X" kann man sich die Übersicht zum Armee Ausbildungsstand einblenden oder ausblenden lassen .
    Wenn man vom Reiter "Per Attribut" zum Reiter "Übersicht (\"Variable\")" wechselt wo alle möglichen Ausbildungslevel Kombinationen angezeigt werden ,
    kann man einsehen wie viele Soldaten sich in den jeweiligen Ausbildungslevel Kombination momentan befinden .
    Führt diese Darstellung aller möglichen Ausbildungslevel Kombinationen ab einer bestimmten Anzahl von möglichen Kombinationen nicht zu Darstellungsproblemen ?
    Also angenommen ein Soldat kann 16-mal trainiert werden , je 4-mal pro Trainingskategorie , von denen es immer genau 4 gibt .
    Dies würde doch den Fensterrahmen locker sprengen , sowohl in der Breite als auch in der Tiefe .
    Gibt es momentan irgendwelche Schutzmechanismen die eine vernünftige Darstellung garantieren ?
    Oder geht man davon aus das Soldaten im allgemeinen nicht mehr als 12-mal insgesamt trainiert werden können ,
    was je nach Verteilung innerhalb der Trainingskategorien zu einer noch mehr oder weniger vernünftigen Darstellung führt ?

    Bei der Erweiterung Europäer (EN) von MarkMcWire mit der der Stamm der Europäer hinzugefügt wird , gibt es ja schon die obig beschriebene mildere Form ,
    mit insgesamt 12 Trainings pro Soldat , gleichmäßig verteilt auf alle 4 vorhandenen Trainingskategorien , pro Trainingskategorie je 3 Ausbildungslevel .
    Das Übersichtsfenster ist schon sehr groß aber wird noch vernünftig dargestellt . Im Fall der Europäer
    für Zeilen horizontal : ( (3+1) * (3+1) = 16 ) { Angreifen - Ausweichen } ,
    für Zeilen vertikal : ( (3+1) * (3+1) = 16 ) {Verteidigung - Leben } was insgesamt ( 16 * 16 = 256 ) Ausbildungskombinationen ergibt .

    Im Fall 2
    für Zeilen horizontal : ( (4+1) * (4+1) = 25 ) { Angreifen - Ausweichen } ,
    für Zeilen vertikal : ( (4+1) * (4+1) = 25 ) {Verteidigung - Leben } was insgesamt ( 25 * 25 = 625 ) Ausbildungskombinationen ergibt .

  • Bei manchen Bilddateien liegt eine Indizierte Ebene vor , neben der Transparents Ebene .
    Wenn man die Indizierte Ebene (Hintergrundfarbe) nicht entsprechend zurück rausrechnet bei der Umwandlung von Indiziert-RGBA zu RGBA ,
    dann entstehen im Bild an einigen Stellen teilweise transparente Pixel , die dann die Hintergrundfarbe der darunterliegenden Ebene übernehmen
    und so dafür sorgen dass das resultierende Bild , wenn das Bild als Ebene in ein anderes Bild eingefügt wird , vom ursprünglichen Indizierten-RGBA Bild abweicht .
    Aus welchen Grund wurde diese Indizierung vorgenommen und warum nur bei manchen Bildern ?
    Der für mich naheliegendste Grund wäre das dadurch die Bilddatei Größe noch etwas reduziert werden kann , im Vergleich zu nicht Indiziert abgespeicherten PNG-Bildern .

Anregungen

  • Punkt 1 : In wie fern lässt sich etwas an der Einheit "constructionsite" (Gebäude Baustelle und Gebäude Abrissstelle) am Verhalten hinzufügen , bezüglich :
    im folgenden geht es nur um die Gebäude Baustelle , wenn Ware_A konsumiert wird , um den Baufortschritt am später resultierenden Gebäude zu erhöhen ,
    das dann nach Zeit_B (Diese wird aktuell schon automatisch definiert und hängt nur von der Gesamtanzahl von Waren ,
    die für den Bau des später resultierenden Gebäudes benötigt werden , ab) (Wenn eine Ware konsumiert wurde , die Zeitspanne bis die nächste Ware konsumiert wird)
    die Ware_B produziert wird und der Bauarbeiter nach dem produzieren die produzierte Ware_B aus der Baustelle herausträgt , zur mit der Baustelle verbunden Fahne
    und dann dort die produzierte Ware_B ablegt . So wie es aktuell schon bei der Gebäude Abrissstelle funktioniert .
    Dies betrifft die Tabellen "buildcost" und "enhancement_cost" :
...
buildcost=
{
    empire_ware_planks=4,
    empire_ware_granite=2,
    empire_ware_rope=-1
},
...
  • (Fortsetzung von Punkt 1) Diese Art der Umsetzung wäre wohl eine Variante mit einen eher geringeren Aufwand , Problem hier :
    Es kann nicht definiert werden , das Ware_B erst dann produziert wird , nachdem Ware_A konsumiert wurde .
    Zudem könnte diese Art der Umsetzung Probleme bei der automatischen Berechnung der Zeitspanne zwischen dem konsumieren der Waren und der %-Anzeige des Baufortschritts verursachen .
    Dieses Problem könnte man durch eine weitere Tabelle lösen :
...
buildcost=
{
    empire_ware_planks=4,
    empire_ware_granite=2
},
produce_when_build=
{
    empire_ware_planks=empire_ware_rope
},
...
  • (Fortsetzung von Punkt 1) Eine im Vergleich zur obrigen Umsetzungs-Variante , Variante mit wohl einen noch geringeren Aufwand wäre :
...
buildcost=
{
    empire_ware_planks=4,
    empire_ware_granite=2
},
produce_after_construction_finished=
{
    empire_ware_rope=4
},
...
  • (Fortsetzung von Punkt 1) Diese zuletzt mit dem Beispielcode beschriebene Variante würde ich klar präferieren .
    Führt aber ohne das ich es überprüft habe mit 100%-tiger Wahrscheinlichkeit aktuell zu einer Fehlermeldung , "das dieses Argument unbekannt sei" ,
    weshalb ich es durch Auskommentierung schon im voraus deaktiviert habe .
    Eine Herangehensweise die ich bereits ausprobiert habe , war mit "programms" ohne Erfolg da man kein Programm definieren kann , das nur einmal aufgerufen wird .
    Entweder wenn das Gebäude einen Fehlschlag erleidet , weil zum Beispiel eine Eingangs Ware fehlt oder wenn das Ende des "versuchten Schleifenprogramms"
    (Damit gemeint : main={call=a,call=b} , a={produce einmalig} , b={call=c,call=c,call=c, und weitere 128 Zeilen ... } , c={consume und produce normal} ) erreicht ist ,
    wird das Programm was nur einmalig aufgerufen werden soll , wieder aufgerufen .

  • Punkt 2 : Ich würde es für sinnvoll und logisch halten und daher präferieren wenn Gebäude-Einheiten des Typs "trainingsites"
    künftig auch die Eigenschaft "heal_per_second" haben müssen .
    Momentan haben nur Gebäude-Einheiten des Typs "militarysites" und "warehouses" diese Eigenschaft .

  • Punkt 3 : Wie sehen die Pläne für die Strukturierung von Bilddateien für Soldaten Varianten aus ?
    Aktuell befinden sich alle Bilddatein zum Soldaten im gleichen Ordner wie die init.lua Definitionsdatei .
    Sollten in Zukunft mal Bestrebungen aufkommen die Möglichkeit zu eröffnen , das auf Animations-Varianten zurückgegriffen wird , in Abhängigkeit von dem Ausbildungsstand des Soldaten ,
    wie sollen dann die Bilddatei Namen normiert sein ? Wenn ich mir das jetzt schon so vorstelle , würde der Ordner an Bilddateien explodieren und es würde sehr unübersichtlich werden .
    Dann sollten die Bilddateien für die Animations-Varianten in Unterordnern sich befinden , damit es nicht so unübersichtlich wird .
    Ein Vorschlag von mir zur Datei und Ordnerstruktur:
soldier=
{
    init.lua
    register.lua
    attack_level_indicator=
    {
        attack_level_0_0.5.png , attack_level_0_1.png , attack_level_0_2.png , ...
        attack_level_1_0.5.png , attack_level_1_1.png , ...
        ...
    },
    defense_level_indicator=
    {
        ...
    },
    evade_level_indicator={...},
    health_level_indicator={...},
    generic= oder default_style=
    -- Wenn für die beim Soldat vorhandene Ausbildungslevel Kombination keine Animations-Variante vorhanden ist
    -- Sowie für ein Soldat der noch nicht ausgebildet wurde
    {
        idle_0.5.png , idle_1.png , idle_2.png , idle_4.png ,
        walk_e_0.5.png , ...
        ...
    },
    attack_4_defense_0_evade_2_health_4= oder variant_a4_d0_e2_h4= oder variant_4024= 
    -- Animationen die für einen Soldaten genutzt werden sollen der die im Ordnernamen beschriebene Ausbildungslevel Kombination hat
    {
        idle_0.5.png , ...
        ...
    },
    ...
}

Ah kleine Rechnung noch für mich selbst :
[ 1 bis 3 ] | [ 256 bis 625 ] *
(
  ( 1 * ( idle 4 + 4pc ) ) +
  ( 6 * ( walk 4 + 4pc ) ) +
  ( 2 bis 6 * ( attack_ok 4 + 4pc ) ) +
  ( 2 bis 6 * ( attack_fail 4 + 4pc ) ) +
  ( 2 bis 6 * ( evade_ok 4 + 4pc ) ) +
  ( 2 bis 6 * ( evade_fail 4 + 4pc ) ) +
  ( 2 bis 6 * ( die 4 + 4pc ) )
)
  1_default_             east_west_   case =     136 PNGs | ~    3MiB (  3,31MiB inklusive der Level Indikatoren und lua --Amazonen )
  1_default_             directional_ case =     296 PNGs | ~  6,5MiB ( ~   7MiB inklusive Rest )
  2_rookie_hero_         east_west_   case =     272 PNGs | ~    6MiB ( ~ 6,5MiB )
  2_rookie_hero_         directional_ case =     592 PNGs | ~   13MiB ( ~13,5MiB )
  3_rookie_default_hero_ east_west_   case =     408 PNGs | ~    9MiB ( ~ 9,5MiB )
  3_rookie_default_hero_ directional_ case =     888 PNGs | ~ 19,5MiB ( ~  20MiB )
256_all_variants_        east_west_   case =  34.816 PNGs | ~  769MiB
256_all_variants_        directional_ case =  75.776 PNGs | ~ 1,68GiB
625_all_variants_        east_west_   case =  85.000 PNGs | ~ 1,88GiB
625_all_variants_        directional_ case = 185.000 PNGs | ~    4GiB | * 6 Stämme = 24,5GiB -- Vollkommen bekloppt

  • (Fortsetzung von Punkt 3) Meine Intention dahinter : Das ein maximal ausgebildeter Soldat , kurz ein Held , anders aussieht ,
    als die nicht maximal ausgebildeten Soldaten und gleichzeitig schonmal eine Normierung / Struktur vorzuschlagen die gleich die Möglichkeit gibt ,
    wenn man ganz ganz ganz viel Zeit hat , die Animations-Varianten für alle anderen Ausbildungslevel Kombinationen zu hinterlegen .
    Ich habe nicht vor Animations-Varianten für die Soldaten hinzuzufügen , das wäre ein Fass ohne Boden und von daher halte ich von dieser doch ganz netten Idee einen großen Abstand .
    Allerdings möchte ich dies zumindest mal niedergeschrieben haben , bevor es wieder in Vergessenheit gerät .
    Ist praktisch im Vergleich zu den anderen Punkten nur heiße Luft , wo von mir auch keine Intention dahinter steckt .
    Den die anderen Punkte von mir , haben einen konkreten Grund , im Vergleich zu diesen letzten Punkt .

    Nach meiner Rechnung sehe ich das dieses Konzept sehr schnell in den illusorischen Wahnsinn führt .
    Vielleicht ist da eine Lösung mit der Engine via übereinander gelegte Ebenen doch besser .

Das Imperium schlägt zurück ! TY

Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 17:07
Posts: 2005
OS: Debian Testing
Version: Latest master
Ranking
One Elder of Players
Location: 0x55555d3a34c0
Posted at: 2024-08-13, 08:35

Nach den ersten paar Absätzen hab ich aufgehört zu lesen… bitte, mach für jede Frage jeweils einen neuen Thread auf.

  • Bilddateien werden mit PNGQuant und anderen Tools optimiert, um ihre Größe zu reduzieren, was in der Regel Indizierung beinhaltet. Bilder, die bereits nicht weiter optimiert werden können, werden übersprungen. Das hat in der Transition von v1.0 zu v1.1 die Downloadgröße von Widelands um fast 400 MB (!) reduziert.

  • Die meisten Bilder außer den Einheitenanimationen sind derzeit nicht skalierbar. Grund ist dass das für jede einzelne Verwendung in C++ separat und individuell angepasst werden muss. Das ist z.B. schon für die Bauhilfe getan worden.

  • Das detaillierte Übersichtsfenster mit Taste X ist nur benutzbar, wenn das jeweilige Volk einigermaßen »typische« Levelhöchstwerte hat.

  • Schau mal in die Definition der Einheitengraphiken zum friesischen Soldaten.


Top Quote