JA2 Source: Bugfixing-Projekt

[Realist]

Moin,


da sich vor allem auch nach Wildfire wieder viele Leute über die Bugs in JA2
aufregen, möchte ich ein passendes Projekt beginnen.

Und zwar möchte ich versuchen, die Bugs mittels Sourcecode auszuräumen und eine
möglichst unverbugte ja2.exe zu erzeugen. Dazu würde ich das Programm WEdit an
diese ja2.exe anpassen und beides öffentlich zur Verfügung stellen, sodass
Spieler und Modder bei Interesse darauf zurückgreifen könnten.

Da keine (vollständige) Bug-Liste zu JA2 existiert oder mir zumindest nicht
bekannt ist, soll dieser Thread dazu dienen, dass jeder die ihm bekannten Bugs
postet, damit diese erst einmal erfasst und gesammelt werden.

Als Bug gilt alles, was in der ja2.exe falsch/fehlerhaft ist und das Spiel im Spielen
beeinträchtigt.
Soll heißen, wenn z.B. in einer Beschreibung zu einer Waffe ein inhaltlicher
Fehler auftaucht, dann ist dies kein Bug. Aber das sollte ja wohl klar sein.

Weiterhin ist der Sourcecode Grundlage für die Goldversion 1.12 (dt), das heißt
Bugs die in der Goldversion gegenüber den vorhergehenden Versionen bereits
behoben sind, bedürfen keiner Korrektur. Trotzdem wünsche ich mir, dass auch
solche Bugs, die nur aus den Classic-Versionen bekannt sind, gepostet werden.
Die, die im Besitz einer Goldversion sind, mögen daher bitte ihre Aufmerksamkeit
vermehrt den Bugs in Gold zuwenden.

Nochmal zum Verständnis:
Bitte keine Bugs aus Wildfire posten, sondern nur aus dem originalen JA2 in den
Versionen 1.00, 1.01, 1.02, 1.05, 1.07 und vor allem 1.12.
Dabei bitte nach Kenntnisstand dabei schreiben, ob ein Bug in einer höheren
Version bereits behoben wurde.

Ein solcher Bugreport sollte also nach Möglichkeit enthalten:
- Version(en) in der/denen der Bug auftritt,
- Beschreibung des Bugs,
- wenn möglich, ob eine höhere Version den Bug fixt.


Ich würde mich freuen, wenn diese Idee hier Anklang und Unterstützung findet.

Realist

[Nitrat]

dufte !
1 = Version(en) in der/denen der Bug auftritt,
2 = Beschreibung des Bugs,
3 = wenn möglich, ob eine höhere Version den Bug fixt.

1. dt v1.00
2. Geldabhebebug
3. gefixt in dt v1.05

1. dt v1.00 +dt v1.02
2. Milizen überschuss im Sektor
3. dt v1.05

PS: hab ich das so richtig verstanden ?
MFG......

[miro]

..ne, ich glaub nicht.


>> sag mal, ich dachte, der quelltext wäre nur von ver. 1.00 verfügbar..?

[Realist]

@miro
source ist von gold 1.12, wär ja unfug den von einer uralt version zu veröffentlichen, wenns eine aktuellere gibt. denn wenn schon, denn schon.

darum @Nitrat
jepp genau so - nur halt auch bugs aus gold, weil solche von früher bereits gefixt sind.
trotzdem will ich auch gerne ältere sammeln um zu gucken ob durch deren bugfixes nicht
noch mehr unfug entstanden ist.

[Wulfy301]

v1.12
Grafikfehler mit original Map Estoni (Helikopter ist nur teilweise zu sehen)
Lösung:
"C:\ja2\Build\Strategic\Map Screen Helicopter.c(110)"

