[TC] OOS-Sektorwachen im Reich der Xenon

[Allmaecht]

@MoSII: Sind das CODEA Träger? In dem Fall zählt jeder Jäger extra, Vanilla werden einfach alle Jäger zusammen gehauen um die Kampfkraft zu bestimmen. Wär nett falls Egosoft mal was zum nächsten Patch ausplaudert, wenn da am OOS Kampfsystem was geändert wird, stehen wir danach wieder vor dem selben Problem. Wär schön wenn man Informationen erhalten könnte, die das OOS Verhalten allgemein ein bischen nachvollziehbar machen. Denn mit Logik kommt man, wie´s scheint, nicht allzu weit. Ach war das bei X2 noch schön unkompliziert. Ich denke mal es sind die vielen kleinen, nicht ganz ausgegorenen Extras die nach und nach die Balance etwas zum Kippen bringen.

[MoSII]

@MoSII: Sind das CODEA Träger? In dem Fall zählt jeder Jäger extra, Vanilla werden einfach alle Jäger zusammen gehauen um die Kampfkraft zu bestimmen. Wär nett falls Egosoft mal was zum nächsten Patch ausplaudert, wenn da am OOS Kampfsystem was geändert wird, stehen wir danach wieder vor dem selben Problem. Wär schön wenn man Informationen erhalten könnte, die das OOS Verhalten allgemein ein bischen nachvollziehbar machen. Denn mit Logik kommt man, wie´s scheint, nicht allzu weit. Ach war das bei X2 noch schön unkompliziert. Ich denke mal es sind die vielen kleinen, nicht ganz ausgegorenen Extras die nach und nach die Balance etwas zum Kippen bringen.

Jap sind 2 coole Codea Träger =)

€: in meiner Sig. sieht man ja das ich eigentlich keine Vanilla[EGO] Commandos benutze

[wyvern11]

Vanilla werden einfach alle Jäger zusammen gehauen um die Kampfkraft zu bestimmen.

das ist eine unbestätigte (man könnte auch sagen widerlegte, zumindest für X3R) legende :
http://forum.egosoft.com/viewtopic.php?t=182101

Dennoch denke ich, das Raketen im OOS Kampf nicht immer treffen.

doch, damals immer und sofort - siehe genannter Thread

[Andreas2801]

Nochmal zum Thema Raketen im OOS Kampf.
Ich weiss zumindest aus eigener Erfahrung das Q´s gegen Mich im IS Kampf immer wieder Hammerhai nutzen.Gut dank Raketen Abwehr stört es mich IS nicht gross.
Aber wenn OOS keine Raketenabwehr eigener Schiffe funzt und die Q´s evt verstärkt Raketen nutzen OOS dann sind M2 in der tat schnell Geschichte.

[Burneyx]

@wyvern11,
hab den Bericht gelesen und er bestätigt im großen und ganzen meine Beobachtungen.
Dennoch ist es bei mir so:

GKS allein, hoher Schildverlust der nur durch Raketen so schnell entstehen kann.

GKS mit Jägerschutz, da entsteht dieser hohe Schildverlust nicht, da auch die Jäger zum Ziel werden. Da solch starke Raketen einen Jäger sofort zerstören würden, falls sie ihn trifft, müßte ich jeden Tag die ganzen Jäger ersetzen. Dies ist aber nicht so, deshalb bleibt eigentlich nur die Vermutung das Raketen nicht zwangsläufig immer treffen. Anders kann ich mir das logisch nicht erklären.

[Codo]

Natürlich ist so was nicht gewollt und Sinn macht es doch, wenn man es aus der Sicht von Multicore CPU's betrachtet.
Was ich sagen will:Wenn ein Teil der Scripte (was Sinn macht) auf Core2
läuft, dann darf das alles natürlich nur Ergebnisunabhängig von Core1
sein, da sonnst die richtige "Reihenfolge" gar net mehr zusammenpassen würde.
Beispiel:Core1 berechnet OOS Kampf hardcodet. Falls jetzt irgendwelche
Scripte mit in den OOS Kampf auch nur entfernt mit beteiligt sind, und das
auf Core2 abläuft und dann noch zu früh ein Ergebniss liefert, obwohl
die Auswertung von Core1 noch gar net da ist...oder eher umgekehrt
Dann haste Kuddelmuddel.verstehste
In dem Fall wäre es sicherer (leider auch langsamer) TC nur auf einem
Kern laufen zu lassen.

