Beiträge von scumsaecke.de

Gern, kein Problem - es ist ja kein Staatsgeheimnis.

Bitte beachte aber, dass wir das auf unsere Spielweise eingestellt haben. Es müssen also die Spieler und die sonstigen EInstellungen dazu passen. Gerade im PvE bereich ist das Balancing sehr schwierig - man muss zb auf Munitionsdrops oder Materialien zur Muniherstellung sehr achten, damit zwischen Loot und benötigten Loot zum Überleben keine Unbalance eintritt. Will man also den Loot nicht nach oben nehmen und trotzdem eine schwere Welt haben, muss man an den individuellen Loot ran. (was wir ja nun können)

Und so ergibt sich unterm Strich auf jedem Server ein anderes Spielgefühl. Selbst wenn man die Settings komplett 1:1 kopieren würde, wäre es nicht das Gleiche.

Viel Erfolg und auch Glück, dass es für Euch einigermaßen stimmt - wenn ihr weitere Fragen habt, immer her. Es gibt hier viele helfende Schreiber

Grüße
Phil

Moinsi,

derzeit haben wir es so, sind aber ständig am ändern und testen. Seit dem neuen Patch müssen wir wieder nachjustieren.
Es ist in Verbindung mit hohem Schaden (Bei uns x2) ein relativ schweres Setting für die Bunker mit sehr seltenen aber zackigen Horden.

Für unsere serverspezifischen Settings und dem Spielerverhalten (auch wichtig), mMn derzeit das Beste was man mit den Parametern anfangen kann.
Pieper haben wir auch wieder aktiviert - aber wie gesagt, nach letztem Patch muss wieder justiert werden.

scum.EncounterBaseCharacterAmountMultiplier=2.000000
scum.EncounterExtraCharacterPerPlayerMultiplier=1.000000
scum.EncounterExtraCharacterPlayerCapMultiplier=4.000000
scum.EncounterTotalCharactersSpawnedMultiplier=1.000000
scum.EncounterCharacterRespawnTimeMultiplier=4.000000
scum.EncounterCharacterRespawnBatchSizeMultiplier=1.000000
scum.EncounterCharacterAggressiveSpawnChanceOverride=0.100000
scum.EncounterCharacterAINoiseResponseRadiusMultiplier=0.050000
scum.EncounterHordeGroupBaseCharacterAmountMultiplier=1.300000
scum.EncounterHordeGroupExtraCharacterPerPlayerMultiplier=1.000000
scum.EncounterHordeGroupExtraCharacterPlayerCapMultiplier=2.000000
scum.EncounterHordeBaseCharacterAmountMultiplier=2.500000
scum.EncounterHordeExtraCharacterPerPlayerMultiplier=1.000000
scum.EncounterHordeExtraCharacterPlayerCapMultiplier=3.000000
scum.EncounterHordeActivationChanceMultiplier=0.020000
scum.EncounterHordeNoiseCheckCooldownMultiplier=1.500000
scum.EncounterHordeSpawnDistanceMultiplier=6.600000
scum.EncounterHordeGroupRefillTimeMultiplier=1.500000
scum.EncounterCanRemoveLowPriorityCharacters=0
scum.EncounterCanClampCharacterNumWhenOutOfResources=0
scum.PuppetsCanOpenDoors=1
scum.PuppetsCanVaultWindows=1

Parameter wie batch sizes würde ich nicht anfassen

Grüße
phil

Ich hätte sie tatsächlich gern erweitert. Die Einstellungen sind schon sinnvoll wie sie sind, hier und da fehlt noch etwas aber im großen und ganzen sind die spawneinstellungen schon gut.

Mein Vorschlag wäre eher, diese zu ver-drei-fachen. Oben einen Reiter "Spawn" und dann 3 Unterreiter "LTZ", "MZT" und "HTZ" Eine kurze Erklärung drunter was das bedeutet und dann genau diese gleichen Einstellung unter jeden dieser Reiter.

