JA2 v1.13 Release ist online [v2085]

[Starwalker]

Richtig. Die Frage ist, warum funktioniert es in b005 und in b007 funktioniert es nicht?

bzw. ich könnte mir vorstellen, dass die assertion bei b005 gerade nicht greift, denn auch bei b005 habe ich undefinierte städte verwendet und das spiel konnte problemlos weiterfahren. Auch ja2 1.12, 1.02 und ja2005 kennen diese Fehler nicht. In dem Kontext ist es auch völlig hirnrissig, hier auf 1-12 townID zu testen.

Irgendjemand muss doch den schrott verbrochen haben und müsste das revidieren können oder nicht?

Ja schon, noch wissen wir aber nicht, wo der 'Schrott' sitzt. SpaceViking's TownLoyalty.cpp und die für die exe vom SVN-Server sind laut SpaceViking und ChrisL gleich, also kann der Fehler eigentlich nicht in TownLoyalty.cpp liegen, sondern er liegt an der Stelle, wo bTownId definiert (oder eben nicht definiert) wird.

Die Zeile in TownLoyalty.cpp lautet ja
Assert( ( bTownId >= FIRST_TOWN ) && ( bTownId < NUM_TOWNS ) );
wobei FIRST_TOWN=1 ist, und NUM_TOWNS die Gesamtzahl der Städte+1 (im normalen Spiel haben wir 12 Städte, plus den Zustand wo bTownId=0 [BLANK_SECTOR]).
Die Assertion soll sicherstellen, daß die übergebene bTownId für die folgende Funktion sinnvoll ist, z.B. ist bTownId=0 für Loyalität nicht sinnvoll, weil das keine Stadt sondern Pampa ist.
Wenn bTownId garnicht definiert wurde, dann ist es vermutlich -1. Deswegen hätte mich der aktuelle Wert im Abbruchsfalle ja auch interessiert, aber Assertions sind einfache JA/NEIN-Fragen, die ohne Ausgabe abbrechen (hat man mir zumindest so erklärt).
Man müsste also wissen, wo in Deinem Fall die bTownId (falsch) definiert wird, aber im 'normalen' 1.13 tritt der Fehler bisher nicht auf, daher ist er auch nicht so einfach zu finden.

Also:
Kann sein, daß bTownId=-1, weil's nicht definiert wurde.
Kann sein, daß bTownId=0, weil's in RR Pampa ist, was in 1.13 mal Stadt war (bezogen auf RPC/NPC-Skript/File?)
Kann sein, daß bTownId=>NUM_TOWNS ist, weil in RR mehr Städte sind, NUM_TOWNS aber nicht angepasst wurde (fehlerhaft oder garnicht aus Cities.xml eingelesen).

Fragt sich eben, welcher der drei Fehler auftritt, und wo er verursacht wurde.

[smilingassassin]

der Fehler an sich ist IMO bereits, dass diese assertion sinnloserweise während dem anheuern von RPC's abgespielt wird.

Für die RPC's ist es scheissegal ob sie Town ID 0, 1, oder sontwas haben, es ist irrelevant und wurde von ja2 auch IMMER richtigerweise für irrelevant erachtet, bis vor einigen revisionen jemand diese i.C. sinnlose assertion aktiviert hat. (so siehts zumindest aus)


Um das in "vanilla" zu testen, mach mal folgendes: in proedit, nimm einen RPC, der in einem fest definierten sektor ist, z.B. Dynamo oder Shank, dann setz mal "NPC town" auf "none" --> neues spiel, versuchen anzuheuern --> assertion failure
(oder definiere einem RPC wie hamous ohne festen sektor einen festen sektor, das hat die gleiche Konsequenz)

Jetzt bei RPC's wie darrell wär es ja eigentlich so, dass bereits vanilla ja2 ihm kein NPC town definiert. Wenn man den dann rekrutiert, schmiert ja2 ab. Der 0 wert ist also hier nicht falsch, der 0 wert hat hier früher immer fehlerfrei funktioniert, es kann nicht sein, dass das jetzt plötzlich nicht mehr gehen soll.

es muss doch möglich sein, den rekrutierungscode von beta5 und beta7 zu vergleichen, diese änderung ist völlig sinn- und zwecklos und erschwert nur unnötig einfache änderungen in proedit (und ich kann mit bestimmtheit sagen, dass nicht jeder proedit user so schnell den workaround finden wird, sinnlose npc towns zu verteilen)

[smeagol]

Falsch, das ist ein Fehler im XML-Editor.
Der ist so programmiert (warum auch immer) das er die Lookup-files aus Hardcode neu erstellt, und wenn im code keine 60 Einträge für silhouettes.xml vorgesehen sind, sondern nur 26, dann erstellt der Editor eben eine silhouettes.xml mit nur 26 Einträgen.
Frag' mich nicht warum Madd Mugsy den XML-Editor genau so programmiert hat (der enthält leider einiges an hardcoded limits), ich weiß es nicht, und ich habe auch schon lange nichts mehr von ihm gehört.

Kann man da den Code im XML-Editor nicht dahingehend modifizeiern, dass der die ausgelagerten Lookups reinliest anstatt die aus dem hardcode zu reproduzieren, wenn der Einträge enthält, die dem Editor nicht gefallen? Ich finds an der Stelle eben merkwürdig, dass die geänderte XML von Jax immer anstandslos vom Editor akzeptiert worden ist. Wenn ich jetzt versuche eine nur leicht abgewandelte Form davon dem Editor unterzuschieben, wandelt der die trotzdem immer stumpf um. Das nervt schon sehr... von daher kann ich das Gemotze von Khor gut nachvollziehen. Von einer stable modding platform ist das jedenfalls im Moment leider noch weit entfernt.
Die Sache ist nun mal, wenn man eine bestimmte Grenze an items erreicht hat, dann kommt man eben mit einer so begrenzten Anzahl an verschiedenen Taschen nicht mehr hin und mir fehlen schlicht und einfach einige wichtige Taschentypen in der derzeitigen Version der silhouette.xml (z.B. die Taschen für normale Gewehrmunition (also nicht die für die Sturmgewehre sondern für Sniperrifle Munition), die Taschen für große Handgranaten (Tränengas, Senfgas, Flashbangs...), für große Pistolen, für Wurfmesser...) ohne die ich leider nicht vernünftig die LBEs bearbeiten kann. Keine Ahnung, wie Jax das hinbekommen hat, zu dem Zeitpunkt als die XML Dateien erstellt worden sind, war ich nur für die Maps zuständig und hab mir da ehrlich gesagt auch keinen Kopf drum gemacht, weil ich dachte, das passt schon...
Das Problem ist aber nunmal, dass der WF Mod sich dadurch leider nur begrenzt auf neue Versionen übertragen lässt. Ich fürchte ja auch, wenn ich das irgendwie zum Laufen bekommen sollte, dass etliche Items auf den Karten nicht mehr mit den geplanten Items übereinstimmen. Die Stabilität des gesamten Projektes ist dadurch einfach nicht gegeben.

