|
Mantis - X-Force
|
|
Viewing Issue Advanced Details |
|
|
ID:
|
Category:
|
Severity:
|
Reproducibility:
|
Date Submitted:
|
Last Update:
|
|
2149 |
Bodeneinsatz |
major |
random |
29.05.09 13:39 |
05.07.09 03:00 |
|
|
Reporter:
|
Natter |
Platform:
|
|
|
|
Assigned To:
|
Natter |
OS:
|
|
|
|
Priority:
|
normal |
OS Version:
|
|
|
|
Status:
|
closed |
Product Version:
|
V0.915b01 |
|
|
Product Build:
|
|
Resolution:
|
fixed |
|
|
Projection:
|
none |
|
|
|
|
ETA:
|
none |
Fixed in Version:
|
V0.915b02 |
|
|
|
Summary:
|
0002149: Zugriffsverletzung im AI-Skript |
|
Description:
|
Das AI-Skript erzeugt manchmal eine Zugriffsverletzung, und wird dadurch vorzeitig beendet. Laut Fehlermeldung tritt der Fehler in ShotAsLongAsPossible bei Figure.WaeitForWeapObj auf. Leider konnte ich auch nach länerem Suchen die Ursache bisher nicht finden.
Das Problem ist auch nicht sicher reproduzierbar. Ich hab es im GalWar mit 2 AntiGrav-Einheiten mehrfach beobachtet, wenn ich in einem Haus in Deckung ging, und die Aliens erstmal die Wände wegschossen. Ich kann nicht sagen, ob es damit zusammenhängt. Allerdings ist das Problem bei mir noch nie beim ersten Schuss aufgetreten. |
|
Steps To Reproduce:
|
|
|
Additional Information:
|
|
| Relationships | SYSTEM WARNING: Creating default object from empty value
| has duplicate | 0002156 | closed | Natter | X-Skript | Bodeneinsatz AI Fehler | | related to | 0002189 | closed | Natter | X-Force | Fehler bei PerformWeapObjFrame (und der AI-Skriptfunktion auch) |
|
|
Attached Files:
|
 error3.png [^] (30,396 bytes) 02.06.09 05:08