Das ist ja im Grunde das Problem, dass die 3 Zonen miteinander verbunden sind und nicht separat einstellbar sind. So könnte GP alles sauber für Vanilla einstellen, was auch für Serverbetreiber mit weniger Interesse reichen sollte oder der interessierte Betreiber kann sich, wenn er denn mag, in die Katakompen der Settings bewegen und sich da auslassen.

Das eine muss doch nicht das andere ausschließen. Man kann ein Häkchen "Advanced Settings" integrieren, welche diese Settings dann einblenden - vorher hat man nur 2-3 Regler pro Zone. Das ist nun echt kein Hexenwerk.

Eigentlich gehört in einem Sandbox Spiel jeder Multi ins Backend zum Einstellen.

Grüße
phil

Einer der Begrüßungssätze unseres Bots ist "Hallo -spielername-, wir freuen uns dass du da bist! Die 2 Steine vor dir sind dein Starterpack! Willkommen!"

Ich kann das allerdings so nicht bestätigen, dass alle ein voll ausgestattetes FZ haben wollen. Die Spieler investieren oft viel Zeit und Mühe um ein Auto bei uns fit zu machen, was ich super finde. Wracks können doch ruhig max auf der Insel sein - es kommt auf die restlichen Settings an wie man damit als Spieler umgeht. Zb ist es bei uns nicht sinnvoll, wracks zu fleddern oder zu verkaufen - beides bringt beim Händler kein Geld. WIrklich nur wenn du etwas für dein eigenes Auto brauchst, lohnt es sich, etwas zu demontieren.

Allerdings kommt die Frage nach einem Starterpack schon öfter. Ka, wo die Spieler diese EIgenart her haben - gruselig...

grüße
phil

Chill

Moin zusammen.

direkt vom Entwicklerteam:

Wir können nach jedem Neustart den Befehl exakt einmal benutzen und er funktioniert auch. Ein zweites Mal ist nicht möglich. Allerdings kann es in den Morgenstunden sein, dass der Befehl immer und ohne Probleme funktioniert. Weird

Bitte wendet Euch ebenfalls an die Entwickler, damit sie sehen, dass es noch mehr Server mit dem Problem gibt - oder es macht das Bugreport Team von Scumworld.
Laut seiner Aussage scheint es nur wenige Server zu geben die das haben - es könnte also helfen einen Fix zu bekommen.

Grüße und Danke
Phil

Hallo, ich habe nun lange getestet und es immer wieder auf mein Gefühl geschoben. Aber habt ihr das auch, wenn ihr Loot bearbeitet habt, dass es dann irgendwie unverhältnismäßig mehr wird?

Selbst wenn nur einzelne Items in den json getauscht wurden oder herausgenommen wurden, also im Grunde fast keine Änderung stattgefunden hat. Man könnte fast sagen, es reicht dass die Overrides da sind - der Loot wird irgendwie mehr, viel mehr...

Weiß einer der Serverbetreiber was ich meine? Habt/kennt ihr das auch?

Grüße und Danke
Phil

Nachtrag: Die Entwickler haben ja schon etwas dagegen getan - dein Char wird zumindest wieder hoch geschafft wenn dann die Bodentextur endlich da ist (die Engine also merkt, dass etwas nicht stimmt - das war früher nicht so). Nur bleibt er leider in der Position welche er gerade im und mit Auto hatte (Schräglage), Also Relog.

Eventuell können sie so etwas noch bei den Autos einbauen - ob das geht weiß ich aber nicht. Fakt ist, die LOW LOD Texturen werden keine Kollission bekommen, denn deren Aufgabe ist es, das Spiel vorm Abschmieren zu bewahren. Physikberechnungen sind größtenteils Sache der Grafikkarte - und damit auch Kollisionen! Und wenn eine LOW LOD geladen wird, ist es eh gerade völlig aus mit der Grafikleistung - da also eine Kollision zu hinterlegen und zu berechnen würde die LOW LODs obsolet machen und dein Spiel einfach crashen. Oops -> Fatal Error en masse...

