Die Warnung klingt nach einem Problem mit der Masterserver-Kommunikation. Nach Rundenabschluss senden ja alle Clients ihre Ergebnisse an den Masterserver, wobei eben eine Sektion [Response] mit dabei ist. Ihr verwendet aber schon den clonk.de Server, bei dem alles funktionieren müsste?

Okay, das Problem ist gelöst. Schuld daran war nicht die Existenz von UpdateScoreboard(), sondern ein Versuch, auf ein bereits gelöschtes Objekt mit AddEffect() zuzugreifen. If-Verschachtelungs-Fail. UpdateScoreboard() hat nur mitgemischt, da durch das nicht vorhanden sein Errors ausgelöst wurden, wodurch der Code nicht bis zum Ende durchlaufen konnte und die kritische Stelle nicht erreicht hat.
Ich finde es trotzdem krass, dass nur die Verlierer einen Crash bekommen haben. x)

An dieser Stelle nochmal herzlichen Dank an Scaba und Kanibal!

Das Szenario einmal mit einer Debug-Engine spielen; entweder Du selbst oder ein Mitspieler, der Clonk Rage als Debug-Build hat

Hilfreich wäre auf alle Fälle mal das Log.

Es gibt Menschen die noch Kasernenstadt II spielen wollen? \o/

Hab mir den Fehler mal angeschaut: Der Engine-Crash kann immer dann auftreten, wenn ein Objekt den Inhalt seines Containers bearbeitet während er gelöscht wird. Ein Beispiel:
Man hat ein Container-Objekt container und zwei Inhaltsobjekte contents1 und contents2. contents1 hat in seinem Script einen Destruction()-Callback der das contents2-Objekt aus dem Container herausholt:

protected func Destruction() { FindObject(CTS2)->Exit(); }

Das Szenarioscript sieht wie folgt aus:

func Initialize()
{
  var container = CreateObject(CTNR, 0, 0, NO_OWNER);
 
  // Reihenfolge muss manchmal vertauscht werden
  container->CreateContents(CTS1);
  container->CreateContents(CTS2);
 
  container->RemoveObject();
}

Dann passiert Folgendes:
1) C4Object::AssignRemoval() wird für container aufgerufen, es ist also this==container.
2) Darin wird die verkettete Liste der Inhaltsobjekte durchlaufen und die Objekte entfernt, indem C4Object::AssignRemoval() rekursiv für diese Objekte aufgerufen wird.
3) clnk zeigt jetzt auf das Contents-Listenelement für contents1 und next auf das für contents2.
4) Man befindet sich also wieder in C4Object::AssignRemoval(), diesmal aber für this==contents1.
5) Darin wird der Destruction()-Scriptcallback aufgerufen.
6) Destruction() ruft Exit(contents2) auf, wodurch C4ObjectList::Remove(contents2) ausgeführt wird.
7) Dort wird das Element für contents2 aus der Contents-Liste entfernt und freigegeben.
8) Wieder zurück in C4Object::AssignRemoval() für this==container, aber diesmal im nächsten Schleifendurchlauf. Hier wird nun clnk=next ausgeführt.
9) next wurde in 3) auf das Contents-Listenelement von contents2 gesetzt. In 7) wurde es aber freigegeben!
10) Ab hier sollte nun irgendwann die Engine abstürzen, da versucht wird, den Zeiger auf contents2 aus dem freigegebenen Listenelement zu lesen.

Um den Fehler zu beheben muss die Schleife zum Entfernen der Inhaltsobjekte bei jedem Durchlauf wieder von vorne anfangen (da die Liste ja durch Scriptcallbacks verändert worden sein könnte):

// Kill contents
C4Object *cobj; C4ObjectLink *clnk,*next;
while ((clnk = Contents.First) && (cobj = clnk->Obj))
{
  next = clnk->Next;
  if (fExitContents)
  {
    cobj->Exit(x, y);
  }
  else
  {
    Contents.Remove(cobj);
    cobj->AssignRemoval();
  }
}

Eine andere Lösung (zumindest für das Szenario) ist, den Scriptbug zu beheben, der zu dem Enginefehler führt: Im Szenarioscript wird beim Relaunch nicht geprüft, ob der aktuelle Spieler noch lebt. Das lässt sich beheben indem man
if (!GetPlayerName(iPlr)) return;
in die erste Zeile von RelaunchPlayer() schreibt.