Allein das Einfügen von neuen Grafiken ist eine riesen Qual. Ich hab gestern dann noch festgestellt, dass unendlich viele Item Grafiken, die im WF mod vorhanden sind, im standard 1.13 nicht vorhanden sind. Neue items einzubauen artet somit immer in mühseliger Kleinarbeit aus (allein schon deswegen, weil die Bilddateien in 3 einzelnen Dateien gespeichert werden und dann natürlich auch unter den richtigen Nummern gespeichert werden müssen). Kann man zusätzlich zu den Guns, P1, P2 und P3 Items noch weitere Kategorien einbauen? Oder eventuell die Bilder in den Kategorien sortierter zusammenstellen? Ich denke mal, man kommt um die Arbeit einfach nicht drumherum, wenn man so etwas wie eine stable modding platform erstellen möchte. Der ganze Ärger hat ja bei mir damit angefangen, dass ich nicht mehr genügend Bilder hatte, um neue items zu erstellen. Aber wie ich schmerzlich feststellen musste ist es ja in der Tat nicht so einfach, neue Bilder einfach hinzuzufügen.

lange Rede, kurzer Sinn: So ist modden jedenfalls nicht sonderlich angenehm und ich würde mir da ehrlich gesagt wünschen, dass eine breitere Basis an Images in das Standard 1.13 übernommen wird (die müssen ja nicht alle gleich zu Items verarbeitet werden, aber so hätte man immer die Gelegenheit, bei Modding vorhaben das entsprechend umzusetzen...). Da gibt es dann natürlich noch die Probleme mit dem Mapeditor, der auch nicht alle Items einliest, etc.... Im Moment hab ich jedenfalls keine vernünftige Arbeitsversion, auf deren Grundlage ich an dem WF Mod weiterarbeiten könnte. Was sehr bedauerlich, aber anscheinend auch nicht zu ändern ist, wenn nicht an den entsprechenden Editoren geschraubt wird...

[Fan]

Da laufen 2 Diskussionen parallel ab; ich bleibe mal bei der einen:

@smili & starwalker

Nur ein Versuch eines Laien, Licht in die Sache zu bringen.
Vielleicht ist es wichtig, mitzuteilen, wie es genau zu dem crash gekommen ist:

Wenn ich bisher im Rahmen von Tests für PCM den Hicks einen 'Besuch' abgestattet habe, war ich wenigstens in einem Sektor von Cambria, wenigstens in dem, in dem sich Keith Hemps befindet.
Dieses mal bin ich direkt in den Sektor G 9 gegangen (mit <Strg><t>, weil ich den crash testen wollte. Es wurde also nicht die für die Quest relevante Stadt berührt. Ich habe Flo von MERC verpflichtet und sie mit dem alten Hick verkuppelt. Daraufhin hat der Darrel gebeten, Flo zur Kapelle zu bringen. Nach seiner "Mission" erscheint Darrel mit dem Spruch "Du schon wieder" in
meiner Party.
Danach sofort crash.

[Gorro der Grüne]

Das hatte ich jetzt zum 5 oder 6 mal

[smilingassassin]

Da laufen 2 Diskussionen parallel ab; ich bleibe mal bei der einen:

@smili & starwalker

Nur ein Versuch eines Laien, Licht in die Sache zu bringen.
Vielleicht ist es wichtig, mitzuteilen, wie es genau zu dem crash gekommen ist:

Wenn ich bisher im Rahmen von Tests für PCM den Hicks einen 'Besuch' abgestattet habe, war ich wenigstens in einem Sektor von Cambria, wenigstens in dem, in dem sich Keith Hemps befindet.
Dieses mal bin ich direkt in den Sektor G 9 gegangen (mit <Strg><t>, weil ich den crash testen wollte. Es wurde also nicht die für die Quest relevante Stadt berührt. Ich habe Flo von MERC verpflichtet und sie mit dem alten Hick verkuppelt. Daraufhin hat der Darrel gebeten, Flo zur Kapelle zu bringen. Nach seiner "Mission" erscheint Darrel mit dem Spruch "Du schon wieder" in
meiner Party.
Danach sofort crash.

ja, das ist einer der drei bisher bekannten Fälle, die anderen beiden sind eagle und Slay in Vengeance-1.13, jeweils beim anheuern.

Intuitiv bekommt man das Gefühl, dass die fragliche assertion fälschlicherweise beim zeitpunkt des rekrutierens eines rpc's aktiviert wird. Ein check zur Zugehörigkeit zu einem "town" macht u.A. dann Sinn, wenn man einen NPC attackiert und dadurch das mit ihm verbunden dorf sich hinsichtlich der Loyalität negativ entwickelt, oder wenn spezielle npc aktionen laufen, die die loya verändern. sie macht aber beim rekrutieren eines RPC's keinerlei Sinn, insbesondere darf es keine Rolle spielen, ob ein RPC irgendwo in der Pampa mit einem Dorf irgendwie in Verbindung steht. Es gibt keinen logischen grund, warum ein neues Teammitglied einen Bezug zu einem Dorf braucht, genausowenig wie AIM oder MERC charaktere einen haben.

Fehlerhaft ist also höchstwahrscheinlich der neue code, der beim anheuern fälschlicherweise diese assertion aktiviert. Der Code ist noch nicht sehr alt, in space viking's beta 5 ist er noch nicht drin, in beta 7 schon, da ist also ein kurzer Zeithorizont in dem der fehler eingeführt wurde

[Sam Hotte]

Intuitiv bekommt man das Gefühl, dass die fragliche assertion fälschlicherweise beim zeitpunkt des rekrutierens eines rpc's aktiviert wird. Ein check zur Zugehörigkeit zu einem "town" macht u.A. dann Sinn, wenn man einen NPC attackiert und dadurch das mit ihm verbunden dorf sich hinsichtlich der Loyalität negativ entwickelt, oder wenn spezielle npc aktionen laufen, die die loya verändern. sie macht aber beim rekrutieren eines RPC's keinerlei Sinn, insbesondere darf es keine Rolle spielen, ob ein RPC irgendwo in der Pampa mit einem Dorf irgendwie in Verbindung steht. Es gibt keinen logischen grund, warum ein neues Teammitglied einen Bezug zu einem Dorf braucht, genausowenig wie AIM oder MERC charaktere einen haben.

Ich kann mir schon einen Gründe vorstellen, warum ein RPC mit einem Dorf in Verbindung stehen können soll. Bleistiftsweise könnte man damit realsieren, daß Dorf X dem Spieler mehr oder weniger freundlich gesonnen ist, wenn er RPC Y in seinem Kader hat.

Ob das allerdings gewolltes Feature sein könnte, vermag ich nicht zu sagen.
Falls ja, müßte es jedoch irgendjemanden geben, der das eingebaut hat und es daher auch debuggen oder sagen können müßte, wie man damit beim modden umzugehen hat.

[Fan]

@smili,

als Ergänung:
ein erneuter Versuch, dieses Mal als allererste "Amtshandlung" in Arulco = Rekrutierung von Fox und Verkupplung mit
dem alten Hick: Abbruch mit demselben Fehler.

[smilingassassin]

aber in dem moment, als darrell dem team beitreten will, oder?

denn das ist der entscheidende Moment. Das prozedere davor ist egal, ich könnte einen solchen crash auch für ander RPC verursachen

[Fan]

aber in dem moment, als darrell dem team beitreten will, oder?

Ja, genau in dem Moment wie bei Flo. Es läuft alles ab wie erwartet, dann meldet sich Darrell im Team mit seinem Spruch
und das war's dann.

[Starwalker]

Ich denke, es gibt durchaus RPCs, bei denen bei der Rekrutierung die Town Loyalty eine Rolle spielt, man denke da mal an Dynamo. Deswegen die Assertion. Die sitzt ja vor einer Funktion, die nicht mit falschen Werten gefüttert werden soll.

Die Assertions sind allgemein 'an' oder 'aus', man kann die beim compilen nicht einzeln anwählen.

Und das Du mit b005 den Fehler nicht hast, liegt einfach daran, daß in b005 die Assertions allgemein abgeschaltet sind (SpaceViking hat da ein altes builddefine verwendet, für 007 benutzt er das neue).

Die Assertions sind momentan allgemein angeschaltet, um wenigstens Hinweise auf Fehler zu bekommen, denn der Abbruch mit Fehlermeldung ist immer noch besser als ein CTD ganz ohne Hinweis.
Und ohne die angeschalteten Assertions können Fehler im Hintergrund bleiben, ohne das man sie jemals bemerkt und korrigieren kann

Gibt's denn RPCs, die im Standardspiel eine bTownId von 0 haben?
Das Problem ist ja, daß dieser Abbruch nur bei RR stattfindet, im normalen Spiel habe ich den noch nicht gesehen.

Die Frage ist doch, was die Funktion /nach/ der Assertion macht, wenn sie einen falschen Wert bekommt, das könnte sich auch schlecht auswirken.

Es ist daher nicht sicher, ob man genau diese Assertion auskommentieren darf, oder ob eine kompliziertere Lösung gefunden werden muß (z.B. über die Funktion hinwegspringen, wenn bTownId=0).

[Starwalker]

Kann man da den Code im XML-Editor nicht dahingehend modifizeiern, dass der die ausgelagerten Lookups reinliest anstatt die aus dem hardcode zu reproduzieren, wenn der Einträge enthält, die dem Editor nicht gefallen? Ich finds an der Stelle eben merkwürdig, dass die geänderte XML von Jax immer anstandslos vom Editor akzeptiert worden ist. Wenn ich jetzt versuche eine nur leicht abgewandelte Form davon dem Editor unterzuschieben, wandelt der die trotzdem immer stumpf um. Das nervt schon sehr... von daher kann ich das Gemotze von Khor gut nachvollziehen. Von einer stable modding platform ist das jedenfalls im Moment leider noch weit entfernt.

Da musst Du RoWa21 fragen, er ist im Moment der einzige der da was ändern könnte.

Die Sache ist nun mal, wenn man eine bestimmte Grenze an items erreicht hat, dann kommt man eben mit einer so begrenzten Anzahl an verschiedenen Taschen nicht mehr hin und mir fehlen schlicht und einfach einige wichtige Taschentypen in der derzeitigen Version der silhouette.xml (z.B. die Taschen für normale Gewehrmunition (also nicht die für die Sturmgewehre sondern für Sniperrifle Munition), die Taschen für große Handgranaten (Tränengas, Senfgas, Flashbangs...), für große Pistolen, für Wurfmesser...) ohne die ich leider nicht vernünftig die LBEs bearbeiten kann. Keine Ahnung, wie Jax das hinbekommen hat, zu dem Zeitpunkt als die XML Dateien erstellt worden sind, war ich nur für die Maps zuständig und hab mir da ehrlich gesagt auch keinen Kopf drum gemacht, weil ich dachte, das passt schon...

Die Silhouetten dienen dazu zu zeigen, welcher Inhalt 'normalerweise' mit diesem Taschentyp in Verbindung gebracht wird (auch wenn eine Vielzahl anderer Dinge hineinpasst). Eine Tasche für zwei Sturmgewehrmagazine wird immer noch genauso groß sein wie eine für eine einzelne zylindrische Tränengasgranate, egal welche Silhouette da drin ist.
Es würde nur Sinn machen, das weiter zu unterteilen, wenn man mehr Restriktionen einführt, also z.B. garkeine zylindrischen Granaten in den Magazintaschen erlaubt, obwohl sie in der Realität hineinpassen.
Und jetzt (als Beispiel) dreimal dieselbe Taschengröße mit verschiedenen Silhouetten zu versehen, das halte ich für sinnfrei, deswegen haben wir es ja auch nicht gemacht.
Deswegen gibt's ja das itemsize-tag, mit dessen Hilfe man feststellen kann, wieviele Exemplare eines Gegenstandes in eine bestimmte Tasche passen.
Die Silhouetten dienen einzig und allein zur Identifikation des Taschentyps und haben mit dem Inhalt eher wenig zu tun. Wir hätten auch alles mit verschiedenen Versionen der 'general pocket'-Silhouette zupflastern können.

Allein das Einfügen von neuen Grafiken ist eine riesen Qual. Ich hab gestern dann noch festgestellt, dass unendlich viele Item Grafiken, die im WF mod vorhanden sind, im standard 1.13 nicht vorhanden sind. Neue items einzubauen artet somit immer in mühseliger Kleinarbeit aus (allein schon deswegen, weil die Bilddateien in 3 einzelnen Dateien gespeichert werden und dann natürlich auch unter den richtigen Nummern gespeichert werden müssen). Kann man zusätzlich zu den Guns, P1, P2 und P3 Items noch weitere Kategorien einbauen? Oder eventuell die Bilder in den Kategorien sortierter zusammenstellen? Ich denke mal, man kommt um die Arbeit einfach nicht drumherum, wenn man so etwas wie eine stable modding platform erstellen möchte. Der ganze Ärger hat ja bei mir damit angefangen, dass ich nicht mehr genügend Bilder hatte, um neue items zu erstellen. Aber wie ich schmerzlich feststellen musste ist es ja in der Tat nicht so einfach, neue Bilder einfach hinzuzufügen.

Das mit dem Bilder einfügen war schon immer so, jetzt weisst Du wie es mir geht, wenn in 1.13 neue Gegenstände eingefügt werden müssen, ich habe nämlich auch keine andere Möglichkeit als diese.
Und nein, es gibt keine weiteren Kategorien, wir müssen mit Guns, P1, P2 und P3 auskommen

[Starwalker]

Das hatte ich jetzt zum 5 oder 6 mal

Bitte schick' mir ein Savegame von direkt vor dem Abbruch, und schreib' mir dazu was ich machen muss, damit der Fehler auftritt.

Die Zeile, auf die sich die Fehlermeldung bezieht, sagt mir so nichts, bezieht sich wohl auf Fenstergrößen:
Assert( ( sLeft >= 0 ) && ( sTop >= 0 ) && ( sLeft + sWidth <= SCREEN_WIDTH ) && ( sTop + sHeight <= SCREEN_HEIGHT ) );

Ist Dein System up-to-date, was die Interfacegrafiken betrifft?

[Gorro der Grüne]

Ich hatte nie ein"enges" save davor. Der Fehler war bisher nicht nachvollziehbar. Werde mich beim nächsten mal bemühen.

[smeagol]

Da musst Du RoWa21 fragen, er ist im Moment der einzige der da was ändern könnte.
Das mit dem Bilder einfügen war schon immer so, jetzt weisst Du wie es mir geht, wenn in 1.13 neue Gegenstände eingefügt werden müssen, ich habe nämlich auch keine andere Möglichkeit als diese.
Und nein, es gibt keine weiteren Kategorien, wir müssen mit Guns, P1, P2 und P3 auskommen

Rowa ht sich dazu ja schon im BP geäußert und will den XML editor wohl dahingehend angleichen, was ich übrigens mal richtig gut finde.

Jo, das mit den Bildern ist wirklich lästig. Du hast mein aufrichtiges Mitgefühl. Wenn man das mal selber probiert hat, weiss man die Arbeit viel mehr zu würdigen.

Schade, dass man da keine weitere Kategorien einbauen kann, würde etwas Ordnung in das Chaos bringen.

Mit den Silhouetten ist mir schon klar, dass die nur der optischen Unterstützung dienen. Durch unterschiedliche Silhouetten ist es aber nun mal auch möglich unterschiedliche Taschen zu spezifizieren, ohne dass es für den Endnutzer verwirrend wird, weil alle Taschen das gleiche Pic haben (wie das ja im DBB Mod in übertriebener Form geschehen ist. Den DBB Mod find ich dahingehebd aber auch etwas zu weit ausufernd. Mal ehrlich, eine Unterscheidung von Taschen für ein AK Magazin und zwei AK Magazine in Abgrenzung zu Magazinen für Nato Waffen? WTF. Man kanns auch übertreiben! Mir schwebt da dann doch eher ein Kompromiss zwischen standard 1.13 und DBB vor. Die Lösung die sich Jax für den WF Mod ausgedacht hat gefiel mir jedenfalls ganz gut, und ähnliches schwebt mir für eine Überarbeitung auch vor).

So, bis der Editor fertig ist, zocke ich weiter Port Royale 2.

[Fan]

@smeagol
Da Du gerade online bist:
Weiter oben wollte ich von Dir schon wissen....

Das Allinone5 mit Euren Internationalen WF - Karten (WF6.06-Mod-beta.international...) dürfte doch funktionieren, oder?

MfG...

[Starwalker]

Das hatte ich jetzt zum 5 oder 6 mal

Bitte schick' mir ein Savegame von direkt vor dem Abbruch, und schreib' mir dazu was ich machen muss, damit der Fehler auftritt.

Die Zeile, auf die sich die Fehlermeldung bezieht, sagt mir so nichts, bezieht sich wohl auf Fenstergrößen:
Assert( ( sLeft >= 0 ) && ( sTop >= 0 ) && ( sLeft + sWidth <= SCREEN_WIDTH ) && ( sTop + sHeight <= SCREEN_HEIGHT ) );

Ist Dein System up-to-date, was die Interfacegrafiken betrifft?

Da man ja nicht lange genug editieren kann, muss ich mich mal selber zitieren

Tritt der Fehler denn immer auf, wenn das Vehicle Inventory offen ist, oder auch zu anderen Gelegenheiten?

[Gorro der Grüne]

Nachdem ich mich ja zur aussterbenden Spielergattung der Diebe bekenne muß ich jetzt maulen.

Mit den 100 AP gibt es ein Problem ohne Granaten ist Ausrauben nur noch in einem Zug oder mit Inkaufnahme gravierender Verletzungen machbar.


1) Egal ob der Rotarsch nachdem er umgehauen wurde 1 oder 6 Faustschläge mitbekommt nachdem er lag - er steht immer wieder auf und sticht einen ab.
(ohne Messer boxt er)
Das gilt für 1, 2, 3, 4, 5 und 6 Schläge auf den am Boden liegenden.


2) Selbst wenn er keine Müffeltüte aufhat und jeweils direkt von VG und TG (Handgranatenversionen) getroffen wird. stehen 50% wieder auf und versuchen zu türmen.
Für 40mm kann ich noch nix sagen, da ich gerade zum ersten mal welche dabeihabe.

