Nexus und Animationen oder Nexus allgemein

Sehr geehrter Herr Lotter,

folgendes Problem:
1) Beim Testen diverser Levels meines Spieles ist mir aufgefallen, dass der Nexus in manchen Welten von im Schnitt 40MB auf 4000-7000MB oder gar bis auf 49GB ansteigt (im Task Manager ist acknex.exe maximal bei 730MB). Letzteres ist in einem Skateboard Level der Fall, wobei die Spielfigur aus etwas über 150 Vertex-Animations-Frames besteht (ich schickte dem Support das Modell bereits vor einem Jahr wegen eines Normalenproblems). Lösche ich alle bis auf einen Frame, so sinkt der Nexus auf etwa 7000MB. [Gerade getestet: Lade ich nur die WMB in einem Testprojekt, also weiterhin per SED, so ist der Nexus bei 22MB.]

In einem anderen Level, einer Cutscene, befindet sich ein Modell mit ca. 970 Bone-Animationen/ Frames und der Nexus steigt auf über 3000MB. Speichere ich die Datei neu ab, bewirkt es nichts (sie scheint also nicht beschädigt), lösche ich aber bspw. 300 Frames, so ist der Nexus nur bei 79MB. Alle Dateien in diesem Level wurden mindestens einmal neu abgespeichert, erstelle ich darin aber einen Skycube mit nicht allzu großer Auflösung, so steigt der Nexus wieder auf über 3000MB an.

In anderen Levels, welche weder spürbar große oder viele Texturen noch viele Entities oder Animationen haben, habe ich teilweise ähnlich große Nexus Werte.

Da ich mir das nicht erklären kann (und es auch mit alten Versionen, sowohl meines Spieles und Gamestudios, passiert), frage ich Sie, ob Sie das irgendwie erklären/ aus der Ferne raten oder mir Tipps geben können, wo und wonach ich suchen muss.


2) Wo ich gerade dabei bin, vielleicht können Sie sich auch noch einmal folgenden Code/ Post angucken und die potentielle Ursache dafür angeben: http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=439410#Post439410

Vielen Dank!


EDIT: Im zuvor verlinkten Thread schrieb alibaba folgendes:


Könnte es vielleicht sogar sein, dass der/ ein Compiler Bug aus dem (View) Entity Crash Thread für 2) verantwortlich ist?

Also ich weiß ja dass ich hier eignetlich nicht posten sollte, aber mit dem nexus hatte ich auch schon zu kämpfen...
Ich habe relativ viele mdl Dateien (40) mit 3 bones animationen und insgesamt um die 250 frames. Die Dateien haben um die 5 skins (dds komprimiert mit stärskter packrate, dx1) aber mein Nexus ist trotzdem immer sehr hoch :S
Ich hätte hier gerne eine gute Antwort
Danke

Was den Nexus betrifft, müsste ich mir ein Testprojekt ansehen - Bones Animation kann eigentlich keine 49GB Speicher benötigen.

Was das Skript betrifft, so sind Object-Definitionen in Funktionen stets statisch.

Statt

STRING* str_tmp = str_create("");

also

STRING* str_tmp;
str_tmp = str_create("");

dann wird str_create() bei jedem Aufruf ausgeführt. Testen Sie auch, ob das File-Handle tatsächlich nonzero ist, bevor Sie auf das File zugreifen. Denn es kann immer mal vorkommen, dass auf einem PC eine Datei gesperrt ist, insbesondere nach einem vorhergehenden Absturz mit offenem File.

Unter aktuellen systemen(prinzipiel XP, spätestens Vista), sollte bei einem prozessabsturz das FileHandle wieder freigegeben werden, da windows die resourcen, die ein prozess beansprucht speichert und übrig gebliebene beim beenden des Prozesses frei gibt.

Finde ich auch. Wir sollten eine Petition aufsetzen.

[...]Das Problem hatte anscheinend eine sehr einfache Ursache, und zwar war der Nexus für manche Levels um ein paar MB zu klein, nun scheint also alles in Ordnung zu sein. Jedoch finde ich es etwas merkwürdig, dass die Variable dann teils nahezu exponentiell anwächst (oder macht das technisch sogar Sinn?).