INT16 sRefuelStartGridNo[ NUMBER_OF_REFUEL_SITES ] ={
9001, // drassen
13544 , // estoni

Mfg...

[Wulfy301]

V1.12
Nachdem man Shank aus Tixa befreit und angeheuert hat, geht’s ab nach Estoni, dort spricht man mit Jake, anschließend darf man hier mit dem Heli landen und auftanken.
Das funktioniert aber nur, wenn man sofort nach der Befreiung von Shank zu Fuß nach Estoni läuft!!
Wenn man den Helikopter benutzt um von Tixa nach Estoni zu kommen und anschließend mit Jake spricht, bekommt man keine Belohnung und die Aufgabe ist somit eigentlich nicht beendet!

Mfg...

[miro]

was mich ja absolut stört und am installieren von 1.12 hindert, ist der energiebug. also dass man 10x auf soldaten einlschagen kann und die immerwieder aufstehen können.


>> hm, aber angeblich wird gerade offiziell ein neuer patch für ja2gold entwickelt....uhm

[Realist]

Moin,

ihr könnt/sollt auch Bugs posten, die beim Modden auftreten.

Als da wären bis 1.12 einschließlich:


- Entladebug: bei mehr als 2 verschiedenen Magazingrößen des gleichen Kalibers
kann es beim Entladen zu einem anderen Magazin führen.

- Ammo-Statusbar-Bug: bei zu großen Magazinen ist die Füllstandanzeige in Form
des Balkens links vom Item fehlerhaft.


-> die beiden konnte ich übrigens bereits beheben.

@Dr.X,
falls du das lesen solltest, ich habe meinen Entlade-Bugfix von früher ausgiebig
getestet und er funktioniert wohl! Wenn man nicht alles selbst macht...


- Phänomen, dass Attachments selber keine Attachments haben können. Siehe u.a. TBoA
wo die Pistole die Attachments verliert, wenn man sie an die Weste dran macht.


und noch ein Bug, der nicht das Modden betrifft:

es gibt in Ja2 das koriosum, dass manchmal der schuss einfach zu gut ist. versuch mal weniger stark mehr zu ziehlen (weniger rechtsklicks meine ich) oder auf den kopf zielen oder was abbauen vom gewehr
zur erklärung des problems: die trefferwahrscheinlichkeit rutscht einfach über 128 und wird damit negativ

=> das ist imho der katastrophalste bug überhaupt.



wie siehts aus mit weiteren bugs, die z.b. das Klauen von Gegnern betreffen (endlos eieruhr)
oder gewichtsbugs etc.?

[-=[MAD]=-]

Gewichtsbugs sind eigentlich doch falsche Werte in der MyWeapons (wenn man damit arbeitet). Oder meinst du die granatenweitwerf-gewichtbugs?

Klauen von Gegnern: meistens geht die Eieruhr mit STRG+ALT+ENTER weg, manchmal nicht und manchmal kommt erst gar keine.
Bei WF hab ich jetzt zB die erfahrung gemacht, dass die Eieruhr (ging nicht weg) kam, als ich den gegner beklauen wollte. Dann hab ich dieselbe aktion mit dem EH-Kasten wiederholt, und es kam keine Eieruhr im ersten fall lag die geklaute waffe nur aufm boden, im zweiten war sie im inventar meines söldners

gruss, -=[MAD]=-

[miro]

stimmt, klauen ist total verbuggt überhaupt.

was auftreten kann ist, dass einmal die waffe des soldaten am boden liegt UND im inventar des söldners.


>> hält der söldner eine waffe in der 2. hand, so verschwindet diese auch, wenn man dann eine waffe klaut, die ins inventar reinkommt, sie wird einfach ersetzt.


ich seh eigentlich nicht wirklich ein, wo da so großartig bugs entstehen können.

im prinzip wird ja nur beachtet, wie stark beide sind, wer wieviel energie hat und ob der soldate bewusstlos ist - was manchmal dazu führt, dass man die waffe nicht klauen konnte, weils an kraft mangelt....ist ja auch so schwer, wenn der soldat bewusstlos vor einem liegt..


hach, wär ja2 doch nur in php geschrieben ...bzw. perl.



ciao

[Mysterious Dr.X]

Howdy Rowdies!

@Dr.X,
falls du das lesen solltest, ich habe meinen Entlade-Bugfix von früher ausgiebig
getestet und er funktioniert wohl! Wenn man nicht alles selbst macht...

Genau das gleiche wollte ich gestern nochmal testen, hatte aber Gold nicht mehr installiert. Aber gut zu wissen, dass es doch klappt, nun kann ich meine Jungs vom Metavira-Mod beruhigen .

1. v1.07 Gold
2. ein Grafikfehler(?) beim Geldabheben
3. v1.12 Gold aka "the holy version"


Dr.X

[-=[MAD]=-]

@Dr.X
wer beruhigt hier wen?

@miro
hmm, dein phänomen hatte ich noch nie, und ich lasse immer meine hauptwaffe in der zweiten hand, in die erste kommt ja der EH-Kasten

gruss, -=[MAD]=-

[B0NECHUCKER]

hiho
A
1. versionen : alle
2. drawcost/turn waffendrawcost wird mit ap kosten fürs umdrehen quasi verrechnet
3. offiziell unfixxed
B
1.versionen :alle
2.burstbug
3.fix offiziell angeblich ab gold ?...aber dvornik schreibt dazu anderes

wenn A gefixxt werden sollte könnte man das draw-capping auf 3 ap gleich mit entfernen und an UB angleichen.
also höher draw-costs ermöglichen

line of sight/physics kommen mir auch bissel seltsam vor - beispiel feurgefecht, gebäudedach/boden

bug oder feature,das man gebäudedächer nicht zerstören kann ? ;-) naja vielleicht auch einfach faulheit oder zeitknappheit der original progger ;-)