[Gorro der Grüne]

Mindestens einmal in Drassen Mine - gefühlt etwa 50:50

Installation ist: Gold / englischer Installer aus Scheins post / Many Mercs / Smilis Basismode

Verwendete Echse: 7b

[smilingassassin]

Ich denke, es gibt durchaus RPCs, bei denen bei der Rekrutierung die Town Loyalty eine Rolle spielt, man denke da mal an Dynamo. Deswegen die Assertion. Die sitzt ja vor einer Funktion, die nicht mit falschen Werten gefüttert werden soll.

Die Assertions sind allgemein 'an' oder 'aus', man kann die beim compilen nicht einzeln anwählen.

Und das Du mit b005 den Fehler nicht hast, liegt einfach daran, daß in b005 die Assertions allgemein abgeschaltet sind (SpaceViking hat da ein altes builddefine verwendet, für 007 benutzt er das neue).

Die Assertions sind momentan allgemein angeschaltet, um wenigstens Hinweise auf Fehler zu bekommen, denn der Abbruch mit Fehlermeldung ist immer noch besser als ein CTD ganz ohne Hinweis.
Und ohne die angeschalteten Assertions können Fehler im Hintergrund bleiben, ohne das man sie jemals bemerkt und korrigieren kann

Gibt's denn RPCs, die im Standardspiel eine bTownId von 0 haben?
Das Problem ist ja, daß dieser Abbruch nur bei RR stattfindet, im normalen Spiel habe ich den noch nicht gesehen.

Die Frage ist doch, was die Funktion /nach/ der Assertion macht, wenn sie einen falschen Wert bekommt, das könnte sich auch schlecht auswirken.

Es ist daher nicht sicher, ob man genau diese Assertion auskommentieren darf, oder ob eine kompliziertere Lösung gefunden werden muß (z.B. über die Funktion hinwegspringen, wenn bTownId=0).

Nein, das Problem tritt in RR nicht auf, lies doch meine postings einmal durch und nein, in dem moment, in dem ein RPC ins Team kommt, spielt NPC town keine Rolle, das ist barer Unsinn. Dynamo's loyalty boost funzt über ein npc script bei Matt und nicht aarrggggghhhh...

...einfach mal lesen wäre so hilfreich.

Nochmal: Früher war es anders
Früher war es korrekt

und zu assertions: Crashes nerven. In b5 hatte ich KEINEN crash. Denn da war auch kein relevanter Fehler vorhanden. Wenn man crashes nur aufgrund der assertions einfügt ist niemandem geholfen.

Ich kann mir vorstellen, dass diese assertion in anderen situationen Sinn macht, deswegen muss man sich überlegen, wie man das problem sinnvoll umgeht.


@scheinworld

dein crash als carmen dir die diskette geben will ist wegen Perko. Benutze Perko nicht um gegenstände von NPC's zu bekommen, benutze einen anderen charakter bis evtl. jemand das problem behoben hat (was gar nicht anzunehmen ist, das es je passiert)

[Starwalker]

Also:

- Es ist offensichtlich eine Funktion eingebaut, die bei der Rekrutierung einen Zusammenhang mit Town Loyalty sucht oder herstellt
- Es wurde ebenfalls eine Assertion eingefügt, damit die Funktion nicht mit fehlerhaften Werten beliefert wird
- Diese Assertion war abgeschaltet, weil der Code so compiled wurde, daß die Assertions unberücksichtigt blieben
Und ich vermute dies geht alles auf die Originalentwickler zurück.

Was das 1.13-Team gemacht hat ist, diese Assertions jetzt zu berücksichtigen, um der Fehler Herr zu werden.