Die Entwickler können einfach nicht anders, weil sie das Spiel (bzw die Engine) nicht geschrieben haben...

Phil

Ich muss nochmal eines herausstellen:
Es kann NIEMALS ein schlechter Ping oder ein überlasteter Server sein - wer das nicht glaubt, soll während der Fahrt das Internetkabel ziehen und schauen ob er unter die Map flattert.... oder ob einfach nur da steht "Connection Lost"...

Dann passiert hier etwas fatales im Thread. Ihr würfelt alle Fehler zusammen. Die von dir erlebten Fehler mit unpassierbaren Brücken oder unsichtbaren Barrieren haben rein garnichts mit den Renderfehlern zu tun, bei denen Spieler unter die Karte flattern.

Fakt ist, dass keiner mit seinem Auto unter die Karte flutscht, wenn der PC entsprechende Hardware hat und gut konfiguriert ist! Nochmal - ich rede hier nur von dem Fehler bei denen man unter die Map flutscht! Das ist auch kein Fehler von SCUM sondern eine allgemeine Eigenart der UE4! Würdet ihr euch in Conan auch so schnell fortbewegen und die Engine wäre so ausgereizt, würdet ihr das gleiche erleben. Sogar die herumschwebenden Waffen von nahen Spielern sind in diesen Spielen ebenfalls zu sehen. Das ist alles Enginebedingt und liegt an der aus- bzw über-gereitzten UE4.

Bewegt man sich schnell und hat gleichzeitig eine Grafikkarte mit 8GB oder weniger, ist die Grafikkarte sehr oft genötigt die bereits fertig gerenderten Bodentexturen wieder zu droppen - denn der VRAM reicht nicht aus und da vorn ist gerade eine Base mit 500 Entities und auf der anderen Seite eine Stadt... Fährt man nun weiter, braucht man aber die dort verwendeten Bodentexturen wieder, also wird ganz schnell frisch durchgerendert - geht in dieser Kette um ein paar ms oder ns etwas zu latent voran, wird eine LOW LOD Textur geladen (Engine) - und die hat keine Kollission - ergo: Durchgeflattert

Ein zu langsamer PC oder zu wenig VRAM sorgen also dafür, dass die Graka noch mehr zu tun hat als eine nicht ausgereitze Graka. Hat man eine aktuelle Graka mit 12, 16, 20 oder 24GB, werden die Bodentexturen einmal durchgerendert und dann im VRAM gehalten wo sie sehr lange abrufbereit sind, bis sie wieder gedropppt werden. Und natürlich wird das von Patch zu Patch schlimmer, da die Anzahl der Texturen immer mehr wird. Basebuilding, Klamotten, Fahrzeuge, Worldassets, usw...

Leicht könnte man vermuten, dass es etwas mit dem Server zu tun hat, da man diese Erfahrung auf anderen Servern evtl nicht macht. Leider falsch. Jeder Server ist anders bebaut, bespielt und hat unterschiedlich viele Sachen herumstehen...

Bitte differenziert die Probleme und blamed nicht immer gamepires (nein ich bin kein Fanboy)
Das würde vieles einfacher machen - auch für die Entwickler.

Grüße und schönes WE
Phil

Hallo, mit den neuen Looteinstellungen sind mir ein paar fehlende Sachen aufgefallen.

Es fehlt mir total die Möglichkeit, eigene Presets zu hinterlegen.
Mir wird Himmelangst, wenn ich an die anstehenden Änderungen denke, wenn neue Items ins Spiel kommen.
Eigene Presets hinterlegen und Containern zuweisen würde helfen, das ganze zu minimieren.

Aber zum Hauptproblem:

Derzeit sehe ich keine Möglichkeit, einen Container mit den echten Lootchancen zb 10.000 mal zu testen, darum mein Vorschlag:

Neuer Befehl: #SimNextContainerAndPrintOutput Anzahl

Damit wird der nächste Container der gelootet wird, nur simuliert.
"Anzahl" im Befehl gibt an, wie oft das Looten simuliert wird und der Output wird in Listenform ausgegeben.

Zb:
Candle_01 102
Scredriver_small 52
usw.

Zusätzlich wäre der Output in der Loot.log sinnvoll.

Das wäre meiner Meinung nach ein sehr nützliches Werkzeug zum ausloten des Loots.

Grüße und Danke
Phil

Ok, hier die Lösung:

Man kann Subpresets mit Fixed Items kombinieren und diesen eine Wahrscheinlichkeit geben.

{
"Subpresets": [
{
"Rarity": "Uncommon",
"Id": "Special_Packages-Vault-Examine_RPK_Vault_Pack"
},
{
"Rarity": "Uncommon",
"Id": "weitere Vault-Packs"
}
],
"Items": [
{
"Rarity": "Common",
"Id": "2H_Katana"
},
{
"Rarity": "ExtremelyRare",
"Id": "2H_Katana1"
}
],
"Probability": 5,
"QuantityMin": 1,
"QuantityMax": 1,
"AllowDuplicates": false,
"ShouldFilterItemsByZone": true,
"InitialDamage": 0,
"RandomDamage": 0,
"InitialUsage": 0,
"RandomUsage": 0
}

Grüße
phil

Copper Coin kann man als Fixed Item droppen lassen. Da und nur da, geht es. Also zb als Belohnung in einem Killbox-Locker

Grüße
phil

EDIT: Klar, wer lesen kann. BHop hat genau das schon geschrieben

EDIT2: Könnte man die Coins nicht als Fixed Item in eines der sinnlosen Packs stecken, die man eh nicht braucht. Zb eines der Munipacks aus der Killbox (da entfernen). Und dieses Pack dann mit einer Wahrscheinlichkeit einbinden?

Das stimmt. Als Beispiel sind die fixen Spawnzeitenverhältnisse zwischen HTZ (0,5-1 Sek) und LTZ (60-120 sek) so weit auseinander, dass ein Respawn im Bunker von 10 Minuten (so wie es vorher war (Clear-Gefühl)) unmöglich ist. Stellt man nämlich den Multi so hoch dass die HTZ passt, hat man in der LTZ eine Respawnzeit von mehreren Stunden...

Das macht die Städte entweder total langweilig und die Bunker funny oder die Städte funny und die Bunker unspielbar.

Workaround:

- Pieper deaktivieren (die spawnen eh teilweise in einem)
- Zombies keine Türen mehr öffnen lassen (Vorsicht - Brenner öffnet dann auch nicht mehr im Bunker)

Den Rest kann man mit Zombie-Grundmenge, spawnradius, Hordenmultis, global encounter, usw ausbalancieren.

Wir haben es nun fast geschafft das alte Spawnverhalten wieder zu simulieren - allerdings ohne Pieper - bis der spawn gefixt ist.


Es fehlt noch ein wichtiger Parameter, nämlich der Mindest-Spawn-Abstand! Der maximale Abstand ist einstellbar, leider beinhaltet der auch immer 0, was dazu fürt dass man ab und zu einen Spawn direkt neben sich oder gar in sich oder auf sich hat. Ist das ein Pieper -> Ende. Es muss also ein Mindest-Spawn-Abstand mit in die Config.

Grüße
phil

Hallo,

wir versuchen krampfhaft einen Weg zu finden, einem bestimmten Container, und nur diesem Container, mit einer gewissen Wahrscheinlichkeit ein Item zuzuweisen. Leider hat dieser Container bisher nur "fixed" Items.

Konkret:

Im Abandonded Bunker gibt es einen Tier-4 Lockpick Locker im Honeypot, dieser soll wenn man ihn öffnet mit einer gewissen Wahrscheinlichkeit auch mal ein Katana enthalten und mit noch weniger Wahrscheinlichkeit ein Goldenes Katana - wir brauchen also zu den bestehenden Waffenpacks 2 weitere, denn die bestehenden sind fixed Items.

Wir finden einfach keinen sinnvollen Weg, das umzusetzen ohne in andere Container einzugreifen, wo ja die bestehenden Packs auch genutzt werden. Hat jemand eine Idee?

Grüße und Danke
Phil

BTW gleiches mit dem Feuerschaden. Ist der deaktiviert, ist der Brenner ein zahmes Kätzchen...

Möchte man also im PvE nicht, dass sich Leute gegenseitig (oder Fahrzeuge) grillen, macht der Brenner keinen Feuerschaden mehr.

Grüße
phil

Hallo, deaktiviert man in den Optionen dass Zombies keine Türen mehr öffnen sollen, ist auch der Brenner in seinem Kabuff eingesperrt.

Entweder ein Bug oder wenn nicht, dann eine fehlende Option.

Grüße
phil

Die Server-TPS haben sich nicht gebessert und die Frametimes sind ebenfalls so geblieben.

Keine Ahnung wie es auf shared Servern aussieht, aber wir haben 0,0 Perf- Verbesserung erfahren.

Und das obwohl wir bei aktuell 52 Spielern gerade mal 54 Zombies und 5 Tiere auf dem Server haben...

Das Horde-System in jetziger Form (auch mit den Einstellmöglichkeiten) ist eine volle Enttäuschung.

Zitat von MrVain712

Aber wenn das gewinnen von Performance jetzt nur noch bedeutet, das man dem Spiel nach und nach die Seele nimmt

/sign

Jo, da hilft nur PC fit machen. Low LOD Textures haben in SCUM keine Kollision - das war schon immer so.

Es ist auch kein Problem mit "Unter die Map fallen" sondern mit zu langsamen oder einfach schlecht konfigurierten PCs die nicht in der Lage sind aber einer bestimmten Geschwindigkeit das Spiel sauber und schnell genug durch zu rendern.

Das ist weder ein Bug noch irgend ein anderer Fehler. Es passiert genau das, was vorgesehen ist.

grüße
phil

Ja, nicht so toll mit den cryptischen Werten. Ich glaube es ist ein doppelter Multi für jeden Parameter da - der Multi der Devs und unser Multi.

Originalwert x Devmulti x Settingsmulti = Servereinstellung so meine Vermutung.

Ein Meterwert würde vorraussetzen, dass das eben nicht so stattfindet sondern der Wert den wir eintragen nicht weiter multipliziert wird.

Grüße
phil

Zitat von roemsen

Das Problem ist halt, wenn irgendwann noch Mods kommen, wirds heftig bis richtig übel. Und wer weiß was die Server-Admins dann noch so alles treiben.

Und daaaaannnn fällt alles (negative) aber auf das Spiel selbst zurück... -> "Das Spiel ist kaputt... das Spiel läuft bei meinem Rechner nicht wirklich... Ich hab ständig Abstürze..."

Ja, waurm nur?!

Also...

Auch die Entwickler haben eine Verantwortung gegenüber ihrem Produkt... besonders bei einem Baby wie SCUM.

Ach, als ob nur ein einziger Spieler auf die Idee kommen würde, Funcom wegen dem AOC Gelagge anzugehen.
Ich möchte allgemein mal jemanden sehen, der einen Gamedev oder ein Spiel wegen einer Mod blamed...

Entweder sind SCUM allgemein Spieler einfach zu deppert zu begreifen was eine Mod ist oder die Devs sprechen dem Spieler ab, das unterscheiden zu können.
Für mich eher eine Beleidigung - auch das Deaktivieren der Vögel, usw. 1 Vogel braucht 10 Mal so viel resourcen wie nen Zombie? ja ne is klar....