gruss bone

[-=[MAD]=-]

zu B

kam da nicht mit WEdit nen patch raus? war gleich mitgeliefert, afaik bei allen versionen

gruss, -=[MAD]=-

[shadow the deat]

Klaun war doch soweit ich weiß schon gelöst wurden ist


da hatte man dann auch nen Menü wo man sehn konnte was man klaut

war glaub ich beim Whitehat Project bei

und war an sich Bug frei glaub ich

[Tingeroo]

Es werden dringend zusätzliche Muniartenplätze in der Exe benötigt! Ebenso müssen die Magazine mit hoher und niedriger Menge an Muni untereinander verknüpfbar sein, da sonst ja diese entladungsprobleme auftreten.

Scifiwaffen raus, dafür Granatwerfer/Mörserplätze schaffen (Animation), Raketengewehranimation auf ein anders Item packen! [gut, die Scifiwaffen lassen sich eh umändern, aber eine zusätzliche Waffe mit Mörserani fände ich ganz gut..]

allgemein finde ich, dass die Bloodcats nerven ... Hinterhalt weg, dafür dies als "normalen" Angriff mit Taktikübersichtsmap vorab usw., damit auch mal ein einzelner Merc einen solchen Angriff schaffen kann (oder ich kann sowat halt nicht )
dabei gibts den bug, dass alle positionen ja versetzt werden, dass Söldner aufm Dach vom Hummer stehen (wenn Sie vorher in der Map aufm Dach waren) und dort aber nicht runter können...

Die Panzermilizmedunasachen, sprich, es gibt 2 tanks und danach stehen alle faces "Kopf", die tanks vielleicht als questeinbau ermöglichen...

alle kellermaps sollten Gegner haben, eventuell direkt in die Exe einbauen, auch die Scifimaps, dafür die Viecher raus...

loyalitätsverlust wenn in den Städten über den Kartenrand zwischen sektoren wechselt, hat für mich keinen Sinn und nervt

...stimmt, im moment habe ich in estoni zwar benzin, aber scirider fliegt dort nicht an (als landeplatz)

carmen gibt immer kohle, deshalb überlebt bei mir immer ein terrorist

........mir fällt gerade nicht mehr ain, aber kommt sicher noch......

[Gunny]