Das Du keine Fehler bemerkst, wenn die Assertion abgeschaltet ist, bedeutet nicht daß der Fehler nicht trotzdem passiert, Du bemerkst ihn bloß nicht.
Die Assertions sind ja gerade dazu da, Fehler aufzuspüren, die sonst unbemerkt bleiben. In Deinem Fall ist /immer/ ein Fehler passiert, nur hast Du ihn ohne Assertion nicht bemerkt. Ob und wie der Fehler sich dann auswirkt kann ich ohne Kenntnis des codes aber nicht sagen.

Die Assertions sind 'Quality Control', und wir brauchen sie um bugs abstellen zu können. Und Du willst jetzt, daß wir sie abstellen und die Fehler im code lassen?

Das ist ungefähr so als würdest Du dich beschweren, das wir ein Minenfeld mit Fähnchen markieren um die Minen räumen zu können, bloß weil Du selber bisher unbeschadet durch das Minenfeld gekommen bist, und es ist Dir egal ob andere auf Minen treten.

Das Dynamo's Loyalty-Boost über Matt's Skript funktioniert hattest Du bisher jedenfalls nicht geschrieben. Was glaubst Du denn was ich alles über JA2's Programmierung weiß? Herzlich wenig, denn das ist auch nicht meine Aufgabe.

Was den Bezug zu RR betrifft, so nahm ich an daß das in RR war. Also Korrektur: Dieser Fehler tritt nur bei Deinen Projekten auf.

Ich muß erstmal über Chris und SV herausbekommen, was die Funktion hinter der Assertion macht, und ob man die Assertion nicht unbeschadet entfernen oder die Funktion im Falle bTownId=0 einfach überspringen kann.

[Scheinworld]

Ich muß erstmal über Chris und SV herausbekommen, was die Funktion hinter der Assertion macht, und ob man die Assertion nicht unbeschadet entfernen oder die Funktion im Falle bTownId=0 einfach überspringen kann.

@ Starwalker: Vielen Dank für deine Bemühungen und Schilderungen in den jeweiligen Threads!

@scheinworld

dein crash als carmen dir die diskette geben will ist wegen Perko. Benutze Perko nicht um gegenstände von NPC's zu bekommen, benutze einen anderen charakter bis evtl. jemand das problem behoben hat (was gar nicht anzunehmen ist, das es je passiert)

@ Smili: Für einen "Posting-Passiven" bist Du anscheinend noch sehr aktiv im BP. Du hattest jedenfalls Recht, ich habe anschließend mit Reaper Carmen angesprochen. Er gab mir die Diskette und Machete, ich eilte zu Slay, den ich per Proedit in den Nachbarsektor (G8) eingestellt hatte und er ließ sich erfolgreich rekrutieren. Allerdings nicht per Übergabe der Diskette, sondern er musste angegriffen/verarztet werden. Das hat mich daran erinnert, die veränderte 064.NPC Datei des russischen Patches für das Paket zu übernehmen.

Screenshot:


Apropos Perko, seine Gesichtsanimationen funktionieren auch nur mit deiner angepassten EXE: B007b.exe und nicht mit SpaceVikings Original EXE: ja2_release_SV_B007b.exe. Also Manuels, Spookys und Perkos Face Koordinaten sind in deiner EXE bestimmt, ja?

Installation ist: Gold / englischer Installer aus Scheins post / Many Mercs / Smilis Basismode

Verwendete Echse: 7b

@ Gorro: Die 7b basiert allerdings schon auf der 2445er EXE, während die Gesamtpakete auf die Verwendung der 2436er ausgelegt sind. Vielleicht solltest Du per SVN den \Data\Fonts Ordner updaten? Wie auch immer, entgegen meinen eigentlichen Vorsätzen werde ich ein allinone6 Paket uploaden, sobald ein paar Probleme mit der Verwendung von den RPCs ausgeräumt wurden und/oder der XML Editor von Roman angepasst wurde. Am liebsten würde ich es gleich mit integriertem PCM von Smili "liefern", aber momentan ist diese Kombination einfach derart Absturz gefährdet, dass es keinen Sinn machen würde.


Gruß und auf bald; Schein…

[Gorro der Grüne]

3 Trüppchen sehr eng aufeinander

- 3 Vacuum (HG) mittenrein, eine Träne dazu (genau auf den einen ohne Gasmaske)
- die 2 mit Gasmaske bekommen jeder noch eine mit
- eine von den Masken wird ausgeraubt
nächster Zug
- der ausgeraubte und der ohne Maske springen auf
- der ohne Maske bricht am Rande des Tränengases zusammen
- der ausgeraubte wird mit der eigenen Waffe erschossen
- der ohne Maske bekommt eine gewischt
- der 3 Mann wird beraubt und bekommt dann Igors Messer gezeigt.
nächster Zug
- das Gas hat den unbemaskten Herrn erreicht
- der Kerl springt wieder auf
nächster Zug
- Igor langt ihm ein paar
- Dimitri raubt ihn aus
anstelle ihn zu meucheln, sichere ich und schau was kommt
nächster Zug
- der Depp springt auf und flüchtet über die innerarulcanische Sektorengrenze.

Zur Strafe wurde er dort nochmal ausgeraubt.

imho sollte das so nicht möglich sein

[smeagol]

@smeagol
Da Du gerade online bist:
Weiter oben wollte ich von Dir schon wissen....

Das Allinone5 mit Euren Internationalen WF - Karten (WF6.06-Mod-beta.international...) dürfte doch funktionieren, oder?

MfG...

Könnte lediglich Probleme mit einigen Ingame Items geben, das hab ich aber noch nicht getestet. Prinzipiell müsste es gehen. Hab übrigens auch zu einigen Karten bereits updates angefertigt, da gab es in einigen Karten kleine Unstimmigkeiten (z.B. in dem nordöstlichen Meduna Sektor, da gibt es auf der Weltkarte eine Straßenverbindung nach Norden, die aber nicht in der taktischen Karte vorhanden war...). Wenn ich mit dem XML editieren fertig bin, werde ich auch mal ein Update von den Maps hochladen (da gibt es dann unter anderem auch den Jeep in A10).

[Gorro der Grüne]

Die Herrschaften sind nicht auf der Flucht.

[insert_name]

Bei deiner langweiligen Spielweise ist doch klar, dass die Söldner reihenweise wegratzen.

[Scheinworld]

So, bis der Editor fertig ist, zocke ich weiter Port Royale 2.

@ smeagol: Da blieb Dir aber nicht viel Zeit, um "fremdzugehen".

Link: http://www.ja-galaxy-forum.com/board/ub ... Post203689


Gruß und frohes Schaffen; Schein...

[Gorro der Grüne]

Parken: Nach der weiter oben dargestellten arulcanischen Brillianz zum Thema Architektur nun ein Beispiel des autofahrerischen Könnens.

G13: dabei liegen da schon 7 Tote rum

[smilingassassin]

scheinworld

die probleme beim rekrutieren von rpc's kann ich sehr einfach beheben, das ist kein problem, ich will nur die falsche/ falsch eingestellte/ sinnlose assertion weghaben, damit man wieder normal arbeiten kann. Es könnte durchaus sein, dass auch andere Ports davon betroffen wären.

Ich lese noch regelmässig im BP, habe aber bald mehr User auf Ignore als andere

das problem bei Perko ist, dass er auch nach dem rekrutieren händler bleibt. Versuch mal, ihm was zu geben oder so, dann bekommst du evtl. das reparatur interface. Bei Devin isses iirc ähnlich, versuch doch mal, auch devin in dieser weise zu testen, e.g. geh mit devin zu skipper, gib ihm etwas, daraufhin wird die skipper die keycard geben, was auch ne assertion verursachen könnte.