Das habe ich nicht gewusst, danke für die Aufklärung. Jedoch verstehe ich nicht so ganz, was dann das ptr_remove() am Ende der Funktion für Auswirkungen auf den anscheinend statisch generierten String hat? Wird der String dann einfach ignoriert oder beim nächsten Aufruf doch neu erstellt?

Dennoch erklärt das noch nicht den Absturz der level_protcol Funktion in "L2C", welcher weiterhin auftritt (filehandle natürlich geprüft). Es wird stets eine Funktion zweifach aufgeführt, welche entweder einen "defekten" Namen trägt (wobei die file_str_write Operation dann gelegentlich abstürzt), oder aber gar keinen und/ oder mit (ent != NULL) und ent->link.index auf 0, -1, -1310736 oder sonstigen Werten.

Naja... wenn du Entities löschst dann ist deren Pointer nicht NULL
Das ist mir schon sehr oft passiert und das nervt mich doch am meisten an 3DGS :S

Das ist zwar korrekt, hat mit meinem Problem aber (höchstwahrscheinlich) nichts zu tun?!

Ich möchte nur noch einmal auf folgende Fragen aufmerksam machen:


Das Problem tritt nicht nur bei mir allein auf, aber auch nicht bei jedem. Ich wüsste aktuell nicht, in welche Richtung ich das debuggen sollte, insbesondere im Hinblick auf die beiden/ die doppelt aufgeführte Funktion mit defektem Namen/ ohne Namen (welche auch zum Absturz führt, gelegentlich). Haben Sie eine Idee?

EDIT: Was ich zuletzt versuchte, war, Funktionen, welche "lokal" (also per Entity) gestartet werden, dann aber global laufen, zu analysieren. Diese scheinen aber auch unproblematisch bezüglich des Problems zu sein. freeze_mode und NOFREEZE benutze ich auch, falls das irgendeine Rolle spielt.

Can anyone post here with english language

The thread is/ was about two separate problems:

1) The Nexus variable in the debug panel "exploded" in some levels of my game, from an average value of about 40MB up to 7-49GB. The reason for this was simple though, the max_nexus set before you start the game simply was too low in some cases (in prior versions/ years ago there used to be an error message then).

2) For debugging purposes I've written a level protocol function which among others lists the functions currently running in the level. However, in my project (and at least one other project) there is one/ two functions which yield broken names and lead to crashes.

1) is clear - the displayed number was wrong in some cases - but can you upload an example for 2)?

A test project which has been reduced to a reasonable size in a reasonable amount of time has been sent to the support. Thank you in advance.

Have you already had the time to take a look at the sample project/ issue 2)?

At least partially. The developer had followed your installation instructions with the data.skd file, but still got error messages at start, and could not reproduce the problem with your game - there was also no "Continue", but just a black screen after the menu. But he found something suspicious in the engine_gettaskinfo function, apparently no function and entity names were returned under some circumstances. This will be corrected in the next update.

Thank you for the response. The error messages or warnings appear when no data.skd file was found on game start. I've just tried it again, unpacked the zip file, created a Superku folder (in "Eigene Dokumente"), copied the data.skd file there, and started superku_crashes.c with a Test Run. On the 4th try the L2C error appeared.

However, I hope the developer has found the issue even so.

This function still crashes for me.
Was the fix included in the most recent update?

Yes, engine_gettaskinfo was modified in that version. But it was maybe not responsible for the crash, as it could not be reproduced here anyway. Do you have a simple, stripped down example for reproducing the crash?

The problem with crashes in huge games is that it can take a long time of testing and playing around until we can see the problem, if at all. We've meanwhile collected a bunch of large games over time, all with described problems or crashes that we could not reproduce in a reasonable amount of time. The more hidden the problem is in such a project, the higher the chance that it stays unfixed.

Thanks for the response, I forgot about it.

Yes, I understand. The problem for me with trying to make a small self contained example in that regard is that I don't think I can make it crash each time even in my full game.
Maybe I should invest a week or two, playtest and log/ diag extensively and proofread the whole game code (for invalid array/ memory stuff, ...).

Either way I'm going to monitor this and try if I can isolate the issue.