@Tingeroo
es ging hier eher um Bugs, nicht um Modding der Source,
die meisten deiner Wünsche kann man relativ easy verwirklichen

@Topic
es gibt folgende mir bekannten Bugs in der Source

1. Gewichtsbug
--> Granaten werden immer gleich weit geworfen, egal welches Gewicht sie haben
--> Fix dafür kann ich nachreichen
2. Drawcost/Turncost
--> habe die entsprechende Stelle in der Source wahrscheinlich gefunden, Fix wird nachgereicht
3. Bugs betreffs schlafender Mercs, die trotzdem Items reparieren,
--> Fix kam von Chris Camfield persönlich, kann ich nachreichen

und natürlich die bereits hier besprochenen

[Tingeroo]

die meisten deiner Wünsche kann man relativ easy verwirklichen

meine indirekte Frage war ja auch nach einer fertigen Exe, da mich das VisualC++ nicht mag

Versionen 1.00, 1.01, 1.02, 1.05, 1.07 und vor allem 1.12.

@ realist
also was genau hast Du vor ?

[B0NECHUCKER]

hiho

@thema bugs beim modden ......war da nicht noch was bei den offsets der beiden t-shirts und bei der schrot oder caws-mun? bin mir nicht sicher aber w4st schreibt im wedit-doc doch was zu dem thema.

@ modding der exe/source mach ich mal nen neuen thread auf

[Gunny]

ja Bone, da war was,
hängt im Wesentlichen nur mit einem Zahlendreher in der Source zusammen wenn ich das richtig interpretiert habe

[Gunny]

Hier einer der versprochenen Source Fixes:

Fix for standing mercs after climbing

file: Soldier Ani.c
lines: 254-258
Old:
// Set desired anim height!
pSoldier->ubDesiredHeight = ANIM_CROUCH;

// Move merc up specific height

New:
// Set desired anim height!
pSoldier->ubDesiredHeight = ANIM_CROUCH;
usUIMovementMode = GetMoveStateBasedOnStance( pSoldier, gAnimControl[ pSoldier->usAnimState ].ubEndHeight );
pSoldier->usUIMovementMode = usUIMovementMode;

// Move merc up specific height

der Rest folgt noch

[riodoro]

Hallo,
ein weiterer Bug bzw. eine Kuriosität ist es, dass ein Söldner wenn er einen gewissen Beweglichkeitswert überschreitet, er plötzlich mehr AP für seine Aktionen aufwenden muss. (z.B. Wurfmesser werfen kostet Blood 8 AP (bereinigt) statt der üblichen 7)

MfG
riodoro

P.S. Dieses Problem hängt aber nicht nur mit der Bew. zusammen. AUch die anderen die Aktion betreffenden Werte haben Einfluss. Handelt es sich dabei möglicherweise auch um einen Prüfsummenfehler?

[riodoro]

Hallo,
Gegner verändern häufig die Position (kriechen-liegen) und schiessen dann, obwohl sie aus dieser neuen Position die Söldner nicht sehen können. Gut man kann argumentieren, dass die Söldner dies auch können, aber ich würde wetten, dass die Modifikatoren für blindes schiessen dabei keine Anwendung finden.
Dieses "feature" tritt nur in Gold auf.

MfG
riodoro

[Mysterious Dr.X]

Howdy Rowdies!

Weiß jetzt nicht mehr genau ob's schon erwähnt wurde und bin einfach zu faul nochmal nachzuschauen:

1. 1.07 & 1.12 Gold-Version
2. Gegner treffen den Söldner mit Granaten/Leuchtstäben, sodass immer 1 LP abgezogen wird.

Ob's in der 1.07 Version auch auftritt weiß ich nicht, ist ja eigentlich auch shice-egal .


Dr.X

[Gunny]

Howdy Rowdies!

Weiß jetzt nicht mehr genau ob's schon erwähnt wurde und bin einfach zu faul nochmal nachzuschauen:

1. 1.07 & 1.12 Gold-Version
2. Gegner treffen den Söldner mit Granaten/Leuchtstäben, sodass immer 1 LP abgezogen wird.

Ob's in der 1.07 Version auch auftritt weiß ich nicht, ist ja eigentlich auch shice-egal .


Dr.X

das ist kein Bug,
die KI behandelt auch Leuchtstäbe wie Granaten, nur das die "Explosion" halt Licht ist

[Snej]

Wie im Thread "JA2 V1.02 BSE Test" unter
http://jagged.gamigo.de/ja_forum/showthread.php?t=15681
zu lesen ist, habe ich mich ein wenig mit dem BSE Test beschäftigt.

Hier nun eine Liste der mir aufgefallenen Fehler mit Behebungsmöglichkeiten:

1. Die SkillListe wird nicht initialisiert. Das führt dazu, das, wenn man den BSE Test
abbricht und beim erneuten Anlauf keinen! Skill angibt, der AE trotzdem einen Skill
bekommt.

Lösung:
in der Datei "IMP Compile Character.c"
Line 43 und
Line 606
fügt man zu
iLastElementInSkillsList = 0;
noch
SkillsList[0]=NO_SKILLTRAIT; // vgl. "soldier profile type.h"
hinzu


2. Wie in dem erwähnten Thread zu lesen ist, ist die Vergabe der Berufsauffassung
ziemlich kompliziert und eigentlich anders gemeint.

Lösung:
in "IMP Compile Character.c" Line 219 ff.
in der Funktion "CreatePlayerAttitude"
genauer Line 270
"iAttitude = iCounter2;" ist durch "iAttitude = iCounter;" zu ersetzen


3. Beim Test sollte die Antwort 9:2 nicht mehr pessimistisch sein

Lösung:
in "IMP PersonalityQuiz.c"
Line 1209
ein "break;" einfügen


4. Zu überlegen ist, ob mehr Persönlichkeiten zugelassen werden sollen
Siehe in "IMP Compile Character.c" Line 502 ff.