error5.png [^] (116,088 bytes) 02.06.09 23:34 |
|
Notes |
|
|
(0003864)
|
|
DirkF
|
|
31.05.09 13:31
|
|
Zusatzinfo:
Die Triliir-Antigraveinheiten haben einen der höchsten ZE-Werte und gleichzeitig mit den Nadelwaffen schwächere aber besonders schnell schießende Waffen.
Es dürfte keine andere Kombination geben, die eine annähernd gleich hohe Anzahl von Schüssen pro Runde erlaubt.
Eventuell sollte man das bei der weiteren Fehlersuche im Hinterkopf behalten. |
|
|
|
(0003878)
|
|
Natter
|
|
02.06.09 04:46
|
|
So, ich hab mich jetzt mal etwas in "fortgeschrittenem Debbuging" versucht. Die Zugriffsverletzung tritt definitiv in TGameFigure.WaitForWeapObj auf, genuaer in
while CheckForWeapObj and (counter<10) do ...
Da ich die Exception an der Stelle abfange, gibt es zwar eine Fehlermeldung, aber das Skript wird erstmal nicht beendet. Bisher hat das bei mir keine Probleme gemacht, die eigentliche Ursache ist aber immernoch unbekannt. |
|
|
|
(0003879)
|
|
Natter
|
|
02.06.09 05:07
|
|
So, das Problem liegt irgendwo hier:
try // wegen Bug 2149
if not Pause then
begin
{ Objekte verarbeiten }
for Dummy:=0 to fObjectList.Count-1 do
begin
if (TISOObject(fObjectList[Dummy]) is TWaffenObject) then
for FrameDummy:=1 to Frames do
begin
if (not TISOObject(fObjectList[Dummy]).Deleted) and TISOObject(fObjectList[Dummy]).PerformFrame then
NeedRedraw:=true;
end;
end;
end;
except
on E: Exception do
begin
game_api_MessageBox('Eine Exception ist in TDXIsoEngine.PerformWeapObjFrame aufgetreten. '
+ 'Genauer in "if not Pause then ..."'+ sLineBreak + 'dummy: ' + IntToStr(dummy) + sLineBreak + 'fObjectList.Count ' + IntToStr(fObjectList.Count) + sLineBreak
+ 'Die Meldung lautet:' + sLineBreak + E.message,'behandelte Exception aufgetreten');
raise;
end;
end;
Dem angehängten Screen ist zu entnehmen, dass dummy=fObjectList.Count=7 ist ^^ |
|
|
|
(0003880)
|
|
DirkF
|
|
02.06.09 06:59
|
|
Ich würde einfach mal die Variable umbenennen.
alles immer "dummy" zu nennen was man nur vorübergehend braucht, ist ein gewisses Risiko - und ich gehe davon aus das die hier zugeschlagen hat.
Denn die For-Schleife sollte dummy nicht höher als 6 laufen lassen, und da es soweit ich sehen kann innerhalb der Schleife nicht verändert wird, könnte das eine Überlagerung gleichnamiger Variablen sein.
Die andere mögliche Ursache wäre das der fObjectList.Count durch Zerstörung von Objekten reduziert wird, während diese Schleife noch läuft.
Speichere das mal temporär und lasse die Schleife bis zum gespeicherten Wert statt dem direkten Wert laufen, gebe dann den aktuellen und den Originalwert in der Meldung aus. |
|
|
|
(0003881)
|
|
Natter
|
|
02.06.09 14:38
|
|
Ich nenne den Counter eigentlich immer i ;) Ist von anderer Stelle kopiert (also hat das vermutlich Christian geschrieben). Da AitForWeapObj ziemlich übersichtlich ist, glaube ich nicht, dass der Name der Variablen das Problem ist.
Wenn der Fehler reproduzierbar wäre, wäre das Problem wesentlich besser einzugrenzen. So muss ich meinen Spielstand ca. 30 Minuten immer wierder neu Laden, bis das Problem mal auftaucht.
Eigentlich kann ich mir nur vorstellen, das eines der Listenelemente irgendwo gelöscht wird - aber ich habe kein Ahnung, wo das passiert. Normalerweise erfolgt das Löschen erst in einer nachfolgenden Schleife (hier wird höchstens deletetd auf true gesetzt).
Ich hatte schon überlegt, ob es mit dem Tode einer EInheit zu tun haben könnte. Aber ich bilde mir ein, einen Screenshot zu haben, wo der Fehler zwar auftritt, aberr alle 4 Soldaten noch leben (das könnte aber auch durch ein noch ausstehendes redraw bedingt sein). Außerdem werden getötete Einheiten ja erst am Einsatzende wirklich gelöscht.
Ich werde versuchen, das Ganze noch weiter einzugrenzen, aber da es nicht reproduzierbar ist, könnte es dauern. A ndererseits - die Funktion wi rd nur per Skript genutzt, und der Zugriffsfehler kommt beim lesen - man könnte durchaus überlegen, die Exception in der veröffentlichen Version zu ignorieren (mache ich ja eigentlich schon jetzt - da der Fehler behandelt wird, läuft das AI-Skript ungestört weiter). |
|
|
|
(0003882)
|
|
Natter
|
|
03.06.09 01:06
|
|
Wie der letzte Screen deutlich belegt, kann sich an den Objekten in der Schleife jede Menge ändern. Selbst meine Überlegung mit dem down to könnte daher nicht ausreichend sein. Eventuell baue ich vor jedem Einsatz der Zählervariable nochmal eine Prüfung ein, ob die>=count ist.
Mir ist trotzdem noch nicht klar, wie es dazu kommt. Dass ist insofern blöd, weil die Funktion für die Objekte von anderer Stelle kopiert wurde. Genau das Gleiche wird nämlich auch in TISOEngine.PerformeFrame gemacht. Und da diese Funktion nicht per Skript aufgerufen wird, würde der Fehler dort vermutlich zu einem Spielabsturz führen. |
|
|
|
(0003888)
|
|
Natter
|
|
04.06.09 14:46
|
|
if (not TISOObject(fObjectList[Dummy]).Deleted)... um (dummy<fObjectList.Count) erweitert. Das gleiche hab ich auch in PerformFrame gemacht, auch wenn es dort meines Wissens noch keine Probleme gab.
Ich hoffe, damit ist das Problem in der b02 beseitigt. Wenn nicht, bitte nochmal melden. |
|