Jagged Alliance Forum

hi,


mir geht 1.13 schon langsam echt aufn sack, was die stabilität angeht.
weil das ist schon mein 3. savegame, das ich schon abbrechen möchte, nur weil mir ja2 dauernd abkackt.

ich weiß nicht warum, aber in den letzten tagen (der spielzeit, also da ist jetzt zB tag 22) kackt ja2 besonders oft ab, wenn ich den zeitraffer aktiviere.
irgendwie hab ich es bisher immer geschafft, das ganze zu umgehen....indem ich zB den sektor lade, bei bobby rays mal was einkaufe oder sonst was.

aber das hat den absturz dann immer nur hinausgezögert. so wie jetzt.
weiß jemand, woran das liegen könnte?

einfach mal ausprobieren: da

ist us-version 1.13



ciao

mmm...

Ich sehe, dass du Trefferquote auf 100 hast. Ich weiß nicht, ob das eine gute Idee ist. Ansonsten kämpfst du auch nur ganz alleine durch die Gegend und hast trotzdem kein Geld. Wie schaffst du das ...

Aus dem Logfile für den Crash kann ich folgende Zeile entnehmen:
Exact Error Message
"The thread tried to divide an integer value by an integer divisor of zero."

Lokadamus hat geschrieben:mmm...

Ich sehe, dass du Trefferquote auf 100 hast. Ich weiß nicht, ob das eine gute Idee ist. Ansonsten kämpfst du auch nur ganz alleine durch die Gegend und hast trotzdem kein Geld. Wie schaffst du das ...

Aus dem Logfile für den Crash kann ich folgende Zeile entnehmen:
Exact Error Message
"The thread tried to divide an integer value by an integer divisor of zero."

hi,


ah, danke. ich bin garnicht auf die idee gekommen, mir die error_log anzuschauen

aber trotzdem weiß ich nicht weiter...hm.

ja, ich kämpfe mich alleine durch, die 2 savegames davor wo ich 6 leute im trupp hatte, waren mir zu einfach

wie ich das schaffe? ich bin einfach gut

..und kohle hab ich deshalb kaum, weil ich recht oft mit skyride irgendwo rumfliege...deidrannas affen greifen ja alle paar stunden irgendwo an, wo ich kaum mit dem milizentraining vorrankomme...


gut, da wird was durch 0 dividiert. soll ich meine mathelehrerin fragen, wie das geht? lol....... hat jemand eine idee, wie das zu umgehen ist..?



ciao

mmm...

Mir fallen dazu nur 2 Sachen ein:
1.) Die Trefferquote mal zurück auf 95 setzen, so triffst du immernoch sehr gut, aber wir können das als Ursache danach ausschliessen, falls die Spielstände weiterhin dauernt abschmieren.
2.) Die ganzen Gegenstände mal verscherbeln. Das geht mit gedrückter Alt- Taste und einem Linksklick auf einen Gegenstand in der Map- Übersicht sehr einfach. Allerdings bekommst du dann auch nur 25% des Wertes des Gegenstandes, wobei Munition in Waffen nicht mitgezählt wird. Diese also rausnehmen und dann verkaufen ...

"Einfach" ist es, weil du zu gute Waffen zur Verfügung hast . Ich hab deshalb ein neues Spiel ala JA2 Original angefangen, ausser, dass ich mir 4 AEs gemacht habe. Der Versuch, Maddog gleich nach der Eroberung von Drassen zu holen, war doch schwieriger als erwartet. Ebenso wurde ich am Tag 6 und 10 in Drassen angegriffen ...

Bei mir kommt als crashlog immer der Text:
"The thread tried to read from or write to a virtual address for which it does not have the appropriate access."
Für was hat der Thread keine Erlaubnis, oder wer kann mir Laien mal helfen.

hi,


nun, diese verkaufen-option mit der alt-taste hab ich abgestellt. ich finds doof und unrealistisch, d.h. schadets nur dem spielspaß.
aber das mit der treffsicherheit schau ich mir mal an, wenn jape auch unter wine läuft