"void AddAPersonalityToPersonalityList( INT8 bPersonlity )
{
// CJC, Oct 26 98: prevent personality list from being generated
// because no dialogue was written to support PC personality quotes

// BUT we can manage this for PSYCHO okay

if ( bPersonlity != PSYCHO )
{
return;
}
"
Dann sollte man die if-Abfrage entfernen.


5. Die Erstellung der Bestätigungs E-Mail sollte mal überprüft werden
( ich bin zu müssig dazu)
z.B. erscheint bei 35 Beweglichkeit ein Kommentar zur Beweglichkeit unter
"Weniger gute Eigenschaften" sowie unter "Schlechte Eigenschaften".


So weit so gut
Viel Spaß noch

Snej

[Snej]

Zur Zeit beschäftige ich mich mit dem MERCPROFILESTRUCT in "soldier profile type.h"
Dazu erscheint in Kürze auch ein eigener Thread.

Neben dem Ziel die Fehler auszumerzen, sollte man meiner Meinung nach auch versuchen,
die Lesbarkeit des Codes zu verbessern um künftigen Fehlern vorzubeugen.

In diesem Sinne ist dieser Beitrag gedacht.

In der Datei personnel.c ist mir aufgefallen, das die Variable pTeamSoldier in
verschiedenen Bedeutungen daherkommt.

Einmal als SOLDIERTYPE struct welcher in "Soldier Control.h" definiert ist und
dann noch als MERCPROFILESTRUCT.

Das fatale dabei ist, das beide structs auch noch gleichnamige Elemente enthalten
wie z.B. bWisdom.

Mein Lösungsvorschlag armhaltet - quatsch - beinhaltet nun, die Variablen,
die in Bezug zu MERCPROFILESTRUCT stehen umzubenennen.

Damit das nun nicht in zuviel Arbeit (für euch) ausartet hab ich sie mir gemacht.
(Herausfinden wo welche Variablen geändert werden sollten)
Jetzt müssen sie nur noch geändert werden.

Einmal gibt es das globale Array gMercProfiles worin 170 Charaktere gespeichert sind.
In den anderen Dateien tauchen nur noch Pointer auf dieses Array auf, um die Daten zu
manipulieren.
Diese heißen meist pProfile oder pMerc oder pMercProfile.
pMercProfile finde ich am treffendsten, da sowohl der struct als auch das globale
Array so heißen.
Der Name pProfile wird in anderem Zusammenhang auch noch in "Animation Data.c"
und "Soldier Control.c" verwendet.
pMerc wird in etlichen Dateien auch als SOLDIERTYPE verwendet.
pMercProfile wird bisher nur als MERCPROFILESTRUCT verwendet was die Sache erleichtert.

Nun zu meinem Lösungsvorschlag:

SaveLoadGame.c: pProfile -> pMercProfile 14 Änderungen
IMP Compile Character.c: pProfile (nicht ImpProfile) -> pMercProfile 7 Änderungen
IMP Confirm.c: pProfile (nicht ImpProfile) -> pMercProfile 49 Änderungen
insurance Contract.c: pProfile -> pMercProfile 18 Änderungen
merc Files.c: pMerc -> pMercProfile 5 Änderungen
personnel.c: pTeamSoldier aus den Funktionen
GetIdOfDepartedMercWithHighestStat, GetIdOfDepartedMercWithLowestStat und
GetAvgStatOfPastTeamStat -> pMercProfile nur 24+24+13=61 Änderungen nicht 162!!!
Game Init.c: pProfile -> pMercProfile 55 Änderungen
mapscreen.c: pProfile -> pMercProfile 5 Änderungen
Strategic Merc Handler.c: pProfile -> pMercProfile 23+55=78 Änderungen
Strategic Movement.c: pProfile -> pMercProfile 9 Änderungen
Campaign.c: pProfile -> pMercProfile 6+46+2+49+27+9+8+11=158 Änderungen
Campaign.h: pProfile -> pMercProfile 5 Änderungen
Merc Hiring.c: pMerc -> pMercProfile 10 Änderungen
Morale.c: pProfile -> pMercProfile 17 Änderungen
Soldier Create.c: pProfile -> pMercProfile 25+23+26=74 Änderungen
Soldier Profile.c a) pProfile -> pMercProfile 53 Änderungen
b) pNewProfile -> pMercProfile 76 Änderungen
c) Line 1405 beide "bInvStatus" in "bInvNumber" ändern !!!
d) Warum wird Larry_Drunk bzw. Larry_Normal die Erfahrung nicht mitgegeben ?
Sie sollte natürlich im nicht mehr aktuellen Profil auf 0 gesetzt werden.
Ich seh nicht, was da "causing problems" machen sollte. Außer Life und LifeMax
- aber so wie es jetzt ist, auch schon.
Wie es jetzt ist, levelt Larry in beiden Zuständen parallel.
Könnte man also versuchen, Larry_Drunk besser zu machen als Larry_Normal .
Tactical Save.c: pProfile -> pMercProfile 26 Änderungen
Tactical Save.h: pProfile -> pMercProfile 1 Änderung
NPC.c: pMercProfile -> pMercProfileMerc 5 Änderungen
pNPCProfile -> pMercProfileNPC 32 Änderungen
pProfile -> pMercProfile 26 Änderungen (erst zum Schluß denn pMercProfile
sollte vorher geändert werden)


Ende des Lösungsvorschlags


Nachbemerkung: Mir ist klar das dies keine Bugs sind, die "beim Spielen" auftreten -
[mit Ausnahme den in der Datei "Soldier Profile.c" ]
aber ich denke das nicht alle Bugs auf einmal zu fixen sind.

Wenn z.B. durch meine vorgeschlagenen Änderungen am BSE-Test, Probleme mit Charakteren
auftreten, die "ängstlich" sind (war ja bisher nicht möglich), so ist weiteres Bugfixing
gefragt.
Dann ist es von Vorteil einen lesbareren Source zur Verfügung zu haben. Auch für Leute,
die am C lernen sind und evtl. etwas zum Bugfixing beitragen oder später mit dem Source
modden wollen.