starwalker

Was nützen uns bitte diese sinngeladenen aussagen wie "dann tritt es nur bei deinen projekten auf"?

Im ernst jetzt, ich habe sogar angeben, wie ihr das in vanilla ja2 1.13 rekreiieren könnt, geschweige denn die paar lächerlichen megas PCM runterzuladen. Das sollte längst gelöst sein. Und quality control bedeutet nicht, dass man Dinge, die gar nicht kaputt sind, versucht zu reparieren (und damit crashes verursacht). Aber das ist ja ein problem, dass schon länger grassiert

[Gorro der Grüne]

Hochschrauben der Garnisionsstärke + Nachrücken kann zu Problemen führen


Ich habe nur Drassen-Airport und Mine

[Scheinworld]

scheinworld

die probleme beim rekrutieren von rpc's kann ich sehr einfach beheben, das ist kein problem, ich will nur die falsche/ falsch eingestellte/ sinnlose assertion weghaben, damit man wieder normal arbeiten kann. Es könnte durchaus sein, dass auch andere Ports davon betroffen wären.

@ Smili: Ich verstehe Dich schon und ich hätte deinen PCM lieber heute als morgen mit dabei (am besten alles in einem Paket), aber ich bin mir nicht sicher, wie ich Dir dabei helfen könnte? Mir würde ja auch nichts anderes übrig bleiben, als SpaceViking im BP "anzubetteln", dass er seine letzte EXE: ja2_release_SV_B007b.exe dahingehend anpasst, zumindest als Alternativ EXE, aber warum sollte er das für MICH tun?!? Ich hoffe, dass Starwalker in Absprache mit ChrisL dahingehend ihren Einfluss ausüben, falls man das überhaupt so ausdrücken kann.

Ich lese noch regelmässig im BP, habe aber bald mehr User auf Ignore als andere

Steht SpaceViking etwa auch auf deiner Ignorier-Liste? Wenn nicht, dann könntest Du ihn doch vielleicht per PM davon überzeugen. Dein Name hat doch dort immer noch einen wesentlich klangvolleren Namen als meine Wenigkeit.


Beste Grüße; Schein…

[smeagol]

So, bis der Editor fertig ist, zocke ich weiter Port Royale 2.

@ smeagol: Da blieb Dir aber nicht viel Zeit, um "fremdzugehen".

Link: http://www.ja-galaxy-forum.com/board/ub ... Post203689


Gruß und frohes Schaffen; Schein...

Hehehe.

Bin bis gearde eben sozusagen "fremdgegangen". War jedenfalls recht erfolgreich und mal eine nette Abwechslung. Die e-mail an Roman ist jedenfalls schon raus. Dann kann ich ja direkt morgen loslegen. *jubel*

[Starwalker]

imho sollte das so nicht möglich sein

Vermutlich verlieren die nicht genug Breath Points im Nahkampf. Ich habe ChrisL angeschrieben, damit er sich das mal ansieht.

[Starwalker]

Was nützen uns bitte diese sinngeladenen aussagen wie "dann tritt es nur bei deinen projekten auf"?

Es sagt genau das: Das Problem tritt nirgendwo sonst auf.

Im ernst jetzt, ich habe sogar angeben, wie ihr das in vanilla ja2 1.13 rekreiieren könnt,

Brauchen wir ja nicht, nachdem Du endlich gesagt hast, das Darrel eine bTownId von Null liefert.

geschweige denn die paar lächerlichen megas PCM runterzuladen. Das sollte längst gelöst sein. Und quality control bedeutet nicht, dass man Dinge, die gar nicht kaputt sind, versucht zu reparieren (und damit crashes verursacht). Aber das ist ja ein problem, dass schon länger grassiert

Woher weisst Du, daß das garnicht kaputt ist? Wenn wir keine detaillierte Analyse von der Funktion haben, die von der Assertion geschützt wird, dann müssen wir selber erstmal prüfen was da passiert. Vorher können wir die Assertion nicht abändern. Die Assertions sind ja nicht umsonst von den Originalentwicklern eingebaut worden, sondern weil sie Fehler befürchteten, auch wenn diese dann eher von ihrem eigenen miesen Code verursacht worden wären.

Ich gewinne langsam den Eindruck, Du willst garkeine Hilfe, sondern nur meckern, und hilfreiche Informationen lieferst Du nur häppchenweise.

Wieso versuche ich eigentlich immer noch, Dir zu helfen?

[Fan]

@smili u. Starwalker

vertragt Euch im Interesse des Forums. Ich habe PCM_PLUS mit B005 getestet und es lief einwandfrei.
Schön für den Modder. Umso ärgerlicher, jetzt feststellen zu müssen, dass es mit einer Fortentwicklung der
Exe nicht mehr läuft. Ist doch verständlich oder? Ist auch verständlich, dass man die neuen Features nutzen
möchte. Also wo ist die Lösung?
Wenn es nicht anders geht, gebt halt die Assertions für B007b frei. Das geht doch oder nicht?
Ich teste das und mache bei Fehlern keinen Aufstand, sondern registriere sie einfach nur wie bei
Darrell geschehen.

Nach meinen Feststellungen funktionieren die Eingliederungen der RPC bis auf Darrell alle.
Zur Not dann eben ohne Darrell. Wenn ich die neuen Ja2_Options nutze, kann ich insgesamt 32 Söldner beschäftigen.
Da kommt es auf einen nicht mehr an, auch wenn dieser nichts kostet. Dafür habe ich dann Manuel und Spooky.

Wenn dann smeagol noch feststellt, dass die neuen Features mit den internationalen WF6.06 - Karten, die schwerer sind
als die normalen Ja2 - Karten, funktionieren, dann kann man doch zufrieden sein.

[Starwalker]

@smili u. Starwalker

vertragt Euch im Interesse des Forums. Ich habe PCM_PLUS mit B005 getestet und es lief einwandfrei.
Schön für den Modder. Umso ärgerlicher, jetzt feststellen zu müssen, dass es mit einer Fortentwicklung der
Exe nicht mehr läuft.

Aber das ist es doch gerade: Es gab keine Fortentwicklung in Bezug auf Smilies Fehler, es wurden lediglich die bereits existierenden Hilfsmaßnahmen zur Fehlersuche wieder eingeschaltet, die die Originalentwickler abgeschaltet hatten.

SpaceViking erstellt eine Version 007c seiner exe, in welcher die Assertion abgeändert wird, so daß der Fehler mit PCM nicht mehr auftreten sollte. Das heisst aber nicht, daß damit ein Fehler beseitigt ist, er wird nur ignoriert, in der Hoffnung das er keinen Schaden anrichtet.

[smilingassassin]

scheinworld

erstens: du hast eine viel höhere chance von space viking etwas konstruktives zu hören als Ich. Der hat mir nicht einmal geantwortet, als ich ihm endlich den dummen Patch gebastelt hatte, um den er mich mehrfach angebettelt hat. Möglicherweise hat er mich auf ignore, umgekehrt nicht, obwohl fast alle posting von ihm, die sich nciht strikt auf code beziehen, durchaus ignore-würdig sind.

Starwalker