ciao

miro hat geschrieben:wenn jape auch unter wine läuft

mögliche ursache

MFG.....

nö.







war auch unter windoze früher so als ich da mal 1.13 gezockt hab - ist oft abgekackt

Hmm, ich muss sagen, dass ich mit 1.13 nie Abstürze hatte. Erst mit der normal aufgelösten nicht und dann mit (einer der späteren Versionen) mit 800x600/1024x768 auch nicht. Nur ein einziger Deadlock: als ich vom Inneren eines Hauses eine Granate durch ein Fenster nach außen werfen wollte. Aber der ist ja schon berüchtigt.


Welche Version von Wine benutzt du? Hast du selber noch etwas nachkonfiguriert oder aus so einer Wine-Datenbank die benötigten Einstellungen oder ging es gleich so?

miro hat geschrieben:hi,


mir geht 1.13 schon langsam echt aufn sack, was die stabilität angeht.
weil das ist schon mein 3. savegame, das ich schon abbrechen möchte, nur weil mir ja2 dauernd abkackt.

ich weiß nicht warum, aber in den letzten tagen (der spielzeit, also da ist jetzt zB tag 22) kackt ja2 besonders oft ab, wenn ich den zeitraffer aktiviere.
irgendwie hab ich es bisher immer geschafft, das ganze zu umgehen....indem ich zB den sektor lade, bei bobby rays mal was einkaufe oder sonst was.

aber das hat den absturz dann immer nur hinausgezögert. so wie jetzt.
weiß jemand, woran das liegen könnte?

einfach mal ausprobieren: da

ist us-version 1.13



ciao

Ich werd mir heut dein savegame anschauen, und den source-code ein bissl debuggen und schauen, ob ich den bug beheben kann.

morki hat geschrieben:Hmm, ich muss sagen, dass ich mit 1.13 nie Abstürze hatte. Erst mit der normal aufgelösten nicht und dann mit (einer der späteren Versionen) mit 800x600/1024x768 auch nicht. Nur ein einziger Deadlock: als ich vom Inneren eines Hauses eine Granate durch ein Fenster nach außen werfen wollte. Aber der ist ja schon berüchtigt.


Welche Version von Wine benutzt du? Hast du selber noch etwas nachkonfiguriert oder aus so einer Wine-Datenbank die benötigten Einstellungen oder ging es gleich so?

Ja dieser Bug ist alt bekannt und wird für die nächste Version gefixt werden. Steht schon in der Bug-Liste!
Wenn du zwischen dem Fenster und dem Söldner 1 Feld Abstand lässt und dann eine Granate durchs Fenster wirfst, sollte es eigentlich funktionieren. Ist aber mal nur eine Notlösung.

@RoWa21

ja, das wär echt nett


@morki

ver. 0.9.8 beim start, seit release aber .9.9 - der fehler trat aber auch schon früher auf.

es ist nur so, dass es manchmal lange zeit nicht abkackt, dann aber (wie jetzt zB) sehr oft in kurzer zeit. und immer konnte ich es umgehen, nur jetzt gings halt nicht...



ciao

Ajax hat geschrieben:Bei mir kommt als crashlog immer der Text:
"The thread tried to read from or write to a virtual address for which it does not have the appropriate access."
Für was hat der Thread keine Erlaubnis, oder wer kann mir Laien mal helfen.

Nur mal so aus langeweile

Der Faden hat keine Erlaubnis auf eine bestimmte Speicheradresse zuzugreifen. Falsche Zugriffsrechte oder der Bereich gehört ihm gar nicht

Hilft aber trotzdem nichts.

Diesen Fehler gibt es auch bei WF6. Dort lässt er sich umgehen, indem man in der taktischen Ansicht den Zeitpunkt verstreichen läßt, zu dem der CTD stattfindet.