Mein Vorschlag wäre jedes Quartal den aktuellen Source und die zugehörige compilierte exe
online zu stellen und so Schritt für Schritt das Programm zu verbessern.

Ich persönlich finde den Source zu unübersichtlich, zu wenig dokumentiert und das einige
Patches an der falschen Stelle stattfanden. (wohl mit der heißen Nadel gestrickt)
Dadurch lass ich mich aber nicht entmutigen. Deshalb werde ich als Anfang wie oben
erwähnt bald einen Post zum MERCPROFILESTRUCT verfassen.
Den Vorschlag Klassen einzuführen und auf C++ zu wechseln verkneif ich mir an dieser
Stelle. (wegduck)

Grüße

Snej

[Snej]

Dreifachpost nun, aber jeder hat sein eigenes Thema.

Ich hab ein schwerwiegendes Problem mit den Ladefunktionen festgestellt.

Näheres hier.
http://jagged.gamigo.de/ja_forum/showth ... post441538

Nicht verzweifeln

Snej

[Realist]

Moin,

generell finde ich den Code gar nicht so schlecht. Sicher man hätte einiges besser
machen können und vielleicht auch mehr Kommentare einfügen können.
Aber ich kann jetzt nicht nachvollziehen, warum man da einiges neuschreiben sollte
(bzgl. oberer Teil zwei Postings weiter oben).
Die Idee, dass du den Sourcecode jedoch dahingehend überarbeiten willst, damit
bessere Lesbarkeit erzielt wird, finde ich jedoch sehr gut, auch wenn mit dem
orginalen Source gut zurechtkomme. Aber wie du selbst gesagt hast, für Leute, die
nicht ganz fit in C sind oder den Code nicht genau kennen, mag das eine große Hilfe
sein.

Von der Idee einer C++-Konvertierung rate ich jedoch ab. Wenn du natürlich Lust dazu
hast, dann gerne...

Das unten angesproche "Problem" (wenns denn überhaupt eins ist) mit der
MERCPROFILESTRUCT versteh ich nicht. Worum geht es denn genau?

Gruß
Realist


edit
riodoro hat im ja2/ub forum diesen bug gepostet:

grundsätzlich lernt man im Schleichmodus am schnellsten. In der Goldversion glaube ich eh nur in diesem. Ansonsten kommt es auf die investierten AP an. ob man dabei liegt oder steht ist meiner Erfahrung nach gleichgültig. Beachte aber, dass ab einer gewissen Beweglichkeit (90) alle deine Aktionen einen Punkt teurer werden (Bug).

[Snej]

HotFix für das Einlesen der prof.dat

http://jagged.gamigo.de/ja_forum/showth ... post441686

Ähnliches wäre für SoldierTypeStruct zu machen, wovon imho nur die SaveFiles betroffen sind.

Grundfunktionen fürs Laden und Speichern sind ReadFile und WriteFile aus "windows.h"

Überhaupt ist es eine Mammutaufgabe die sizeof (structVar) von ReadFile bzw. FileRead zu trennen.

FileRead in 71 Dateien. (benutzt ReadFile)
structs in 334 Dateien
size of in 204 Dateien des Quelltextes.

Der Ansatz über FileRead scheint mir am vielversprechendsten zu sein.

Aber konzeptionell bräuchten wir für jeden betroffenen struct eine Read und Write Funktion. Für Code Modder die einen struct verändern wollen, müssen noch Kommentare hinterlassen werden, wo die Read und Write Funktionen dieses structs zu finden sind, damit sie auch diese anpassen.

Ich weiß auch nicht warum mir auf einmal das Wort Klasse in den Sinn kommt (wegduck) ...

Die Alternative ist, mit Hotfixes zu arbeiten, wann immer wieder ein Problem auftaucht.