"wissen" ist immer relativ. Aber ich sage mal so: wenn in allen exe's von ja2, die ich jeh gesehen habe, das verwenden von npc town none bei RPC's mit einem durch prof.dat festgelegten sektor auch ausserhalb von städten NIE irgendeinen merkbaren Fehler produziert haben, dann ist da höchstwahrscheinlich auch keiner. Man spricht in dem zusammenhang methodisch auch von Okkam's razor.

ich weiss, dass ihr bei meinen Bugreports ja immer speziell reluctant sind, den arsch hochzukriegen, weil meine bug reports immer eine tolle Möglickeit darstellen, mir eine reinzuwürgen, aber ich versuch es noch ein letztes mal sachlich:

Die Original Entwickler haben nur zwei sorten von RPC's: entweder RPC's in Städten, die durch Prof.dat in einen spezifischen Sektor definiert werden oder RPC's ausserhalb von Städten, die dann per hardcode definniert sind und Npc town 0 haben (weil sie nicht zu einer Stadt gehören)
Nun gibt es in fast jedem Mod auch RPC's, die, in ermangelung der möglichkeit neuen hardcodes, auch ausserhalb von Städten durch prof.dat definiert sind und nicht durch hardcode.

Eure Annahme, dass eine solche Situation einen Fehler darstellt, entbehrt jeglicher Grundlage (namentlich konntest du in zahllosen postings nciht einen Grund, nicht einmal eine Annahme liefern) ist im Lichte der unzähligen exe's, die fehlerlos funktioniert haben, offensichtlich haltlos und wirk geradezu lächerlich und schikanös demjenigen gegenüber, der den Bug entdeckt hat (aus persönlichen Animositäten, denke ich)

Viel wahrscheinlicher ist, dass die original Devs gar nicht an diese Konstellation, die sie selbst nciht hatten, gedacht haben. Sie haben also eine andere Situation (NPC fest definiert ausserhalb einer Stadt) nicht extra geregelt, sonder einfach die Funktion für NPC's in stadtsektoren verwendet (Sie hatten ja auch keinen Grund dazu, wenn man ihnen hier keine Faulheit unterstellen will)
Diese Funktion ist ausserhalb von Städten aber u.U völlig unsinnig, insbesondere dann, wenn ein NPC gar keiner Stadt zugeordnet sein soll (z.B. ein Einsiedler in der Pampa, oder ein untergetauchter Terrorist wie slay in vengeance 1.13)

Nachdem Vergangenheit und gegenwärtige Wahrscheinlichkeit sich sehr eindeutig äussern, können wir auch in die Zukunft sehen

Stell dir vor, jemand mach einen Mod mit 15, 20, 50 Einträgen in cities.xml
Und dieser jemand will auch RPC's in diesen Städten haben.

Eure Assertion wird ihn dazu zwingen, diese RPC's anderen Städten zuzuordnen als sie überhaupt sind, weil die assertion nur 1-12 (oder 0 bis 12 was weiss ich) Werte akzeptiert, der RPC aber möglicherweise in Town ID 25 steht.

Auch für diese Situation (z.B. in RR für Convert eine denkbare, müsste ich testen) taugt eure assertion in keiner Weise, ist grob unsachgemäss und fehlerhaft.

Es ist reine Schikane eurerseits, das überhaupt mit mir zu diskutieren, denn es steht von vornherein ausser frage, dass dieser falsche Code in Ordnung gebracht werden muss, und man hier nicht einfach das einhalten der koinzidenzen des vanilla spiels in proedit von den usern verlangen kann.

Aber ich sehe schon, meine Bugreports werden von euch generell mit extrem viel zurückhaltung aufgenommen

Ich werde also von jetzt an Bugreports in anderer Weise kommunizieren müssen, oder ich lasse einfach die Spieler wie Fan oder Scheinworld die Suppe auslöffeln, die ihr ihnen einbrockt, die werden sich sicher freuen

Fan

kannst du bei hoenir wieder hochladen? Weil dann können wir PCM basic und plus mit workarounds gegen diesen crash schützen.

Für einen persönlcihen workaround kann ich dir auch die neuste prof.dat schicken (oder wer sonst PCM mit assertions spielen will)


im Bezug auf das letzte Posting

Das ist schlicht unwahr. Ihr kreiiert einen Crash wo zuvor keiner war. Ihr verunmöglicht damit das Nutzen von darrell und damit das testen evtl. weiterer Aspekte im Zusammenhang von RPC 73. Das ist das Gegenteil von quality control

[Fan]

Fan

kannst du bei hoenir wieder hochladen? Weil dann können wir PCM basic und plus mit workarounds gegen diesen crash schützen.

Für einen persönlcihen workaround kann ich dir auch die neuste prof.dat schicken (oder wer sonst PCM mit assertions spielen will)

Unter ja2/hoenir.de --->Downloads u.s.w. sind schon PCM Basic und PCM hochgeladen, allerdings nicht von mir.

Da es offenbar nur Darrell wegen der Assertion betrifft, würde da nicht eigentlich schon "Basic" genügen?

Selbstverständlich kannst Du mir auch die neuste Prof.dat schicken zum Testen. Kein Problem.

[Starwalker]

Eure Annahme, dass eine solche Situation einen Fehler darstellt, entbehrt jeglicher Grundlage (namentlich konntest du in zahllosen postings nciht einen Grund, nicht einmal eine Annahme liefern) ist im Lichte der unzähligen exe's, die fehlerlos funktioniert haben, offensichtlich haltlos und wirk geradezu lächerlich und schikanös demjenigen gegenüber, der den Bug entdeckt hat (aus persönlichen Animositäten, denke ich)

Die Originalentwickler haben eine assertion eingebaut, die das was Du machst abfangen sollte. Also haben die Originalentwickler ein fehlerhaftes Verhalten in dieser Situation befürchtet, und das reicht uns erstmal, weil keiner von uns sich mit dieser CPP-Datei bisher näher beschäftigt hat.

Viel wahrscheinlicher ist, dass die original Devs gar nicht an diese Konstellation, die sie selbst nciht hatten, gedacht haben. Sie haben also eine andere Situation (NPC fest definiert ausserhalb einer Stadt) nicht extra geregelt, sonder einfach die Funktion für NPC's in stadtsektoren verwendet (Sie hatten ja auch keinen Grund dazu, wenn man ihnen hier keine Faulheit unterstellen will)
Diese Funktion ist ausserhalb von Städten aber u.U völlig unsinnig, insbesondere dann, wenn ein NPC gar keiner Stadt zugeordnet sein soll (z.B. ein Einsiedler in der Pampa, oder ein untergetauchter Terrorist wie slay in vengeance 1.13)

Exakt, die Originalentwickler wussten nicht, was Du 9 Jahre später versuchen würdest!
Und deshalb musst Du das 1.13-Team beschimpfen und arrogant Änderungen am Originalcode in Deinem Sinne verlangen?

Nachdem Vergangenheit und gegenwärtige Wahrscheinlichkeit sich sehr eindeutig äussern, können wir auch in die Zukunft sehen

Stell dir vor, jemand mach einen Mod mit 15, 20, 50 Einträgen in cities.xml
Und dieser jemand will auch RPC's in diesen Städten haben.

Eure Assertion wird ihn dazu zwingen, diese RPC's anderen Städten zuzuordnen als sie überhaupt sind, weil die assertion nur 1-12 (oder 0 bis 12 was weiss ich) Werte akzeptiert, der RPC aber möglicherweise in Town ID 25 steht.