Für so etwas gibt es Semaphoren http://de.wikipedia.org/wiki/Semaphor_(Informatik). (Sorry, das Board kann diesen Link nicht richtig anzeigen, einfach in Wiki weiter verzweigen) Das Problem hast du im Prinzip auch bei Systemen mit nur einem Kern, sobald die Aufgaben auf 2 Prozesse oder auch nur Threads verteilt werden, muss synchronisiert werden, falls nicht, gibt es schnell schwer zu erklärende und zufällig erscheinende Ereignisse (was mir jetzt wieder irgendwie bekannt vorkommt).

[Codo]

Seit der objektorientierten Programmierung ist Code nicht mehr monolitisch sondern modular. Der nächste Schritt ist die Threaded-Programmierung, ...

Nö! Modularisierung ist wesentlich älter als objektorientierte Programmierung. Auch die Aufteilung auf verschiedene Prozesse und deren Synchronisation ist wesentlich älter als die objektorientierte Programmierung. Während meines Studiums war die objektorientierte Programmierung noch in den Kinderschuhen, ich hatte diese leider überhaupt noch nicht. Unser Programmiermodell war die strukturierte Programmierung und auch diese war nicht der Beginn der besagten Techniken. Die Aufteilung in verschiedene Module wurde mit der Weiterentwicklung der strukturierten Programmierung populär, insbesondere die leider fast vergessene Programmiersprache Modula 2 (3) war hier hervorragend geeignet, aber man konnte dies auch schon vorher, wenn auch ohne Unterstützung durch die Programmiersprache und in Großprojekten war dies schon lange notwendig. Dann hat sich leider diese ...-Sprache "C" durchgesetzt. In der Prozesstechnik, in der verschiedene Schaltvorgänge synchronisiert werden müssen, sind Sperrmechanismen und ähnliches ebenfalls schon lange bekannt, es gab auch mitte der 80er schon gute Sprachen die dies unterstützen, z.B. Pearl ( http://de.wikipedia.org/wiki/PEARL , bitte nicht verwechseln mit der Scriptsprache Perl), notfalls geht so etwas aber auch mit Assembler, dann halt zu Fuß.

[Codo]

Ebenfalls würde eine durch M5 zerstörte Station nicht wirklich dadurch geklärt, die Station wehrt sich eh nicht.
Da muss was anderes als das Threading am Werk sein!
Es sei denn, die Engine "vergisst" deaktivierte Threads, unter Umständen wieder zu aktivieren.

Es könnte dann am Threading liegen, wenn der Thread, der für die Aufladung der Schilde der Station zuständig ist, einfach stehen bleibt oder nicht oft genug dran kommt. Es würde zwar eine ganze Weile dauern, aber irgend wann währe die Station hin. Falls die Warnung wegen dem Angriff nicht erfolgt, könnte diese ebenfalls in diesem Thread beheimatet sein oder halt eben in einem anderen Thread der ebenfalls nicht zum Zuge kommt. Wenn das ganze jedoch innerhalb kürzester Zeit passiert, dann würde ich auf was anderes Tippen. Möglich währe evtl. noch, bei Beschuss soll die Station melden wie viel Hülle und Schilde Sie noch hat, keine rechtzeitige Antwort, keine Hülle mehr ... aber das ist jetzt wirklich schon Kaffeesatz lesen.

Ich habe da ein Problem mit Komplexen, welches die gleiche Ursache haben könnte. Ich habe bei meinen Komplexen beobachtet, dass die Synchronisation der Teilfabriken seit X3TC scheinbar nicht mehr immer klappt, manchmal kann eine Level 1 Fabrik nicht genug Produkte für eine passende Level 2 Fabrik herstellen. Bei meinen Komplexen packen es die Schneckenfarmen öfters mal nicht, die Raumschmieden zu versorgen. Es handelt sich hierbei um kleine, nicht vorhersagbare Fehlmengen. EZ sind ausreichend vorhanden, Zwischenprodukte werden nicht gehandelt und ich hatte mehrfach mal mehrere hundert Schnecken nachgeliefert. Ich habe mehrere dieser Komplexe, teilweise laufen die wunderbar und dann fängt einer wieder an gelb zu blinken. Die Komplexe sind bei mir ziemlich klein (eine Schneckenfarm, eine Raumschmiede, 2 Erweiterte Satellitenfertigung) und erwirtschaften für diese Produkte keinen Überschuss, so das Fehlmengen hier schnell sichtbar werden.

[Allmaecht]

@Heiko Seipel: Da haste natürlich hundertpro recht- ich hätte vielleicht schreiben sollen "seit es Objekte und Klassen gibt programmiert kein Mensch mehr monolitisch". *g* Ich glaub, was du im letzten Post gemeint hast, ist dieses leidige Turing-Problem. Oder hiess der Touring? Na, jedenfalls taucht das bei sehr grossen System oder hier Programmen scheinbar wie aus dem Nichts auf und verhagelt einem den Tag. Bei Mehrkernsystemen wird sich´s nie ganz ausschliessen lassen. Plötzlich steht die Maschine in einem nicht definierten Zustand zu dem´s keine Überleitungsfunktion mehr gibt. Theoretisch wärs sogar möglich dass das passiert, wenn die Systemauslastung zu hoch ist und der Prozessor bzw. Speicher nen kleinen Fehler hat... und Prozessoren haben immer kleine Fehler. Micro-Fehler sozusagen. Ha. Klugscheissen musste jetzt einfach sein, hab auch Info studiert. Nur, wenn das passiert schmeisst´s ne Exception. Und das fällt einem sofort auf.

[Gazz]

Bei meinen Komplexen pachen es die Schneckenfarmen öfters mal nicht, die Raumschmieden zu versorgen. Es handelt sich hierbei um kleine, nicht vorhersagbare Fehlmengen. EZ sind ausreichend vorhanden, Zwischenprodukte werden nicht gehandelt und ich hatte mehrfach mal mehrere hundert Schnecken nachgeliefert. Ich habe mehrere dieser Komplexe, teilweise laufen die wunderbar und dann fängt einer wieder an gelb zu blinken.

Und es überrascht dich tatsächlich, daß die Schnecken manchmal nicht nachkommen?
(Kein Informatiker hier, nur Grundkenntnisse in Zoologie)

[Allmaecht]

@Gazz: Übst du schon für ne Büttenrede?

[Codo]

Bei meinen Komplexen pachen es die Schneckenfarmen öfters mal nicht, die Raumschmieden zu versorgen.

Und es überrascht dich tatsächlich, daß die Schnecken manchmal nicht nachkommen? (Kein Informatiker hier, nur Grundkenntnisse in Zoologie)

Ich habe extra Rennschnecken rein gepackt.

[Burneyx]

Bei meinen Komplexen pachen es die Schneckenfarmen öfters mal nicht, die Raumschmieden zu versorgen.

Und es überrascht dich tatsächlich, daß die Schnecken manchmal nicht nachkommen? (Kein Informatiker hier, nur Grundkenntnisse in Zoologie)

Ich habe extra Rennschnecken rein gepackt.

Manchmal kommt es vor das die KI Waren aus Komplexen kauft, obwohl diese nur auf Einkauf stehen. Ist mir in meinem Spritkomplex in BalaGis Freude laufend mit dem Weizen passiert. Einfach den Preis hochstellen für die Schnecken, dann hört das auf.

[Snakeegg]

@ Burneyx !

... Einfach den Preis hochstellen für die Schnecken, dann hört das auf.

Nö
So ist es leider ganz und gar nicht. Was Heiko Seipel beobachtete kann ich nur bestätigen ! Hatte das Stationsmenü meines Komplexes offen und beobachtete wie meine Agrarzentren immer mal wieder die Produktion nach einem vollendeten Zyklus unterbrachen, obwohl massenhaft Ressourcen vorhanden waren. Dies führte dann über kurz oder lang dazu, daß meinen Rheimwerken die Ressourcen ausgingen. Dieselben Unterbrechungen konnte ich auch bei den Kristallfab`s beobachten.

Die wichtigste Beobachtung hierbei ist für mich allerdings, daß sich die Anzahl dieser "Aussetzer" unter Verwendung von SINZA massiv erhöhten und stark abhängig von meinem eigenen Standort (ruhiger Sektor<>voller Sektor) waren.

Ich denke, daß hier etwas ähnliches wie im OOS-Kampf geschieht, daß bestimmte Scriptroutinen einfach nicht mehr berücksichtigt werden, wenn die Prozessor-/Speicher-/Auslagerungslast zu hoch wird.

Gruß Snakeegg !

[Ju7eFa3]

Kann ich nur bestätigen!
Habe ab und zu das selbe Problem. Bei mir ist dies vor allem bei meinem Drogenkomplex in HG der Fall.

FIX

[wyvern11]

@all : bitte für komplex-warenaustausch-probleme einen eigenen thread starten, auch wenn der verdacht naheliegt, dass das problem eine ähnliche ursache hat

@burneyx:

GKS allein, hoher Schildverlust der nur durch Raketen so schnell entstehen kann.

Du kannst es nicht wissen, aber dem muss ich widersprechen: rüstet man ein schiff mit einer einzelnen waffe aus und lässt die mal ein weilchen feuern, erkennt man, das die auftretenden schäden im wesentlichen von der form

<Basisschaden> x N , wobei N = 1,...,150 ist

Ist der Basisschaden zum Beispiel 1000, können Schäden zwischen 1000 und 150000 auftreten (kleine Schäden sind aber häufiger). Eine Feuerrate spielt auch noch eine Rolle. Manche Waffen schießen doppelt so oft wie andere. Ein detailiertere Auswertung ist in der Mache ...

Fehlschüsse gibt's übrigens auch, jede Waffe hat eine eigene Fehl-Rate

[Burneyx]

@wyvern11
Klar gibt es auch Fehlschüsse, darauf spekuliere ich ja, wenn ich meine GKS von Jägern begleiten lasse.
Die Wahrscheinlichkeit das OOS ein Jäger mit Lasern getroffen wird ist meiner Erfahrung nach wesentlicher geringer als bei einem GKS, das deckt sich ja auch mit dem IS Kampf.
Und da die Schilde ja relativ lange brauchen um zu regenerieren kann man sich das ja nach einem beendeten OOS Kampf schön anschauen.
Bsp.:
Xenon Q Pat in Grüne Schuppe VS Teladi Kondor + 35 Nova
Nach dem Kampf:
1 Klick auf den Kondor: Schiffe in Besitz 35, ergo kein Verlust.
Dann schnell Schilde durchsehen und man weiß bescheid, 1 Nova bei 50% Schild, der Rest 100% Schild.
Klar sind die Xenon in dieser Konfiguration schnell hinüber, aber das ist nicht der einzige Grund für den minimalen Schaden.
Meiner Erfahrung nach ist die Chance auf Fehlschüsse bei Jägern mit einer Wendigkeit von um die 60 U/min sehr hoch und nur dadurch kann ich mir solche Kampfergebnisse erklären.
Der einzige Nachteil ist halt, das man doch ab und an Jäger ersetzen muß, aber wohl wesenlich leichter zu verschmerzen als der Verlust von GKS.
Auch kann man ja bei den Kollegen beobachten, das sie ihre GKS beschützen.
Bsp.: Jonferco(gesehen in Nathans Reise)
1 x Jonferco Colossus M3+, M3, M4, M5 alles an Bord und voll besetzt.
3 x Jonferco Cerberus
1 x Jonferco Schw. Zentaur
3 x Jonferco Zentaur
Dann noch ein M7M und 3 M8 der Argonen(Namen grad nicht im Kopf).

Da Egosoft solche Vorgaben für sinnvoll erachtet und meine Erfahrungen sich damit decken, setze ich halt lieber manchmal etwas mehr ein an Schiffen. Eine gewisse Reserve ist sowieso ratsam, da die stärke der Gegner mit wachsendem Spielstand sowieso dauernd ansteigt.

[wyvern11]

es war schon in x3r so, dass eine wolke von unwichtigen zielen die xenon verwirrt. wir können gerne darüber spekulieren, ob die ziel-turnrate einfluss auf das trefferbild hat, aber da werde ich mich erst zu auslassen, wenn ich es im log gesehen hab...

wichtig für dich zu wissen ist jedenfalls, dass waffen ein spannbreite von
Faktor um 150 haben.

**eine** HEPT/EPW kann also etwa zwischen 330 punkten und 48000 punkten schaden erzielen (pro treffer)

[h4nnib4l]

kann es sein, dass die Clusterflak auch IS kaputt ist? war gerade zum ersten mal damit untewegs, OTAS M2, Khaagh jagen, seh einen Scout der vor einer wand aus explosionen rum fliegt und munter auf mich schiest...

[Wolf13]

Flak oder Clusterflak funktionieren manchmal IS nicht, wenn man zum falschen Zeitpunkt speichert und da gibt es einen eigenen Thread und wenn der Effekt auftritt, sollte man noch ein paar Waffen zum Wechseln haben oder den Sektor verlassen, da es so bleibt und gerade ein Save das Problem nicht behebt.