Grüße Snej

[Bad Puma]

Wenn z.B. durch meine vorgeschlagenen Änderungen am BSE-Test, Probleme mit Charakteren
auftreten, die "ängstlich" sind (war ja bisher nicht möglich), so ist weiteres Bugfixing
gefragt.
Dann ist es von Vorteil einen lesbareren Source zur Verfügung zu haben. Auch für Leute,
die am C lernen sind und evtl. etwas zum Bugfixing beitragen oder später mit dem Source
modden wollen.

Mein Vorschlag wäre jedes Quartal den aktuellen Source und die zugehörige compilierte exe
online zu stellen und so Schritt für Schritt das Programm zu verbessern.

Das sind wirklich gute Ideen denn ich lerne bald auch C nach den Ferien. Mach ne Lehre zum Kaufmänischen Assistenten für Informationsverarbeitung.

Ach ja und wenn sich kein anderer findet würde ich den manipulierten Source auch online stellen.

MfG

Puma

[B0NECHUCKER]

hiho

@ Snej - was hältst du von der c++ version von defrog ?

http://members.chello.at/defrog/

(ist allerdings nicht wirklich dokumentiert, was defrog dadrin alles geändert hat ... )

gruss bone

[Snej]

So gut kenn ich den Quelltext leider nicht, also hab ich mich mir nur mal die "soldier profile type" und die "items types" im tactical ordner angesehen,
da ich mir die Dateien schon etwas mehr angesehen habe und mir dort am ehesten Klassen definieren würde.

Leider Fehlanzeige: Immer noch dergleiche struct enum define ... "super" code

Die BuildLogs in den Release Ordnern deuten eher auf eine systematische computergestützte Überprüfung der Dateien auf C++ Kompatibilität hin.

Also denke ich das vom Menschen gemachte Änderungen kaum zu finden sein werden. Ich lasse mich aber gern eines besseren belehren.

Klassen haben wegen der Datenabkapselung und der automatischen Typüberprüfung riesige Vorteile gegenüber dem jetzigen Code.
Kaum noch UINT8, UINT16, UINT32 Variablen - die kaum etwas aussagen wofür sie gedacht sind - sondern dafür
Item Gun;
oder
Stat Wisdom;
... halt was selbsterkärendes (träum ).

Grüße

Snej

[Tobeas]

Bugs die ich so kenne:
- Slödner kann über einen liegenden Söldner durch ne Wand springen (wurde nie offiziel gefixt)
- Monsterkönigin manchmal einfach nicht da
- Unterbrechungen funktionieren nicht immer....selbst wenn man lauter Söldner mir Erfahrung 10 hinstellt

Wünsche die Ich habe:
- Schnellmodus, bei dem die Milizen auch wenn man in der Map ist sich schneller bewegen und man nicht unbedingt jeden Schritt sieht....
- Undo-Möglichkeit, mit dessen Hilfe man einen, oder zwei Schritte (oder Runden) zurückgehen kann...

[Bad Puma]

Eine Undo-Funktion gibt es doch schon schu mal auf meiner Page unter Tipps da steht wie man eine oder zwei Runden zurück geht.

Bad Puma

[Tobeas]

ja, allerdings gibts dafür keinen Button

[smilingassassin]

hallo leute

ich weiss nicht, ob das wirklcih mit dem thread hier zu tun hat, aber so weit ich mich erinnere, werden ambinet sound snicht gespielt im game

hier hab ich nen screen mit nem kommentar/grund

in der "ambient.slf" findet sich dann auch ein "bad" file


könte man das evtl. im code in ordnung bringen, dass diese ambient sounds gespielt werden?

ausserdem kennt die exe ein/en "sounds/ssa" ordner oder Archiv... was aber nciht existiert genausowenig wie die sounds, die laut exe dadrin sein sollten

(ab offset 0020b070 in ja2 1.02)

ist das in späteren versionen (gold) anders? klappen da die ambient sounds?

thx