Posts by Eric

    Herzlichen Glückwunsch, [Mitarbeiter.GetFirstName]!


    Da Sie die Leistungsziele durchweg erreicht oder übertroffen und sowohl von Ihrem Vorgesetzten als auch von Ihren Kollegen gute Noten erhalten haben, wurden Sie für eine Kündigung zum Ende dieses Quartals ausgewählt! Ihr Opfer wird von uns allen hier bei Dodacorp™ sehr geschätzt, und wir sind glücklich, Sie gehen zu sehen!


    Ihr Vorgesetzter wird sich mit Ihnen in Verbindung setzen um Ihnen Anweisungen im Zusammenhang mit Abfindungszahlungen, der Neuzuweisung Ihrer Dodacorp™ Ruhestandsguthaben an Ihre nächsten Angehörigen und den notwendigen Papierkram für die von Ihnen gewünschten Vorkehrungen für die Zeit nach der Beendigung des Arbeitsverhältnisses zu geben. Als geschätztes Mitglied von Dodacorp™ denken Sie daran, dass Sie bei unseren Partnern unter Burnatech™ einen Mitarbeiterrabatt auf Kremationsdienstleistungen erhalten, und vergessen Sie nicht, dass Sie Ihre ergänzende Ewige Interment™ Urne bei unserer Tochtergesellschaft Repositrexx™ beanspruchen können.


    Fragen Sie Ihren Vorgesetzten nach einem Platz für Ihre Urne an der Wand von Honor™, die begehrtesten Plätze sind schnell vergeben!


    Bitte stellen Sie sicher, dass Sie alle erforderlichen Formulare bis zum ersten von [Mitarbeiter.Kündigungsdatum.Vormonat] ausfüllen, damit Sie diese aufregende Gelegenheit nicht verpassen.


    Wir möchten Ihnen nochmals für Ihren Dienst hier auf Dodacorp™ danken und schätzen es sehr, dass Ihr heutiges Opfer morgen zu Rekordgewinnen führen wird!


    Hochachtungsvoll,

    [Angestellter.Abteilung.Vorgesetzter.VollständigerName]

    [Angestellter.Abteilung.Vorgesetzter.GetFullJobTitle]



    ---


    Inspiriert von der extremen Popularität der Sunset Invasion von CK2 setzen wir unsere Erforschung der Sterblichkeit mit zwei weiteren Zivilisationen, die wir für eine bevorstehende Veröffentlichung planen, fort, dem Todeskult und dem Corporate Death Cult.


    Staatselement Totenkult - leider dürfen die Kuratoren nicht heimlich ein Totenkult sein


    Staatselement Corporate Death Cult - Ritualmord für Kapital und Propheten


    Reiche, die den spiritistischen Imperien zur Verfügung stehen, ersetzen die Tempel, die Spiritualisten normalerweise errichten können, durch Opfertempel, die sowohl dem Todespriester als auch dem Sterblichen Initiierten Arbeitsplätze bieten.


    Gebäude des Opfertempels - lustig, wie immer ein "Hilfe gesucht"- Schild im Fenster zu stehen scheint.


    Death-Priester-Job - der Verbesserung der Spiel-Preformance gewidmet.


    Sterblicher Einstiegsjob - die Vorteile sind zum Sterben schön


    Todeskulte, bei denen die Positionen der Initiierten Sterblichen besetzt sind, erhalten Zugang zu drei neuen Opfer-Edikte mit denen sie das rituelle Gemetzel an den Göttern (oder an welche Kraft auch immer, an die die Päpste Eures Reiches glauben) durchführen können. Sie sind zwar etwas wankelmütig und die Größenordnung der Vorteile variiert, aber je mehr Blut vergossen wird, desto wahrscheinlicher ist es, dass Ihr die besseren Segnungen erhaltet.


    Opfern: Zusammengehörigkeitsedikt - Erinnern wir uns an die guten Zeiten, die wir zusammen hatten


    Opfern: Harmonie-Erlass - Sie können endlich den Eckschreibtisch und den roten Hefter bekommen, den Sie wollten.


    Opfern: Kopfgeld-Erlass - das ist wie eine freiwillige Säuberung, bei der man nicht von der Galaktischen Gemeinschaft beschimpft wird


    Opfern: Zusammengehörigkeit und Aufopferung: Harmonie haben jeweils eine Grundkosten von 50 Einfluss, Opfer: Kopfgeld kostet eine Basiskosten von 100 Einfluss. Diese werden, wie üblich, durch Dinge modifiziert, die sich auf die Kosten des Ediktes auswirken (wie z.B. der Spiritualisten-Modifikator).


    Wenn das Opfer gebracht wird, werden die Sterbepriester Euch darüber informieren, wie es vom Göttlichen empfangen wurde.


    Opfern: Harmonie - hätte mehr Opfertempel bauen sollen, das sind Anfängerzahlen


    Obwohl es sich um Gesellschaften handelt, in denen es um Ritualmord (und den Witz der Sunset Invasion) geht, soll das Thema dieses Staatselements ein Thema der freiwilligen Opfer sein, bei dem die Opfer geschätzt und geehrt werden. Als solches ist es nicht offen für fanatische Reiniger, die wahrscheinlich eine... äh... aggressivere Politik betreiben würden.


    Ich weiß, dass ich letzte Woche gesagt habe, dass wir versuchen würden, einen Blick auf das Leben in der Mishar Cabal zu werfen, aber sie haben den Journalisten, der sie interviewen sollte beiseite geschoben, nachdem sie "zu viel gesehen haben". Wir werden sehen, was wir bald über sie berichten können.


    Nächste Woche werden wir enthüllen was sich unter dem verschwommenen Text im Todeskult der Bürgerschaft verbirgt, und vielleicht sogar JEFF treffen.


    Quelle: https://forum.paradoxplaza.com…e-of-termination.1421077/


    Die Aufgaben zu Tauchfahrten haben bei mir immer markierte Stellen. Oft sind es drei/vier Stellen im Meer welche mit dem üblichen gelben Doppelpfeil gekennzeichnet sind. Insofern kann ich da wenig weiterhelfen. Dein Tauchboot hat aber auch die notwendigen Items gesockelt, also Sonar usw.?

    Die Chronicle Drone Unit-W3 fegte über den Platz, wie sie es seit ihrer Gründung alle zehn Tage tat. Davor hatte Einheit-V3, bis ein Stück bröckelndes Mauerwerk sie unter Tonnen von Trümmern zermalmte, diese Aufgabe übernommen. Die erste Aufgabe der Einheit-W3 bestand darin, diese Trümmer zu beseitigen.


    Der Mollarnock-Commonwealth war einst ein mächtiges Imperium mit einem Dutzend Planeten, das von den glitzernden Türmen seiner Ökumenopolis-Hauptstadt Azure Chalice aus regiert wurde. Der Chardin-Prozess schuf den Direktor, ein Gestaltbewusstsein, das die vielen Maschinendiener der Mollarnock-Region koordinieren konnte. Sie schufteten damit ihre Mollarnock-Meister ihre Zeit mit Kunst, Wissenschaft und Philosophie verbringen konnten.


    Aber alle Dinge vergehen.


    Die Kolonien waren während des Entdeckungskrieges zerstört worden, von einem unversöhnlichen Feind in radioaktive Trümmer verwandelt. Um ihrem Feind den ersehnten Sieg zu verwehren und ihn daran zu hindern, das Juwel des Reiches zu erobern, beschloss Kanzler Rhosen, die Dinge auf eigene Faust zu beenden und setzte eine schreckliche Biowaffe frei, die den Azure Chalice für Jahrhunderte unbewohnbar machte.



    Die Jahrhunderte vergingen.


    Die Chardin Mechanicals sammelten die Toten ein und bestatteten sie in den Heiligtümern von Repose. Ihr Kampf um den Erhalt des Planeten war bewundernswert, aber dem Untergang geweiht - Plünderung, Umnutzung und Neuzuweisung von Materialien konnten nur so viel bewirken. Ohne einen Strom von Ressourcen, die aus den Kolonien kamen verloren sie den Kampf, den Planeten vor dem Verfall zu bewahren.


    Ein Programm zur Rückkehr zu den Sternen, die einst von ihren Schöpfern kontrolliert wurden, wurde begonnen.


    Die Mollarnock mögen sich vor vierhundertsiebenundachtzig Jahren selbst zerstört haben, aber sie würden nie vergessen werden.


    ---


    Stellaris ist voller Geschichten - einige, die wir Euch erzählen, aber so viele mehr, die Ihr uns erzählt und die sich aus dem Spielverlauf ergeben.


    Dies ist die Geschichte der Mollarnock, die von einem schrecklichen Feind zerstört und von denen, die zurückgelassen wurden.


    Memorialist ist ein neues Staatselement welches wir Euch in einem zukünftigen Release vorstellen wollen. Im Gegensatz zu vielen anderen aktuellen Staatselementen wird es für reguläre, Maschinen- und Schwarm-Imperien verfügbar sein.





    Maschinen-Imperium Memorialist


    Reguläres Imperium Memorialist


    Schwarm-Imperium Memorialist


    Dem Gedenken an die Gefallenen und der Erforschung der Unausweichlichkeit des Todes gewidmet, ersetzen die Memorialisten das Autochthon-Monument-Set durch eine andere Reihe von Gebäuden: das Heiligtum der Repose, die Säule des Quietus und das Galaktische Denkmal. Diese Gebäude bieten Stabilitäts- und Chronistenarbeitsplätze, mit zusätzlichen Vorteilen für Reliquien- oder Grabwelten. (Anziehungskraft der Regierungsethik für normale Reiche und Verringerung der Abweichungen für Gestalten).


    Gestalt-Memorialisten können eine etwas andere und philosophischere Sicht auf den Tod haben und versuchen, die Natur von etwas zu lernen, das sie nicht wirklich verstehen können.


    Heiligtum des Repose-Gebäudes – Gestalt


    Heiligtum des Repose-Gebäudes – Normal


    Säule des Quietus-Gebäudes – Gestalt


    Säule des Quietus-Gebäudes – Normal


    Galaktisches Gedenkgebäude – Gestalt


    Galaktisches Gedenkgebäude – Normal


    Solche flache Stabilitätsschübe sind extrem selten, insbesondere in Gestalt-Imperien. Die zusätzlichen Vorteile auf Reliquien- und Tote Welten geben dem Ganzen noch ein bisschen mehr Würze.


    Chronicle Drone Job (Maschine - die Schwarm-Version ist ähnlich, verbraucht aber Nahrung oder Mineralien, je nach Bedarf).


    Todes-Chronist Job



    Memorialisten (auch Gestalt) werden auch feststellen, dass sie gelegentlich Zugang zu feierlicheren Anworten (wie sie manchmal auf Spiritualisten beschränkt sind) auf bestimmte Ereignisse haben, die sich während des Spiels ereignen, was es vielleicht für diejenigen attraktiv macht, die ein Rollenspiel in einem freundlicheren (wenn auch nicht unbedingt sanfteren) Bienenstock spielen möchten. Ich würde empfehlen, Memorialist und Empath zu kombinieren, um maximale Leichtigkeit zu erreichen.


    Nächste Woche werden wir sehen, wie weit eine Megacorp gehen wird, um ihre Profite zu maximieren und auch einen Blick in das Leben in der Mishar Cabal zu werfen.


    ---


    Chardin war der Name des Wissenschaftlers, mit dem ich als Verantwortlicher für die ingenieurwissenschaftliche Forschung begann, als ich den Mollarnock-Commonwealth schaffte und so die ganze Anerkennung für den Chardin-Prozess erhielt.


    Quelle: https://forum.paradoxplaza.com…emory-allocation.1420989/

    Nun ja, merkwürdig ist es schon das es bisher keine neue Nachricht kam. ;(Nun kann ich nicht sagen was da früher bei Facebook stand, allerdings hat er früher auch schon für EA gearbeitet. Kann natürlich sein das EA ihn abgeworben hat und damit das Projekt bei Ubisoft gestoppt ist. Oder er hat seinen Teil der Arbeit erledigt und ist nun wieder bei EA. Ich bin mal Optimist, Ubisoft will sich mit Siedler keine eigene Konkurrenz schaffen. Anno 1800 läuft ja wunderbar und die Zielgruppe von Siedler sind auch die Anno Spieler, im Prinzip ist es die gleiche Zielgruppe. Ich denke mal, wenn die Spielerzahlen in Anno 1800 sinken, nicht doch noch irgendwie ein Season Pass 3 kommt, dann geht es mit Siedler weiter.

    Und wer ist hier so am Zocken?

    Momentan bin ich noch mit Wasteland 3 beschäftigt. Ich muss mich arg zusammenreißen mir nicht noch CK3 zuzulegen, allerdings juckt es mir ganz arg in den Fingern. Momentan schaue ich nur die Videos von Steinwallen. Anderseits habe ich noch Imperator: Rome auf meiner Festplatte und selbst dieses Spiel auch nur 50 Stunden gespielt. Ich befürchte aber, irgendwann werde ich schwach. :engel6234:

    Ich habe mir letztes Jahr einen neuen Rechner mit einer 2080Ti gekauft. Für die Spiele, welche ich derzeit zocke, reicht die vollkommen aus.

    Hi everyone! I am Caligula, one of Stellaris’ Content Designers, which means that I do a variety of tasks based around narrative writing and scripting - “scripting” being our term for doing things that is somewhat similar to programming, but without changing the source code. In other words, I do what modders do (though I have the significant advantage of also being able to peek into the source code and change it around when needed). Every Content Designer has their niche, and mine is that when a particularly complicated system needs to be scripted in (or, more frequently, is giving some sort of trouble - the War in Heaven still gives me nightmares...), I step into the breach.


    Now, we have a lot of exciting stuff to show off in the weeks and months to come, but for today, inspired by some questions that were asked after the last dev diary, I’m going to be writing about the technical side of scripting for modders and aspiring modders, specifically with an eye on what can cause performance problems and how to avoid making bad scripts.


    The Stellaris scripting language is a very powerful tool, and a lot can be done with it, but first of all, a note of caution: just because something is possible, does not mean it should be done. I can’t really stress this enough, because (and I speak from experience here) this attitude will almost certainly end up causing both performance issues and unreadable scripts that you will not be able to disentangle six months later when you realise some part of it is broken. Though it should be borne in mind that doing something in code is, by definition, faster: in code, you can check a single function and be done with it, but if you want it to be accessible through script, there’s a fair few necessary functions it has to go through before you get to checking your function (turning the line of script into a code command, checking whether it’s used in the right scope, etc etc) - hence why some things are hardcoded, and also why hacky solutions to problems can end up being quite bad. So, the first question to consider is, should I really be doing this?


    But who am I kidding, I’m speaking to modders here, so of course you will do it :D So without further ado...


    What causes performance issues?


    Every time you run a check or execute an effect, this will take a very tiny amount of your computer’s processing power. With a few exceptions that should be used sparingly (I’ll get to those later), this is totally fine and is needed to do anything at all. It is when the check is repeated often, over lots of objects, that problems happen. In practice, this usually means pops are the cause, though running something across all planets in the galaxy is also a pretty bad idea.


    As a first step, when possible, it is a good idea to control when your script is run. The best way to do this is by setting where events are fired and using on_actions (or firing events from decisions and the like) wherever possible, instead of mean time to happen or, even worse, just setting an event to try and fire every day. If a degree of randomness is needed, one could also fire a hidden event via, say, a yearly pulse and then firing the actual event you want with a random delay (for an example, check out event action.220).


    Of course, not everything is events, and unfortunately, in Stellaris, a lot of stuff is done with pops! Job weights and other triggers in the jobs files, in particular, have been shown to cause issues in the past. As a rule of thumb, even if you can do super cool stuff, it is a bad idea to do any too complicated script pyromania on jobs. For example, if you were to make a job weight dependent on there being no other pops on the planet that are unemployed (using planet = { any_owned_pop = { is_unemployed = yes } }), then you are doing a regular check on every pop on the planet that then checks every other pop on the planet, i.e. pops squared. Once you reach the late game, this is pretty much guaranteed to cause issues.


    So what can be done?


    Avoiding nested loops, making sure your events are fired appropriately and avoiding pops when possible will get you some way, but we can do better than that. Here is my list of advice for optimising scripts:


    Always use the most appropriate scope


    Say you want to check something on the leader of the current country’s federation. One could, theoretically, do it this way:


    Code:

    any_country = {

    is_in_federation_with = root

    is_federation_leader = yes

    <my_triggers_here> = yes

    }

    This'll run through all countries in the game and see whether they are in the same federation as you, including the space amoeba country and the vile Pasharti (and who would want them in a federation?). That’s a bunch that are definitely irrelevant. So a better check would be to do it this way:


    Code:

    any_federation_ally = {

    is_federation_leader = yes

    <my_triggers_here> = yes

    }

    In code terms, this means that the game going from the country to the federation and then grabbing a list of its members, excluding the current country, and checking the triggers against them. So, that’s obviously going to be fewer checks. However, the best version would be this:


    Code:

    federation.leader = {

    <my_triggers_here> = yes

    }

    That version would go straight to the federation and from there straight to its leader in the code, with as little as possible script to code conversion needed and no need to check triggers against any countries to get there. It also happens to be the most readable (readability and better performance very often correlate…).


    So in this case, the game would check around 50 countries first the first version, 5 for the second and 1 for the third - not bad for some optimisations! Using a similar logic, it is always better to use something that isn’t checking all objects in the galaxy (esp. all pops or all planets) if at all possible but rather a filtered list, e.g. any_planet_within_border instead of any_planet = { solar_system.owner = { is_same_value = prevprev } } (you laugh, but I’ve seen it). And, indeed, one can almost always check any_owned_fleet instead of any_owned_ship.


    Another important improvement we added in 2.6 was any_owned_species, which can replace many any_owned_pop checks (specifically the ones that check for traits and so on of the pop) and mean that way, way fewer objects have to be checked (in a xenophobic empire, it could be single figures for any_owned_species and thousands for any_owned_pop).


    Sometimes you can avoid scopes completely


    On a similar note, if you can check something without doing things with scopes, that’s always going to be better. So, if one wants to check whether a planet has more than two pops working as miners, one could do this two ways:


    Code:

    count_owned_pop = {

    count > 2

    limit = {

    has_job = miner

    }

    }


    Code:

    num_assigned_jobs = {

    job = miner

    value >= 2

    }

    The former will check each pop on the planet and see whether it has the miner job, and then see whether the number that do is higher than 2. The latter will check a cached number that the game has already calculated and see if it is more than 2, which is much quicker to do.


    Some things are just expensive


    Not every check or effect is equal. Checking a flag or a value is generally pretty simple, and changing it is usually not much more complicated. If, however, the game has to recalculate stuff, then it will take longer, because it’s not just looking up a number it already knows. Creating new stuff is also more expensive, both because it’s doing something somewhat complicated (the create_species effect is, I kid you not, more than 600 lines of C++ code...), and because it’ll probably have to recalculate all sorts of values once this is done. It can be a bit tricky to know which triggers and effects are going to be bad, but as a rule, these cases are what you should look out for:

    Anything where you are creating a new scope e.g. create_country, create_species, modify_species

    Anything that needs you to calculate or recalculate pathfinding (e.g. can_access_system trigger, creating new hyperlanes, especially creating new systems)

    Anything that calculates pops (changing around pop jobs on a planet, for instance)


    If it must be done...


    Sometimes, bad things must be done. In these cases, it is best to still use the not so great things with precision. When the game is checking triggers e.g. for an event, it’ll generally stop checking them at the first point something returns false (I’m told this is called “short-circuit evaluation”), so you’ll want to do something like this:


    Code:

    trigger = {

    has_country_flag = flag_that_narrows_things_down_loads

    <something really horrible here>

    }

    I recently did something like this to the refugee pop effect. It was previously a little bit insane (see 01_scripted_triggers_refugees.txt for the full horror). In total, it would check a variation of the following up to eight times:


    Code:

    any_relation = {

    is_country_type = default

    has_communications = prev #relations include countries that have made first contact but not established comms

    NOT = { has_policy_flag = refugees_not_allowed }

    prevprev = { #this ensures Pop scope, as root will not always be pop scope

    OR = {

    has_citizenship_type = { type = citizenship_full country = prev }

    has_citizenship_type = { type = citizenship_caste_system country = prev }

    AND = {

    has_citizenship_type = { type = citizenship_limited country = prev }

    has_citizenship_type = { type = citizenship_caste_system_limited country = prev }

    prev = { has_policy_flag = refugees_allowed }

    }

    }

    }

    any_owned_planet = {

    is_under_colonization = no

    is_controlled_by = owner

    has_orbital_bombardment = no

    }

    }

    Where it varied was simply the last any_owned_planet: It would try and find a relation with a really good planet for the pop to live on, then a pretty good, then a pretty decent, and then finally settle for just any old planet. Which is, obviously, pretty inefficient, since the list of countries that welcome refugees does not change between each of the 8 times you check it. My way of avoiding this - and making the script way more readable, whilst I was at it - was to set a flag before any of the checks, like this:

    Code:

    every_relation = {

    limit = {

    has_any_habitability = yes #bare minimum for being a refugee destination

    }

    set_country_flag = valid_refugee_destination_for_@event_target:refugee_pop

    }

    The checks then simply had to be “does the country have the flag, if yes, does it have a good enough planet”:


    Code:

    has_good_habitability_and_housing = {

    has_country_flag = valid_refugee_destination_for_@event_target:refugee_pop

    any_owned_planet = {

    habitability = { who = event_target:refugee_pop value >= 0.7 }

    free_housing >= 1

    is_under_colonization = no

    is_controlled_by = owner

    has_orbital_bombardment = no

    }

    }

    One can also similarly use if-limits and elses (and, even better, switches when possible - those are the best for performance) in triggers to narrow down the checks down and make things far more readable whilst you are at it. I recently went through the species rights files and redid the allow triggers for sanity’s sake:


    (Before)


    Code:

    custom_tooltip = {

    fail_text = MACHINE_SPECIES_NOT_MACHINE

    OR = {

    has_trait = trait_mechanical

    has_trait = trait_machine_unit

    from = { has_valid_civic = civic_machine_assimilator }

    }

    }

    custom_tooltip = {

    fail_text = ASSIMILATOR_SPECIES_NOT_CYBORG

    OR = {

    NOT = { from = { has_valid_civic = civic_machine_assimilator } }

    AND = {

    OR = {

    has_trait = trait_cybernetic

    has_trait = trait_machine_unit

    has_trait = trait_mechanical

    }

    from = { has_valid_civic = civic_machine_assimilator }

    }

    }

    }

    (After)


    Code:

    if = {

    limit = {

    from = { NOT = { has_valid_civic = civic_machine_assimilator } }

    }

    custom_tooltip = {

    fail_text = MACHINE_SPECIES_NOT_MACHINE

    OR = {

    has_trait = trait_mechanical

    has_trait = trait_machine_unit

    }

    }

    }

    else = {

    custom_tooltip = {

    fail_text = ASSIMILATOR_SPECIES_NOT_CYBORG

    OR = {

    has_trait = trait_cybernetic

    has_trait = trait_machine_unit

    has_trait = trait_mechanical

    }

    }

    }

    The second version will be more efficient, since it is only checking e.g. whether the species has the mechanical trait or whether the country has the assimilator civic once instead of twice, and also, the triggers in the second custom tooltip aren’t obscenely weird anymore. (I also removed all the NANDs, because they broke my brain).


    Happy New Year


    I can’t write this dev diary without telling you about the “Happy New Year” bug. Basically, we were playing dev MP on a reasonably large galaxy and reached reasonably late into the game, and since we were all working remotely on wildly varying computers and internet connection speeds, the performance was perhaps a tad sluggish, but still acceptable for the most part. Then, suddenly, we noticed huge lag spikes - 20 seconds and more - on the 1st of January. So noticeable were these spikes that we began wishing each other a Happy New Year each time the game froze!


    It just so happened that the onset of this lag coincided with several large empires deciding to become synthetic and starting to assimilating their empires. Now, assimilation falls into the category of things that are done in script that maybe, in hindsight, should probably not have been done that way… and works by firing an event for each assimilating country every 1st of January. This event in turn fired an event for each of their planets that selected a bunch of pops on the planet and used modify_species on each of them at least once, but sometimes up to four times. This added up to a fairly significant performance hog!


    After trying various solutions, it turned out the best way to fix this was to first go through every_owned_species from the country scope, check whether this species should be assimilated, and if so use modify_species to create the species it would assimilate to, setting a species flag that pointed to the species it was being assimilated from. Then, instead of creating a new species for every pop that was assimilated, the scripts were rewritten to find the already-created species that the pop should become, and simply use change_species on it. The result is still unreadable script (I will spare your eyes and not post it here), but in my tests it reduced the yearly tick by over 50%, thanks to the complicated effect (modify_species) being run as seldom as possible.


    ---


    That’s it for me, for now! I’m guessing this was a bit of a drier dev diary than usual for most of you, but hopefully it was interesting nonetheless :) As a final note, I suspect that the more intrepid among you could call me out on bits of script in the base game that don’t quite live up to these guidelines. Please, feel free to do so, because there are few things more satisfying in this profession than taking something really horrible and making something less horrible out of it!


    Quelle: https://forum.paradoxplaza.com…ow-to-avoid-them.1416409/

    Aber ich bin für meinen Teil im Spiel irgendwo angekommen wo fast alles entdeckt ist. Besucher brauch ich nicht mehr, Expeditionen fallen weg und die Weltausstellung ist auch uninteressant. Die Arktis läuft von alleine, die neue Welt eigentlich auch, da gibt es hin und wieder mal Schönheitskorrekturen und die alte Welt ist eigentlich nicht besiedelt.

    Nun ja, mir geht es etwas ähnlich. Crown Falls ist fast ausgebaut, allerdings fehlen da noch Verschönerungen für Zoo, Museum und Botanischen Garten. Expeditionen sind, dank der Great Eastern und passenden Items, mittlerweile ein Selbstläufer, ebenso die Weltausstellung. Arktis ist noch nicht voll ausgebaut, da habe ich bislang nur ein Plateau besiedelt. Fehlt noch? Die Alte Welt mit meiner Startinsel. Die Will ich auch noch komplett ausbauen und dort ebenfalls eine Weltausstellung aufbauen, ebenso Zoo, Museum und Botanischer Garten da ich da etliche Items doppelt habe. Ich selbst spiele Anno auch nicht mehr jeden Tag und mittlerweile gibt es auch Pausen wo ich mal ein anderes Spiel dazwischen schiebe. Ende Juli/Anfang August habe ich auch sehr intensiv gespielt, allerdings nicht mit meinem regulären Spielstand. Jetzt pausiert es etwas, jetzt muss ich mal das eiskalte Colorado in Wasteland 3 erkunden, allerdings werde ich zu 100% wieder zu Anno zurück kehren. Momentan überlege ich nur ob ich nochmals einen neuen Spielstand anfange oder meinen vorhandenen fortsetze.


    Marcel wurde gestern im Stream gefragt weswegen sie sich gegen ein Addon und sich dafür für die verschiedenen Season-Pässe entschieden haben. Zusammengefasst hat er gesagt das die heutige Zeit eben sehr schnelllebig ist, es immer permanent neue Spiele, Filme usw. gibt. Wenn jetzt ein Addon erst ein Jahr später erscheint birgt es die Gefahr das schon viele Spieler abgesprungen sind. Mit den Season-Pässen ist es ihnen möglich die Spieler über eine lange Zeit am Spiel zu halten da eben regelmäßig neue Inhalte kommen.


    Was einen dritten Season-Pass betrifft bin ich eben der Meinung das er einige Spieler auf Grund der zunehmenden Komplexität sicher überfordern wird. Dies ist auch im öffentlichen Forum so geschrieben. Einige Hardcore-Spieler würden sich über einen dritten Pass freuen, anderen Spielern wäre dies zu viel. Persönlich würde ich mich aber über einen dritten Season-Pass freuen, besonders wenn es dann nach China geht. Prinzessin Qing liefert dazu ja die passende Vorlage. ;))


    Aber erstmal geht es in das Land der Löwen und dies wird ..... :censored: ... schaut dann selbst. :pfeiffen645:

    Nu ja ... da schreibe ich extra einen Beitrag was es Neues gibt und "tata" ... dann gibt es auch schon einen neuen Beitrag in der Anno-Union zum Update 9 ... ;)) Im Prinzip steht nun alles nochmals, schön beschrieben, im Blog. Viel Spaß beim Lesen ... :lesen634:

    ^


    Ein dritter Season pass weiß ich nichtmal ob ich das möchte also noch mehr Karten würden es glaube ich vollends zu komplex machen.

    Ist auch meine Meinung, habe ich auch mal so im öffentlichen Forum geschrieben. Es ist ja jetzt schon recht komplex, mit Land der Löwen wird sicher auch noch einiges dazu kommen und da bin ich mir auch unsicher ob ein dritter Season Pass nicht alles sprengen würde.

    So, ich habe mir mal heute den Stream angeschaut ... zu Land der Löwen wurde leider nichts gezeigt. Nur soviel: Update 9 und "Land der Löwen" soll im Oktober erscheinen. Ansonsten wurde sehr viel zum Update 9 gezeigt, da kommen einige sehr schöne Komfortverbesserungen. :juhuu53:


    • Bei der Weltausstellung kann man sich zukünftig die Kiste aussuchen welche man haben will und bekommt nicht mehr automatisch die höchste Kiste genommen.
    • Die Zeitung kann man jetzt einmal editieren und dann auf Auto-Publishing stellen. Dann werden zukünftige Ausgaben mit den Einstellungen immer wieder veröffentlicht. Man muss also in Zukunft die Zeitung nicht immer wieder neu editieren.
    • Besucher im Besucherhafen werden jetzt bei Meldung angezeigt, man kann diese annehmen ohne zum jeweiligen Hafen zu springen. Man kann auch einstellen das man nur die Meldung bekommt und die Besucher automatisch angenommen werden.
    • Im Kontor wird es eine Suchfunktion für Items geben. Man muss sich also nicht mehr durch alle Items wühlen und kann gezielt nach speziellen Items suchen.
    • Die Item-Auswahl bei den NPC wurde auf 12 Items erhöht.
    • Ruinen kann man in Zukunft mit der Taste J suchen. Einmal auf J gedrückt springt man automatisch zu der Ruine.
    • Wenn man Schiffe in eine andere Session schickt kann man gezielt den Hafen angeben wohin das Schiff fahren soll.
    • Wenn ein Handelsschiff versenkt wurde bekommt man jetzt eine Meldung, dies wird dann auch im Handelsmenü extra angezeigt.
    • Wenn man ein Schiff einer Handelsroute zuweisen möchte kann man sich jetzt die Schiffe im Hadelsmenü anzeigen lassen. Es werden Ladung, Items und der Ort wo sich das Schiff befindet angezeigt.
    • Mit Mausklick und Strg auf ein Schiff im Handelsmenü springt man automatisch zum Schiff.

    Dies mal zur groben Übersicht, ich denke in der Anno-Union wird es dazu noch Beiträge geben. Ansonsten kann ich auch nochmals was schreiben wenn das Update veröffentlicht wird.


    Interessant war die Frage, oder die Antwort auf die Frage, ob es noch einen dritten Season Pass geben wird. Marcel meinte nur das man derzeit auf Land der Löwen fokussiert ist und sich keine Gedanken über die Zukunft macht. Im Forum hat er auf selbige Frage schon einmal mit einem klaren "Nein" geantwortet, heute klang es eher so das man sich dies nun doch noch offen hält. Schauen wir mal ...