Also in der strategischen Ansicht den Zeitpunkt des CTD merken, und beim nächsten Mal eine Minute vorher in die taktische Ansicht wechseln und 2 Minuten verstreichen lassen. Meistens half mir das auch bei 1.13 (wo mir dieser Bug aber wirklich selten begegnet ist).

Blöd ist nur, wenn gerade alle Trupps unterwegs sind, und man daher keine taktische Ansicht bekommen kann...

Starwalker

morki hat geschrieben:Der Faden hat keine Erlaubnis auf eine bestimmte Speicheradresse zuzugreifen. Falsche Zugriffsrechte oder der Bereich gehört ihm gar nicht.

Ein Thread ist in diesem Zusammenhang kein "Faden" im sprichwörtlichen Sinn, sondern ein Ausführungsstrang bzw. eine Ausführungsreihenfolge der Abarbeitung der Software auf einem Prozessor.
Das kann beispielsweise durch einen (hier: fehlerhaften) "Unterprozeduraufruf" im Spiel erfolgen.

de.wikipedia.org (Auszug) hat geschrieben: Ein Prozess bezeichnet den Ablauf eines Computerprogrammes auf einem Prozessor. Ein Prozess kann genau einen Thread des Betriebssystems belegen, wenn bei dem Programmablauf keine Parallelverarbeitung vorgesehen ist. [...]
Gegenüber einem Prozess wird ein Thread auch als Leichtgewichtprozess bezeichnet, da die Umschaltung zwischen Prozessen mehr Aufwand (Rechenzeit) im Betriebssystem erfordert als die Umschaltung zwischen Threads eines Prozesses. Einem Prozess ist ein Speicherraum und weitere Betriebssystemmittel zugeordnet, mehrere Threads eines Prozesses teilen sich hingegen die Betriebsmittel des Prozesses und greifen auf den selben Speicherraum zu.

http://de.wikipedia.org/wiki/Thread_%28Informatik%29

Sehr schön gesagt. Wenn du mir jetzt noch erklärst, warum man bei unserer Speicherverwaltung für CoStubs mithilfe switchContext keinen Prozesswechsel mit gleichzeitigem Umladen des CR3-Registers hinbekommt, gebe ich dir einen Keks.

morki hat geschrieben:Wenn du mir jetzt noch erklärst, warum man bei unserer Speicherverwaltung für CoStubs mithilfe switchContext keinen Prozesswechsel mit gleichzeitigem Umladen des CR3-Registers hinbekommt, gebe ich dir einen Keks.

Keine Ahnung, was ihr da bei eurem Ossi-OS implementiert habt.

--> RTFM


Aber schau mal hier:

The paging at i386 architecture must use CR3 register, as we known, at least. In paging process, CR3 register take one important role, it include page table directory base address.
So in linux kernel, if it is going to map its "linear address" to low end physical address, it also need use CR3 register. but it can not use CR3 directly, in switch_mm() function at least, this function will change CR3 register value to switch user task memory address space.

[...] so I'm assuming that the CR3 register is the pointer to the Global Page Table (GPT).

I known kernel often do not setup page table for itself, except some special cases, for example, vmalloc. This feature say kernel use page table (and CR3) in reverse.

Lets for sake of simplicity, forget about how the kernel fills up the
entries in the GPT (can be done from page faults).

[...]
OK, the CR3 (If I was right in my above statement) points to the page
tables. So we have

.......GPT
CR3 -> +--------+
......| | -> user page tables.
......| |
......| |
......| |
......|0xc0000 | -> Page table of kernel
......+--------+

If all the user's Global page tables (GPT) has a pointer to the kernel
page table for the address of 0xc0000000 and above, then there's no
problem in switching the CR3 register. What happens is that the user's
page tables will change. But all the user tasks have the upper address
pointing to the same address (thus the kernel), with the proper
protection bits as described earlier that say that only when the CPU is
in kernel mode does it have access to this.

Quelle: http://linux.derkeiler.com/Mailing-List ... /4679.html

http://www.fh-zwickau.de/doc/prmo/pmtut ... _spez1.htm
http://de.wikipedia.org/wiki/Protected_Mode