Auch für diese Situation (z.B. in RR für Convert eine denkbare, müsste ich testen) taugt eure assertion in keiner Weise, ist grob unsachgemäss und fehlerhaft.

Begreifst Du immer noch nicht, daß das /nicht/ unsere Assertions sind? Die sind von den /Originalentwicklern/ eingebaut worden an Stellen, die sie schutzwürdig fanden, und später nicht mehr benutzt worden.
Außerdem steht in der Assertion für das Maximum der Wert NUM_TOWNS, und wenn jemand 25 Städte in cities.xml definiert, dann ist NUM_TOWNS auch 25.

Es ist reine Schikane eurerseits, das überhaupt mit mir zu diskutieren, denn es steht von vornherein ausser frage, dass dieser falsche Code in Ordnung gebracht werden muss, und man hier nicht einfach das einhalten der koinzidenzen des vanilla spiels in proedit von den usern verlangen kann.

Dann beschwere Dich bei den Originalentwicklern!
Wir sind nämlich für den 'falschen' Code nicht verantwortlich.
Im übrigen ist er nicht 'falsch', sondern lediglich für Deine Zwecke ungeeignet.

Bis jetzt hatte ich ja nichts gegen Dich, obwohl Du hier mehrfach bestehende Animositäten herbeibeschwörst, aber ab jetzt hast Du von mir garnichts mehr zu erwarten.

[smilingassassin]

ich habe von dir schon seit Monaten nichts mehr erwartet, und diese Erwartungen hast du damit noch untererfüllt, dass du falsche und Dumme dinge getan hast (schlichte inaktivität wäre jederzeit vorzuziehen gewesen)

1. NEIN. Die entwickler kannten die situation nicht und die assertion wurde zufällig auch für diese, OFFENKUNDIG falsche situation verwendet. Das habe ich im Detail erklärt. Du hast immer noch nicht irgendeinen noch so schwachen Anschein geliefert, dass sie das bewusst gemacht hätten. Allerdings sprechen alle bereits diskutierten Elemente dagegen. Du gehst von einem gewollten Zusammenhang aus, was offenkundig nur eine Inzidenz ist. Wer einen Zusammenhang behauptet, muss ihn auch nachweisen, alles andere ist eine leere Behauptung.

Das etwas im originalspiel nicht vorkommt, heisst noch lange nicht, dass es falsch sein muss. Wenn ich in proedit einen söldner oder npc von Billy auf Bobby umbenenne, und das zu fehlern führt, kannst du mit der gleicher erbärmlichkeit behaupten, das gehe euch nichts an, weil es nicht "in the book" ist. Der code ist dann trotzdem falsch und zu korrigieren, egal ob von den ja2 entwicklern oder von 1.13.


2. Proedit kennt keine 25 Städte. Alle NPC Town werte werden in proedit definiert. Was du also von dir gegeben hast, ist mit Verlaub, im Bezug auf Proedit absoluter, grober Unfug. Und es geht hier nur um Proedit, da bisher keine andere occurence von dieser assertion bekannt ist. Nur weil ihr grossmäuler prof.dat trotz regelmässiger Behauptungen zum gegenteil immer noch nicht externalisiert habt, könnt ihr nicht einfach so tun als ob und damit crashes verursachen.

3. Das sind eure assertions, weil sie im Originalcode abgeschaltet sind und Ihr sie wieder angeschaltet habt, ohne zu wissen, was ihr da macht. Es gibt wohl genauso gute Gründe, warum die Originaldevs diese assertions nach einer Testphase wieder auskommentiert haben, wie es für den Umstand des Erschaffens dieser assertions gibt.

4. Ich habe das 1.13 Team in keiner Weise angegriffen. Ich kann das niemanden persönlich zurechnen, dass meine Bugreports irgendwie immer erst mit mehrjähriger Verspätung von neuen Teammitgliedern aufgenommen und korrigiert werden, nachdem man eigentlich bereits im Detail alles geklärt hatte.

5. Wer im Glashaus sitzt, sollte nicht selbst den Begriff der Arroganz gegen andere einsetzen. Es wirkt in diesem Zusammenhang auch irgendwodurch wie ein armseliges Substitut für (mangelnde) Argumente

[Scheinworld]

@smili u. Starwalker

vertragt Euch im Interesse des Forums.

Da kann ich nur ein Ausrufezeichen drunter setzen, um dieser Hoffnung Ausdruck zu verleihen.
<<< ! >>>

Screenshots / Test der "ja2_release_SV_B007c.exe" & PCM+:


Ich muss jetzt los.


Beste Grüße und nochmal vielen Dank ; Schein…

[smilingassassin]

Gut, dass du das testen willst, Scheinworld

musst aber aufpassen, laut Starwalker und SV verursachen die Absenz von assertions probleme mindestens in der Grössenordnung von einem Weltuntergang.

Wenn also darrell ein Schwarzes Loch in deinem computer generiert, RENNE!

[Fan]

@smili,

habe mit der neuen Exe B007c gerade ohne Weltuntergang Darrell rekrutiert, allerdings als ersten RPC.
Werde jetzt damit ein ganzes Spiel testen...

...nicht ohne Dank an die "Produzenten"

[Gorro der Grüne]

@ Sternenschreiter

Schick mir ne pm mit emailadresse für save, ini und Spielbeschreibung.

Fehler war reproduzierbar

Urgs erschießt noch den Herrn unterm Fadenkreuz, danach türmt die Truppe und geht Richtung Cambria wieder rein.

[Gorro der Grüne]

das debugsav 97 ist natürlich auch dabei

Fehler tritt auch auf wenn Urgs keinen erschießt und wenn auf der Almaseite wieder in den Sektor gegangen wird.

Fehler tritt auch auf wenn ich im Nachbarsektor ankomme und dann zurück gehe. Es sind 69 Feinde im Sektor

[Gorro der Grüne]

Wenn ich bei Beginn des Angriffs raus (51 Gegner) und wieder rein gehe tritt der Fehler nicht auf
Wenn ich 2 Leute erschieße und im Normalmodus rausgehe tritt der Fehler auf (80 Gegner durch Nachrücker)

Werde jetzt mal versuchen auf unter 64 herunterzuschießen und dann schauen was passiert

[Gorro der Grüne]

Das Spiel hat offentsichtlich von Beginn an 18 Gegner zu viel angezeigt. Gegner (max) ist 64 eingestellt 82 wurden insgesamt angezeigt.

Als ich den 19.letzten gemeuchelt hatte (theor. Rest 18) war schlagartig keiner mehr da.

[Starwalker]

Das Spiel hat offentsichtlich von Beginn an 18 Gegner zu viel angezeigt. Gegner (max) ist 64 eingestellt 82 wurden insgesamt angezeigt.

Als ich den 19.letzten gemeuchelt hatte (theor. Rest 18) war schlagartig keiner mehr da.

Du hast aber nicht so eine Meldung bekommen?

[Gorro der Grüne]

Nein, hätte ich gemeldet

mail ist raus

[Fan]

Ich habe 32 Söldner engagiert bzw. rekrutiert und dabei PCM_PLUS integriert. In dem Bild kann man sehen, welche
RPC man aufnehmen kann.
Aber muss das so aussehen, dass die dafür vorgesehene Box unten einfach ignoriert wird? Kann man das Feld nicht
vergrößern?