Archiv verlassen und diese Seite im Standarddesign anzeigen : [Skriptpaket] Gothic Free Aim (GFA) - ehemals Freies Zielen
mud-freak
06.08.2016, 18:40
http://www.youtube.com/watch?v=9CrFlxo21QwDas Skriptpaket "Gothic Free Aim" ermöglicht freies Zielen in Gothic und Gothic II für Fernkampf (Bogen, Armbrust) und Zauber.
Unter die Features dieses Skriptpakets fallen ausserdem
kritische Treffer nach getroffenen Körperteilen (z.B. Headshots),
anpassbares Kollisions- und Schadensverhalten (z.B. Instant-Knockout/-Kill),
das Wiederaufsammeln von Geschossen,
wahre Trefferwahrscheinlichkeit durch Streuung von Schüssen,
freies Bewegen während des Zielens,
und eine umfangreiche Konfiguration, um all dies frei anzupassen.
Eine komplette und ausführliche Dokumentation der Features und Anpassungsmöglichkeiten findet sich im Wiki (https://github.com/szapp/GothicFreeAim/wiki/Features#wiki-wrapper).
GFA Wiki (https://github.com/szapp/GothicFreeAim/wiki#wiki-content)
Dokumentation des gesamten Skriptpaketes mit ausführlicher Beschreibung der Anpassungsmöglichkeiten.
FAQ (https://github.com/szapp/GothicFreeAim/wiki/FAQ#wiki-wrapper)
Häufig gestellte Fragen.
Changelog (https://github.com/szapp/GothicFreeAim/wiki/Changelog#wiki-wrapper)
Alle Änderungen gegliedert nach Versionen.
Download (http://github.com/szapp/GothicFreeAim/releases)
Alle Releases des Skriptpaketes inklusive Release-Notes absteigend sortiert.
Demo Mods (https://github.com/szapp/GothicFreeAim/wiki/Demo-Mods#wiki-wrapper)
Gothic 1 und Gothic 2 mit freiem Zielen zum Ausprobieren der Features (Deutsch/English/Polnisch/Russisch).
https://upload.worldofplayers.de/files12/ko_fi_lineheight.png (https://ko-fi.com/szapp)
mud-freak
06.08.2016, 20:30
Da es in diesem Thread mittlerweile um die Implementierung von freiem Zielen geht, habe ich den Einleitungspost angepasst. Hier ist der originale Einleitungspost, in dem es damals noch um SPL_Blink ging.
Hallo!
Ich bin heute morgen auf der Tastatur ausgerutscht und habe aus Versehen einen netten Zauber entworfen.
Dabei gibt es ein Problem:
Während der Investphase (gedrückt halten) des Zaubers wird die Rotation um die Y-Achse deaktiviert; Man kann zwar nach oben und unten schauen, aber sich nicht drehen. In den Zaubern gibt es eine Eigenschaft canTurnDuringInvest, die genau das verspricht was ich will, allerdings scheint sie veraltet und ändert nichts.
Wer sich mit Aufrechterhaltungszaubern nicht so auskennt: Das ist im Grunde eine ähnliche Situation, wie wenn man beim Bogenschiessen gedrückt hält. Mausbewegungen nach oben und unten werden verarbeitet, die Drehung ist allerdings fest gefroren solange der Knopf gedrückt bleibt.
Ich bin mir nicht sicher, ob das am Input oder an der Kamera liegt. Aus den Enginefunktionen und Ausgaben aus dem zSpy wurde ich da nicht schlau.
Hat jemand eine Idee, wie ich die Mausblockade aufheben oder umgehen kann?
Ich hatte dazu gestern schon etwas im LeGo Thread geschrieben, aber vielleicht ist es besser in einem eigenen Thread, wo mir vielleicht jemand eine kreative, abstraktere Alternative anbieten kann.
Um dem ganzen ein bisschen Motivation mitzugeben, hier der Zauber um den es sich handelt. Das soll weniger Werbung als eine Vorschau sein, denn ich habe vor den Zauber in die Modderdatenbank zu stellen so bald ich damit zufrieden bin. Der Zauber ist angelehnt an 'Blink' aus Dishonored. So etwas ähnliches wurde schon einige Mal in Gothic gemoddet, allerdings hatten mir die Varianten nie gefallen. Im Moment ist mir - auf Grund der fehlenden Rotationsmöglichkeit - diese auch noch ein bisschen zu starr.
http://www.youtube.com/watch?v=__By3sgFogY
Die Lösung des Problems wäre übrigens auch der erste Schritt in Richtung freies Zielen mit Ikaurs/LeGo.
Habe das Problem lösen können. Erstaunlich einfach.
Es gibt eine Engine-Funktion, die den Helden drehen lässt und die Kamera automatisch mit bewegt (die hängt am Helden). Ich musste also nur die Mausposition abfragen und die Drehung updaten.
Klappt wirklich gut, ich bin beeindruckt. Hier ein kleiner Test: https://youtu.be/DuaaLR7B7tM Dabei wird die Position nicht zu häufig upgedated, daher sieht das noch etwas stotterig aus. Kann man aber alles ausbessern.
Ich stelle hier später die (wirklich wenigen) Zeilen Code dazu rein. Damit wäre der erste Schritt fürs freie Zielen getan. Jetzt muss man sich "nur" noch mit den Projektilen befassen. Nebenbei wäre aber zu erst einmal mein Zauber fertig. An der Stelle kann ich ja eigentlich hier gerade mal fragen, bevor ich ihn in die Modderdatenbank stelle: gibt es dazu Feedback (Sound gut?, Animation passend?, Effekt in Ordnung?)
Danke, dass du soetwas hochlädst. Genau solche Fortschritten sorgen bei mir überhaupt noch dafür, dass ich überhaupt noch modde. Wenn Gothic 2 auf dem Stand von 2003 geblieben wäre, hätte ich vermutlich schon lange aufgehört.
Der Zauber gefällt mir so sehr gut. Einzige Kritik von mir ist, dass bei kurzen Strecken dieser weiße Filter für meinen Geschmack etwas zu stark/hell ist. Soweit ich mich an Dishonored erinnere, war der Effekt dort weniger stark.
Möglicherweise ändert sich meine Meinung darüber auch, wenn ich es selbst ingame probiert habe und nicht nur über ein Video sehe. Ein großer Kritikpunkt ist es jedenfalls nicht - das kann so jederzeit hochgeladen werden. :)
Sehr schöne Arbeit!
Ich nehme mal an, dass du den Helden wirklich teleportierst und nicht nur schnell zum Ziel bewegst?
Dishonored macht letzteres, aber das sollte man vielleicht lieber nicht übernehmen ;) (https://youtu.be/vjqwYwGaub8?t=3416)
wow, schaut echt schon richtig gut aus!
Ich weiß nicht, ob das damals genau dieses Problem mit der Kamera war, aber "frei" zu fliegen als Zauber war ja recht blöd umzusätzen oder? Allerdings ging es da glaube ich um die Z-Achse Richtung. Hmm.
mud-freak
08.08.2016, 08:54
Danke, dass du soetwas hochlädst. Genau solche Fortschritten sorgen bei mir überhaupt noch dafür, dass ich überhaupt noch modde. Wenn Gothic 2 auf dem Stand von 2003 geblieben wäre, hätte ich vermutlich schon lange aufgehört.
Der Zauber gefällt mir so sehr gut. Einzige Kritik von mir ist, dass bei kurzen Strecken dieser weiße Filter für meinen Geschmack etwas zu stark/hell ist. Soweit ich mich an Dishonored erinnere, war der Effekt dort weniger stark.
Danke für das Feedback. Das stimmt, war mir nicht so aufgefallen. Vor allem bei Nacht sah das merkwürdig aus. Ich habe den Effekt jetzt verringert und schon mal in Skript ein Kommentar hinzugefügt, wo man den Effekt bei Bedarf ganz ausstellen könnte.
Sehr schöne Arbeit!
Ich nehme mal an, dass du den Helden wirklich teleportierst und nicht nur schnell zum Ziel bewegst?
Haha, ja wird einfach teleportiert. Das Skript an sich ist auch unglaublich simpel:
Erstelle Vob ohne Visual und hänge den Aim-FX dran.*
Solange der Zauber gedrückt gehalten ist:
Schiesse einen Trace Ray vom Caster entlang der Kamera-Achse.
Verschiebe das Aim-Vob an die Position, wo der Trace Ray ein Polygon schneidet (oder maximale Distanz)
(Erlaube Maus-Bewegung und aktualisiere Rotation)
Lösche Aim-Vob* und Aim-FX
Erstelle Waypoint an den letzten Koordinaten des Vobs
Teleportiere Caster
*Vielleicht kann ich das Vob auch weglassen. Das optimiere ich gerade noch.
Freies Zielen
Das freie Zielen habe ich mal universell für Zauber und Fernkampfwaffen eingebaut mittels Hook (mit Fadenkreuz usw.). Funktioniert sehr gut, allerdings nenne ich es mal nur "Free Look": Die Projektile schiessen zwar in die richtige Richtung und frei geschossene Pfeile machen auch Schaden, aber sie fliegen noch parallel zum Boden (egal ob man nach oben "zielt" = die Kamera nach oben zeigt). Trotzdem teile ich gern das Skript dazu (sobald ich es noch etwas optimiert habe), vielleicht kann jemand daran weiterarbeiten.
Neconspictor
08.08.2016, 11:24
Die Projektile schiessen zwar in die richtige Richtung und frei geschossene Pfeile machen auch Schaden, aber sie fliegen noch parallel zum Boden (egal ob man nach oben "zielt" = die Kamera nach oben zeigt)
Du müsstest den Look-Vector (und damit die Rotation) deines Geschosses an den Richtungsvektor deiner Flugbahn anpassen.
mud-freak
08.08.2016, 11:58
Du müsstest den Look-Vector (und damit die Rotation) deines Geschosses an den Richtungsvektor deiner Flugbahn anpassen.
Hört sich vernünftig an. Werde mal schauen wie schwierig es ist an das Projektil zu kommen. Zauber würden so schon komplett funktionieren, beim Fernkampf sollte man allerdings noch die Aim-Animation anpassen, sieht sonst etwas seltsam aus.
Was mir noch eingefallen ist: Man sollte vllt auch wie bei Blink einen Trace Ray schiessen, damit man die Healthbars von anvisierten Gegnern anzeigen kann (und wenn die Einstellung aktiviert ist, auch einen Fokus-Highlight)
MyGamingHD
08.08.2016, 14:09
Danke für das Feedback. Das stimmt, war mir nicht so aufgefallen. Vor allem bei Nacht sah das merkwürdig aus. Ich habe den Effekt jetzt verringert und schon mal in Skript ein Kommentar hinzugefügt, wo man den Effekt bei Bedarf ganz ausstellen könnte.
Haha, ja wird einfach teleportiert. Das Skript an sich ist auch unglaublich simpel:
Erstelle Vob ohne Visual und hänge den Aim-FX dran.*
Solange der Zauber gedrückt gehalten ist:
Schiesse einen Trace Ray vom Caster entlang der Kamera-Achse.
Verschiebe das Aim-Vob an die Position, wo der Trace Ray ein Polygon schneidet (oder maximale Distanz)
(Erlaube Maus-Bewegung und aktualisiere Rotation)
Lösche Aim-Vob* und Aim-FX
Erstelle Waypoint an den letzten Koordinaten des Vobs
Teleportiere Caster
*Vielleicht kann ich das Vob auch weglassen. Das optimiere ich gerade noch.
Freies Zielen
Das freie Zielen habe ich mal universell für Zauber und Fernkampfwaffen eingebaut mittels Hook (mit Fadenkreuz usw.). Funktioniert sehr gut, allerdings nenne ich es mal nur "Free Look": Die Projektile schiessen zwar in die richtige Richtung und frei geschossene Pfeile machen auch Schaden, aber sie fliegen noch parallel zum Boden (egal ob man nach oben "zielt" = die Kamera nach oben zeigt). Trotzdem teile ich gern das Skript dazu (sobald ich es noch etwas optimiert habe), vielleicht kann jemand daran weiterarbeiten.
Hört sich vernünftig an. Werde mal schauen wie schwierig es ist an das Projektil zu kommen. Zauber würden so schon komplett funktionieren, beim Fernkampf sollte man allerdings noch die Aim-Animation anpassen, sieht sonst etwas seltsam aus. Was mir noch eingefallen ist: Man sollte vllt auch wie bei Blink einen Trace Ray schiessen, damit man die Healthbars von anvisierten Gegnern anzeigen kann (und wenn die Einstellung aktiviert ist, auch einen Fokus-Highlight)
Soll das heißen, dass es mit deiner Arbeit, möglich wird, mit Zaubern und mit Bögen frei rum zu schießen?:D
Also das was sich viele Modder und viele Spieler seit langem erträumen. ;)
mud-freak
08.08.2016, 15:54
Soll das heißen, dass es mit deiner Arbeit, möglich wird, mit Zaubern und mit Bögen frei rum zu schießen?:D
Also das was sich viele Modder und viele Spieler seit langem erträumen. ;)
Ich fürchte das Fass hab ich jetzt aufgemacht, ja. Das war mit Blink gar nicht meine Absicht. Aber ich schaue mal wie weit ich damit komme; auf jeden Fall stelle ich es aber demnächst hier bereit was ich bisher habe.
ToDo-Checkliste:
Freie Maussteurung
Fernkampf und Magiekampf hooken (wenn im richtigen Kampfmodus und Aktionstaste gedrückt: "befreie" Maus)
Verschiedene Fadenkreuze für Zauber und Fernkampf an und ausstellen
Y-Flugrichtung der Projektile anpassen Wie: Pointer auf Projektile ausfindig machen
Bogen/Armbrust Animationen der Höhe anpassen Wie: siehe #4
Healthbar und Name (und Focus-Highlight) anzeigen wenn NPC anvisiert wird. Wie: Trace Ray trifft oCNPC, siehe Blink. EDIT: Geht vielleicht auch einfacher (siehe Focus.d aber ohne focus collect) EDIT2: Focus collect geht nicht. Klappt bisher nur mittels Boundingbox, was mir ein bisschen zu ungenau ist. EDIT: Halb so wild
Mausempfindlichkeit-Lock: Im Moment bewegt die Maus sich bei weniger bevölkerter Map schneller als bei volleren Wie: Bewegung skalieren an Hand von MEM_Timer.frameTimeFloat
Maus smoothing: Gothic ist nicht für Zielen gemacht, präzise Mausbewegungen (Zielen in der Ferne) sind bisher schwierig Wie: Schon halb getan (siehe Blink), allerdings registriert Gothic wirklich minimale Mausbewegungen nicht
Bonus: Fadenkreuz ändert grösse je nach Entfernung und ändert Farbe bei feindlichen Gegnern (letzteres vielleicht abschaltbar?) EDIT: Das mit der Farbe habe ich weggelassen
Bonus: Während des Zielens seitlich Strafen können. Wie: Weiss nicht ob das mit den Animationen klappt.
Bonus: Zugkraft simulieren. Was genau:
Einfach nur die Pfeilanlegen-Animation langsamer machen? Mal sehen.
Bei weniger Zug die Pfeilgeschwindingkeit verringern? Lohnt sich nicht.
Bei weniger Zug die Pfeilflugbahn anpassen (früherer Drop-off)? Getan!
Bei weniger Zug den Schaden verringern? Lohnt sich nicht.
Oder das Schiessen gar nicht erlauben bis der Bogen ganz gespannt ist? So funktioniert das bereits von Haus aus
STAND: Freies Zielen ist komplett implementiert und spielbereit. Nur noch die oben als "Bonus" gekennzeichneten Aufgaben stehen an.
Hab das hier mal so aufgeschrieben, falls jemand mal dran weiterarbeiten will wenn ichs nicht tue (Code dazu folgt dann).
Die Liste werde ich aktuell halten.
Übrigens: Das "frei rum schiessen" mit Pfeil und Bogen geht schon und ist fabelhaft (allerdings halt wie gesagt nicht in der Y-Flugrichtung). Vielleicht kann ich ein kurzen Clip hochladen für mehr "Motivation".
Ob sich diese Art das Problem zu lösen bewährt ist eine andere Frage. Das sehen wir dann.
Würde mich freuen, wenn jemand Ideen zu den Einträgen in der ToDo-Liste, die mir noch unklar sind ("noch keine Ahnung" und "gute Frage"), hat!
TheBigLeBRUCEky
08.08.2016, 16:24
Bogen/Armbrust Animationen der Höhe anpassen Wie: noch keine Ahnung
Ich habe zwar von dem, was du hier tust, kaum Ahnung, will auf diesen Punkt aber mit einer Gegenfrage antworten.
Sind diese Animationen nicht bereits vorhanden?
Der Held folgt doch mit Bogen/Armbrust dem anvisierten Ziel, im Targetlock sogar noch stärker.
Wenn man also auf einen erhöht stehenden Gegner zielt, wird die Fernwaffe doch nach oben gehalten.
Wenn du damit nichts anfangen kannst, dann sorry...vielleicht bringt dich das aber auch auf irgendeine Idee.
MfG
mud-freak
08.08.2016, 17:50
Sind diese Animationen nicht bereits vorhanden?
Der Held folgt doch mit Bogen/Armbrust dem anvisierten Ziel, im Targetlock sogar noch stärker.
Wenn man also auf einen erhöht stehenden Gegner zielt, wird die Fernwaffe doch nach oben gehalten.
Wenn du damit nichts anfangen kannst, dann sorry...vielleicht bringt dich das aber auch auf irgendeine Idee.
Ja hilft auf jeden Fall, danke! Man müsste schauen in wie weit man die Animationen starten kann (oder ab das auch intern leichter geht). Oder vielleicht den Hero auf was anderes Zielen lassen, damit er das von selbst macht. (Allerdings funktioniert die Kollision dann sicherlich nicht mehr).
Ich habe mal den bisherigen Fortschritt auf Video aufgenommen. Jetzt ist es aber weniger Motivation, als Demotivation. Denn ich hab eher Wert drauf gelegt zu demonstrieren was nicht funktioniert, als hier falsche Versprechen zu geben.
Das schwierige Zielen habe ich in Blink schon verbessern können. Das ist beim Bogenschiessen noch nicht dabei, deshalb ist das da noch ein Krampf: Die Maus hängt fest bis man sie schnell genug bewegt (Gothics Responsiveness ist da ziemlich schlecht), deshalb steht die Maus so lang still und springt dann zu weit, wenn ich sie zu weit bewege.
http://www.youtube.com/watch?v=mcQsdLhs1oM
MyGamingHD
08.08.2016, 17:57
Ich fürchte das Fass hab ich jetzt aufgemacht, ja. Das war mit Blink gar nicht meine Absicht. Aber ich schaue mal wie weit ich damit komme; auf jeden Fall stelle ich es aber demnächst hier bereit was ich bisher habe.
Ich will dich damit nicht unter druck setzen oder dich zu etwas verpflichten, ich war eher fasziniert was die Modding Szene gerade für Fortschritte macht.
Grüße Viktor alias MyGamingHD
TheBigLeBRUCEky
08.08.2016, 18:04
Ja hilft auf jeden Fall, danke! Man müsste schauen in wie weit man die Animationen starten kann (oder ab das auch intern leichter geht). Oder vielleicht den Hero auf was anderes Zielen lassen, damit er das von selbst macht. (Allerdings funktioniert die Kollision dann sicherlich nicht mehr).[/video]
Der Gedanke, den ich dabei hatte, war, dass du die Methode, wie Gothics Targetlock funktioniert, eventuell auf dein Fadenkreuz übertragen kannst.
Das Video sieht schon sehr vielversprechend aus...respekt!
Edit:
Mausempfindlichkeit-Lock: Im Moment bewegt die Maus sich bei weniger bevölkerter Map schneller als bei volleren Wie: gute Frage
Wieder nur so ein Gedanke:
Die Vermutung liegt ja nahe, dass das mit den unterschiedlichen FPS bei leeren bzw. vollen Maps zusammenhängt.
Vielleicht könnte man die Mausempfindlichkeit von den aktuellen FPS abhängig machen, falls sowas überhaupt möglich ist.
Normalerweise muss man ja ins Menü, um die Mausempfindlichkeit zu verändern.
MfG
mud-freak
09.08.2016, 07:58
Ich will dich damit nicht unter druck setzen oder dich zu etwas verpflichten, ich war eher fasziniert was die Modding Szene gerade für Fortschritte macht.
Keine Sorge, so war das nicht gemeint. Ich schau mir das aus eigenem Interesse an. Dass es Leute interessiert ist ein Bonus und sorgt für Motivation.
Die Vermutung liegt ja nahe, dass das mit den unterschiedlichen FPS bei leeren bzw. vollen Maps zusammenhängt.
Vielleicht könnte man die Mausempfindlichkeit von den aktuellen FPS abhängig machen, falls sowas überhaupt möglich ist.
Normalerweise muss man ja ins Menü, um die Mausempfindlichkeit zu verändern.
Das ist ein sehr guter Gedanke. Hast mich auf die Idee gebracht einfach die Mausbewegung mit der verstrichenen Zeit vom letzten Frame zu skalieren. Die wird im zCTimer gespeichert:
var int frameTimeFloat; //zREAL [msec] //Zeit der zwischen diesem und dem letzten Frame verstrichen ist
Der Gedanke, den ich dabei hatte, war, dass du die Methode, wie Gothics Targetlock funktioniert, eventuell auf dein Fadenkreuz übertragen kannst.
Ja, mittlerweile bin ich am überlegen, ob mein Ansatz so der beste ist - für Blink funktioniert es ja fabelhaft. Dort wird ja nichts "geschossen". Aber für das wirkliche Anvisieren bedarf es vielleicht einem anderen Weg.
Z.B.: anstatt das automatische Zielen auszuhebeln und den Hero durch Mausbewegung zu drehen, wäre es vielleicht einfacher das automatische Zielen auf ein unsichtbares Vob zu zwingen und nicht den Hero sondern, das Vob zu bewegen (dann dreht der Hero ja automatisch mit). Dann spart man sich auch das ganze Anpassen von Aim-Animationen und des Schusswinkels vom Boden. Allerdings weiss ich nicht, ob das Projektil dann noch Schaden gegen "im Weg-stehende" NPCs macht, wenn es eigentlich das unsichtbare Vob als eingetragenes Ziel hat.
Ich probier einfach ein bisschen. Ich bin aber eher am Shortgame als am Longgame interessiert bin. D.h. ich stelle hier lieber immer Mal wieder aus dem nichts irgendwelche kleinen Features oder Zauber zur Verfügung, als mich grossen Projekten zu verschreiben. Ich warte mal eine Woche ab, wenn ich bis dahin keine grossen Fortschritte gemacht habe, stell ich das Free-Aim erstmal auf Eis und stell hier die bisherigen Skripte und Gedanken zur Verfügung und hoffe, dass jemand daran weiterarbeiten kann.
TheBigLeBRUCEky
09.08.2016, 11:31
Z.B.: anstatt das automatische Zielen auszuhebeln und den Hero durch Mausbewegung zu drehen, wäre es vielleicht einfacher das automatische Zielen auf ein unsichtbares Vob zu zwingen und nicht den Hero sondern, das Vob zu bewegen (dann dreht der Hero ja automatisch mit). Dann spart man sich auch das ganze Anpassen von Aim-Animationen und des Schusswinkels vom Boden. Allerdings weiss ich nicht, ob das Projektil dann noch Schaden gegen "im Weg-stehende" NPCs macht, wenn es eigentlich das unsichtbare Vob als eingetragenes Ziel hat.
Ich probier einfach ein bisschen. Ich bin aber eher am Shortgame als am Longgame interessiert bin. D.h. ich stelle hier lieber immer Mal wieder aus dem nichts irgendwelche kleinen Features oder Zauber zur Verfügung, als mich grossen Projekten zu verschreiben. Ich warte mal eine Woche ab, wenn ich bis dahin keine grossen Fortschritte gemacht habe, stell ich das Free-Aim erstmal auf Eis und stell hier die bisherigen Skripte und Gedanken zur Verfügung und hoffe, dass jemand daran weiterarbeiten kann.
Wieder meine Gedanken dazu...möglich, dass du für die Probleme, die ich da sehe, eine Lösung weißt.
Ich vermute schon, dass das Geschoss an Zielen Schaden verursacht, die im Weg stehen.
Ist sonst ja auch so, wenn man einen Gegner im Targetlock hat und ein anderer im Weg steht, bekommt der andere auch Schaden.
Das Problem, dass ich eher sehe, ist, dass vermutlich der Verteidigungswert gegen Geschosse, des anvisierten Ziels, für die Schadensberechnung herangezogen wird.
Dein Vob müsste somit vermutlich Verteidigungswerte haben, außerdem könnten dann Ziele, die immun gg. Geschosse sind und im Weg stehen, Schaden erleiden.
So ähnlich ist es ja auch bei Zaubern...
Edit: Außerdem würde der Schaden nicht stimmen...er würde immer von der Verteidigung des Ziel-Vobs abhängen, nicht von der Verteidigung des Getroffenen.
MfG
Y-Flugrichtung der Projektile anpassen Wie: Pointer auf Projektile ausfindig machen
This address Enables you to control an arrow .
void __thiscall oCAIArrow :: SetupAIVob ( zCVob zCVob * * * zCVob )
Arguments
1 - Arg ) What?
2 - Arg ) Whence ?
3 - Arg ) Where ?
Maybe this will help .
mud-freak
10.08.2016, 06:54
This address Enables you to control an arrow .
void __thiscall oCAIArrow :: SetupAIVob ( zCVob zCVob * * * zCVob )
Arguments
1 - Arg ) What?
2 - Arg ) Whence ?
3 - Arg ) Where ?
Maybe this will help .
Thank you, Siemekk. Do you know why there is three arguments? Isn't the 'what' (1st arg) clear by the object (oCAIArrow)?
This engine function might even be easier (but I am not sure):
0x6A0FF0 void __thiscall oCAIArrow::SetTarget(zCVob *)
The problem is, that both functions need a zCVob, instead of a zCVec. I don't know if it would register damage on a different target.
Eine dieser Funktionen hier sollte übrigens das Animationsproblem (wo der Bogen hinzielt) lösen.
0x6B6360 void __thiscall oCAniCtrl_Human::SetLookAtTarget(class zVEC3 &)
0x6B6490 void __thiscall oCAniCtrl_Human::SetLookAtTarget(class zCVob *)
Ich muss mal schauen wie wackelig dieser momentane Ansatz ist. Auf eine zu "hackige" Lösung habe ich keine Lust - die ist dann zu instabil und buggy. Sie muss sich schon gut anfühlen und sound sein.
zCVob- vob to which arrow want to fly. If zCvob =0 arrow fly straight :)
mud-freak
13.08.2016, 08:02
zCVob- vob to which arrow want to fly. If zCvob =0 arrow fly straight :)
Thank you. With the help of Lehona, it looks like this now: https://youtu.be/Fz97Z9Z5UO0
We took a similar approach.
Der Fix im Video stellt schon den Kern vom freien Zielen da. Es wird immer aufs Fadekreuz gezielt (auch wenn man zu dicht vor einer Wand/Hinderniss steht oder freies Feld vor sich hat). Dass der Hero im Video nicht so präzise trifft, liegt am Bogenschiessentalent. Das ist im Video nicht auf 100%, sondern auf 60%. D.h. eine Treffgenauigkeit brauche ich nicht zu implementieren, das wird vom Talent übernommen.
Jetzt fehlen nur noch die richtigen Animationen (dass der Hero mit dem Bogen auch dahin zielt wo das Fadenkreuz ist), die Anzeige von Namen und Healthbar eines anvisierten Gegners, und eine Verbesserung in der Maussteuerung.
Zauber sind leider etwas komplizierter. Auf Grund der Effekte brauchen sie ein vernünftiges Ziel, das sich sowohl in Line-of-Sight befindet, als auch vom richtigen Typ ist. Ausserdem fliegt ein Zauber, wenn er nicht anders geskriptet ist(!) auf sein Ziel und ignoriert Kollision mit anderen Gegenständen. Wer schon mal im richtigen Moment von einem herannahenden Zauber einen Schritt zurück gegangen ist, weiss auch, dass Zauber nur bis zu der originalen Position ihres Zielvob fliegen und dort aufhören, egal ob es einen Treffer gab oder nicht.
Ich probiere gerade die entsprechenden Engine-Funktionen, die ein Target als valide oder invalide markieren, zu hooken. Aber vielleicht wäre es besser sich erst einmal, um die Vervollständigung des freien Zielens mit Bogen zu kümmern. Dann wäre das schon mal fertig. Da muss ich noch herausfinden, wie Gothic normalerweise die Zielanimationen startet.
mud-freak
14.08.2016, 11:48
Die richtigen Animationen sind drin. Intern ist das etwas durcheinander. Das optimiere ich jetzt, danach kommt das Anzeigen der Healthbars von Gegnern.
An dieser Stelle schon mal einen grossen Dank an Lehona, der mir dabei viel weiter geholfen hat.
http://www.youtube.com/watch?v=IPq7n7_d6UM
BlackBat
14.08.2016, 12:35
Das ist ziemlich cool :) nun müsste man sich nur angewöhnen Gothic mit Maus und Tastatur zu spielen. :D
Vielen Dank, dass ihr eure Freizeit ins Gothic Modding investiert. Vorallem nachdem du, mud-freak, dich eigentlich zurückziehen wolltest.
Sehr schön! Genau auf so etwas habe ich gewartet!
Wird das dann als Mod veröffentlicht?
Und wird Magie dann noch frei beweglich sein?
Wenn man das als Mod machen will, könnte man beispielsweise auch das Rennen mit einpflegen (abhängig von der Ausdauer..Aber dann bräuchte man Lehrer dafür).
Milky-Way
14.08.2016, 17:10
Sehr schön! Genau auf so etwas habe ich gewartet!
Wird das dann als Mod veröffentlicht?
Und wird Magie dann noch frei beweglich sein?
Wenn man das als Mod machen will, könnte man beispielsweise auch das Rennen mit einpflegen (abhängig von der Ausdauer..Aber dann bräuchte man Lehrer dafür).
Jeder Modder kann das in seine Mod einbauen. Ob es als einzelne Mod (nicht kompatibel mit anderen Mods, Patches) sinnvoll ist, weiß ich nicht.
Naja zumindest wäre es eine Bereicherung für alle, da nicht jeder eigenständige Mods mag :dnuhr:
Neconspictor
14.08.2016, 19:43
Maus smoothing: Gothic ist nicht für Zielen gemacht, präzise Mausbewegungen (Zielen in der Ferne) sind bisher schwierig Wie: Schon halb getan (siehe Blink), allerdings registriert Gothic wirklich minimale Mausbewegungen nicht
Wenn ich ingame die Kamera mit der Maus drehe habe ich zumindest das Gefühl eine fürs Zielen ausreichend feine Steuerung zu haben. Bei einem deiner Videos hat man aber die einzelnen "Sprünge" der Maus deutlich gesehen.
Ich glaube daher, dass Gothic durchaus feine Mausbewegungen registriert.
Wie sieht denn bis jetzt deine Maussteuerung aus?
Wenn ich ingame die Kamera mit der Maus drehe habe ich zumindest das Gefühl eine fürs Zielen ausreichend feine Steuerung zu haben. Bei einem deiner Videos hat man aber die einzelnen "Sprünge" der Maus deutlich gesehen.
Ich glaube daher, dass Gothic durchaus feine Mausbewegungen registriert.
Wie sieht denn bis jetzt deine Maussteuerung aus?
Er hat sich jetzt am LeGo-Cursor orientiert (technisch), da funktioniert das alles wunderbar weich ;)
Vorher war es (erstaunlicherweise) echt merkwürdig.
Neconspictor
14.08.2016, 21:14
Super! Dann hat sich das Problem ja erledigt :)
mud-freak
15.08.2016, 07:28
Das ist ziemlich cool :) nun müsste man sich nur angewöhnen Gothic mit Maus und Tastatur zu spielen. :D
Danke, da hast du mich auf etwas wichtiges hingewiesen! Es muss unbedingt abgefragt werden, ob die Maussteuerung im Menu eingeschaltet ist, sonst sind Tastatur-only Spieler aufgeschmissen. Für Tastatur-Spieler wird dann das traditionelle Zielen aktiviert.
Wenn ich ingame die Kamera mit der Maus drehe habe ich zumindest das Gefühl eine fürs Zielen ausreichend feine Steuerung zu haben. Bei einem deiner Videos hat man aber die einzelnen "Sprünge" der Maus deutlich gesehen.
Ich glaube daher, dass Gothic durchaus feine Mausbewegungen registriert.
Wie sieht denn bis jetzt deine Maussteuerung aus?
Er hat sich jetzt am LeGo-Cursor orientiert (technisch), da funktioniert das alles wunderbar weich ;)
Vorher war es (erstaunlicherweise) echt merkwürdig.
Ich habe es mittlerweile mal kurz mit den LeGo-Cursor skripten versucht. Teilweise klappt es, aber so ganz gefixt habe ich es noch nicht (ich musste die übernommenen Teile aus den Cursor-Skripten, etwas anpassen). So viel habe ich aber noch nicht rumprobiert. Ich muss noch einmal feststellen, ob es dies mal wirklich an der Mausabfrage liegt oder ob das Anpassen der Rotation des Heros in jedem Frame evtl. kleine Bewegungen blockiert (dürfte aber nicht der Fall sein).
Edit: Tatsächlich hat es an der Drehung gelegen. Jetzt funktioniert die Maussteuerung sehr gut. Habe mal einen aus 200m Entfernung weggesniped.
Ausserdem habe ich mal die Kamera über die Schulter des Helden verschoben, damit sein Kopf nicht immer im Weg (unter dem Fadenkreuz) liegt und man vernünftig zielen kann. Mittleweile fühlt sich das freie Zielen vernünftig an.
Edit:
Sehr schön! Genau auf so etwas habe ich gewartet!
Wird das dann als Mod veröffentlicht?
Und wird Magie dann noch frei beweglich sein?
Wenn man das als Mod machen will, könnte man beispielsweise auch das Rennen mit einpflegen (abhängig von der Ausdauer..Aber dann bräuchte man Lehrer dafür).
Für Magie habe ich das Ganze auch vor, ja. Das funktioniert zwar ähnlich ist aber um einiges komplizierter und war bisher noch ohne Erfolg.
Das als alleinstehende Mod zu veröffentlichen wäre eine Möglichkeit, aber wie schon erwähnt wäre es wohl sinnvoller, das freie Zielen in bestehende Mods einbauen zu lassen. Wenn es in einem spielbaren Zustand ist, werde ich erst einmal die Skripte dafür hier bereit stellen. Vielleicht kann mir dann jemand, der über aktuelle und erfolgreiche Erweiterungsmods besser informiert ist als ich, helfen die Macher dieser auf das freie Zielen aufmerksam zu machen, damit sie es ggf. in ihre Mods einbauen können.
Was du mit Rennen meinst, habe ich nicht gleich verstanden. Worauf du mich aber aufmerksam gemacht hast, ist, dass es schön wäre wenn man während dem Zielen auch noch seitliche Schritte machen könnte. Denn wenn der Spieler beim freien Zielen auf einem Punkt festklebt, sehe ich ehrlich gesagt keinen wirklichen Sinn/Vorteil im freien Zielen.
Jemand der sich mit Animationen auskennt: Ich weiss, dass es da wohl mehrere "Layers" von Animationen gibt, die man gleichzeitig/übereinander abspielen kann. Kann mir da jemand sagen, ob es theoretisch möglich wäre die Strafe-Animation (alles unterhalb der Hüfte) in einem anderen Layer als die Aim-Animation (alles oberhalb der Hüfte) gleichzeitig abspielen zu lassen?
BlackBat
16.08.2016, 11:03
Eine Frage. Wird beim Schießen auch die Zugkraft simuliert? Wenn ich zum Beispiel nur kurz die Maustaste zum schießen drücke, dürfte ich ja nicht die volle Zugkraft erreichen.
Bisher noch nicht, aber das einzubauen wäre nicht unbedingt weiter schwierig.
mud-freak
17.08.2016, 14:19
Eine Frage. Wird beim Schießen auch die Zugkraft simuliert? Wenn ich zum Beispiel nur kurz die Maustaste zum schießen drücke, dürfte ich ja nicht die volle Zugkraft erreichen.
Ich habe das mal (wie auch Strafen beim Zielen) als "Bonus" in die ToDo Liste aufgenommen (d.h. darum kümmere ich mich nachdem die wichtigeren Sachen alle funktionieren). Meine Gegenfrage ist, was du dir genau unter simulierter Zugkraft vorstellst. Mir fallen da fünf verschiedene Effekte ein. Nachfolgend steht die Liste. An was davon hattest du gedacht?
ToDo-Checkliste:
...
9. Bonus: Während des Zielens seitlich strafen können. Wie: Weiss nicht ob das mit den Animationen klappt.
10. Bonus: Zugkraft simulieren. Was genau:
Einfach nur die Pfeilanlegen-Animation langsamer machen?
Bei weniger Zug die Pfeilgeschwindingkeit verringern?
Bei weniger Zug die Pfeilflugbahn anpassen (früherer Drop-off)?
Bei weniger Zug den Schaden verringern?
Oder das Schiessen gar nicht erlauben bis der Bogen ganz gespannt ist?
BlackBat
17.08.2016, 15:51
Ich denke realistisch wären diese 4 Punkte zusammen. Allerdings hört sich das jetzt für einen Laien wie mich ziemlich aufwändig an.
Einfach nur die Pfeilanlegen-Animation langsamer machen?
Bei weniger Zug die Pfeilgeschwindingkeit verringern?
Bei weniger Zug die Pfeilflugbahn anpassen (früherer Drop-off)?
Bei weniger Zug den Schaden verringern?
königsgardist
31.08.2016, 14:20
Hallo,
ich wollte schnell fragen, wie es voran geht. :)
mfg königsgardist
mud-freak
31.08.2016, 16:24
Hallo,
ich wollte schnell fragen, wie es voran geht. :)
mfg königsgardist
Hi, ich war ein paar Tage unterwegs und bin jetzt zurück. Der letzte Stand (Upload-Datum beachten) ist dieser: https://youtu.be/eFDMM3R3Yvw
Die Grundlagen sind gelegt und freies Zielen (für Fernkampf) ist spielbereit. Seit dem Video (21.8.) hat sich nach aussen hin nicht viel geändert. Im Video kann man sehen wie die NPCs vernünftig erfasst und das Fadenkreuz sich der Zielentfernung anpasst (ähnlich wie in Gothic 3). Man sieht allerdings auch, dass das in Ausnahmefällen (0:18 - 0:20 im Video) nicht immer klappt.
Auf der Liste steht jetzt (1.) diesen Bug im Video zu beheben und (2.) seitliches Bewegen beim Zielen zu implementieren. Was Zugkraft angeht, bin ich etwas skeptisch, ob sich das lohnt, denn meiner Erfahrung nach ist das nach zwei, drei mal Schiessen uninteressant und trägt nicht gross zur Spielmechanik bei. Was trotzdem interessant ist und worum ich mich noch bemühen werde ist, dass (3.) Projektile mit der Zeit abfallen (also eine gebogene Flugbahn haben), denn im Normalfall fliegt ein Pfeil schnurgerade.
Edit: Ich will an dieser Stelle aber nicht vorenthalten, dass ich den Fortschritt mit der Fokuserfassung aus dem Video aufgrund des Bugs komplett neu implementieren muss.
königsgardist
01.09.2016, 09:25
Hi, ich war ein paar Tage unterwegs und bin jetzt zurück. Der letzte Stand (Upload-Datum beachten) ist dieser: https://youtu.be/eFDMM3R3Yvw
Die Grundlagen sind gelegt und freies Zielen (für Fernkampf) ist spielbereit. Seit dem Video (21.8.) hat sich nach aussen hin nicht viel geändert. Im Video kann man sehen wie die NPCs vernünftig erfasst und das Fadenkreuz sich der Zielentfernung anpasst (ähnlich wie in Gothic 3). Man sieht allerdings auch, dass das in Ausnahmefällen (0:18 - 0:20 im Video) nicht immer klappt.
Auf der Liste steht jetzt (1.) diesen Bug im Video zu beheben und (2.) seitliches Bewegen beim Zielen zu implementieren. Was Zugkraft angeht, bin ich etwas skeptisch, ob sich das lohnt, denn meiner Erfahrung nach ist das nach zwei, drei mal Schiessen uninteressant und trägt nicht gross zur Spielmechanik bei. Was trotzdem interessant ist und worum ich mich noch bemühen werde ist, dass (3.) Projektile mit der Zeit abfallen (also eine gebogene Flugbahn haben), denn im Normalfall fliegt ein Pfeil schnurgerade.
Edit: Ich will an dieser Stelle aber nicht vorenthalten, dass ich den Fortschritt mit der Fokuserfassung aus dem Video aufgrund des Bugs komplett neu implementieren muss.
Danke vielmals! Das sieht schon mal nicht schlecht aus. :) Alles Gute weiterhin.
mfg königsgardist
mud-freak
07.09.2016, 21:22
Ich wollte mich mal wieder melden. Heute ist kurzfristig eine neue Pflicht aufgekommen, der ich in nächster Zeit nachkommen muss, so dass ich erst einmal weniger/bis gar nicht am freien Zielen arbeiten werde. Macht so vielleicht keinen merklichen Unterschied hier nach aussen hin - doch habe ich in den vergangen Wochen viel Zeit darin investiert. Ich wollte das hier nur schreiben für die Leute, die evtl. darauf warten.
Vielleicht schaffe ich es doch noch irgendwie am Wochenende ein weiteres kleines Video zu drehen, um den bisherigen Stand zu demonstrieren, um das Warten bis ich weiterarbeiten kann zu erleichtern (oder erschweren?). Hier erst einmal ein Liste von fertigen Featuren und Fortschritten. [Edit: Liste verschoben in den Einleitungspost]
[...]
Das ist immer ein grosses Problem in der Implementierung von Shootern, da das Projektil nicht vom Zentrum des Bildschirm (wo das Fadenkreuz ist) los fliegt, sondern von der Waffe (daran ändert auch Firstpersonview nichts). Vollständig implementiert habe ich schon, dass das Projektil dort auftrifft, wo man hinzielt (egal wie weit entfernt das nächste Hindernis ist). Das wird also dynamisch errechnet. Damit ist das Problem vollständig gelöst.
Allerdings macht jetzt die gebogene Flugbahn (s.o.) Probleme, denn damit kann ich vorher nicht feststellen wo das Projektil auftreffen wird. Vertikal kein Problem, allerdings horizontal, denn so "treffen" Projektil und Fadenkreuz nicht immer aufeinander. Da wie gesagt die Waffe nicht im Zentrum des Bildschirms ist, kreuzt das Projektil das Fadenkreuz und fliegt nach links/rechts weiter (schwer zu erklären). Die Lösung dazu habe ich schon, die allerdings ein neues Problem hervor ruft: Ich habe die Kamera jetzt so ausgerichtet, dass sie horizontal genau auf der Position ist, wo das Projektil los fliegt. Das Projektil fliegt also nun genau entlang des Fadenkreuzes (Problem gelöst). Neues Problem: Dieser "Trailstrip" also der Effekt den ein Pfeil zurücklässt, an dem man erkennt wo der Pfeil entlang fliegt, ist von diesem Winkel nicht zu sehen (ist ja genau dahinter). Dazu muss ich mir jetzt noch etwas einfallen lassen, denn man sieht so nun überhaupt nicht wo man hinschiesst. Gelöst durch zusätzlichen Trailstrip FX
Wie man sieht ist das Grundgerüst mehr als fertig. Rum-zu-schiessen macht schon extrem Spass und fühlt sich wirklich gesund und abgerundet an. Man kann NPCs über lange Distanz genüsslich "weg snipen". Was übrigbleibt sind die oben genannten Optimierungen und Extrafeatures (wie Headshot, usw.). Worauf ich bisher sehr wert gelegt habe und das kann ich an dieser Stelle hier schon ein mal sagen, ist, dass über Konstanten oben im Skript alles eingestellt werden kann was man will. Das macht das Einbinden in eine Mod sehr angenehm, wenn man nicht die Funktionen ändern muss, sondern alle Einstellungsmöglichkeiten als Konstanten auf einen Blick vor Augen hat. Ca. so hat man sich das vorzustellen (wird sich sicher noch ändern):
/* Free aim settings */
const int FREEAIM_FOCUS_ACTIVATED = 1; // Enable/Disable focus collection (disable for performance)
const int FREEAIM_CAMERA_X_SHIFT = 0; // Set to 1, if camera is in shoulder view (not recommended)
const int FREEAIM_MAX_DIST = 5000; // 50 meters. For shooting and crosshair adjustments
const int FREEAIM_DRAWTIME_MIN = 1110; // Minimum draw time (ms). Do not change - tied to animation
const int FREEAIM_DRAWTIME_MAX = 2500; // Maximum draw time (ms) for best trajectory
const int FREEAIM_TRAJECTORY_ARC_MAX = 400; // Maximum distance at which the trajectory drops off
const int FREEAIM_TREMOR = 12; // Camera tremor when exceeding FREEAIM_DRAWTIME_MAX
const float FREEAIM_ROTATION_SCALE = 0.16; // Turn rate. Non weapon mode is 0.2 (zMouseRotationScale)
const float FREEAIM_PROJECTILE_GRAVITY = 0.1; // The gravity decides how fast the projectile drops
const int FREEAIM_PROJECTILE_COLLECTABLE = 1; // Make use of the projectile collectible script
const int CROSSHAIR_MIN_SIZE = 16; // Smallest crosshair size in pixels (longest range)
const int CROSSHAIR_MED_SIZE = 20; // Medium crosshair size in pixels (for disabled focus)
const int CROSSHAIR_MAX_SIZE = 32; // Biggest crosshair size in pixels (closest range)
Wie gesagt, ein Video folgt vielleicht noch am Wochenende. Das war jetzt erstmal so der Stand bevor es in ca. drei Wochen weitergeht. Ich hoffe ich konnte so etwas Transparenz darein bringen.
königsgardist
07.09.2016, 22:49
Das ist dir sehr gut gelungen! Vielen Dank- ich freu mich schon wie irre auf dein Feature! Geht es, dass deine Mod als eine Art "Patch" erscheint oder nicht?
mfg königsgardist
Milky-Way
07.09.2016, 23:06
Wie funktioniert denn momentan die Trefferwahrscheinlichkeit / Bogenskill? Geht der Pfeil dann neben das Fadenkreuz oder auch weiterhin genau auf das Fadenkreuz und verursacht nur ggf. keinen Schaden?
Headshot 5% Bisher nur eine Idee. Finde ich aber wichtig beim freien Zielen.
If this (https://github.com/degenerated1123/GD3D11/blob/master/D3D11Engine/zCModel.h) struct of class zCModelNodeInst is correct, all what you need is comparing projectile bounding box with head bounding box. These functions should help:
func int Npc_GetModel (var c_npc slf)
{
CALL__thiscall (MEM_InstToPtr (slf), 7571232);
return CALL_RetValAsPtr ();
};
func int zCModel_SearchNode (var c_npc slf, var string node)
{
var int ptr; ptr = Npc_GetModel (slf);
CALL_zStringPtrParam (node);
CALL__thiscall (ptr, 5758960);
return CALL_RetValAsPtr ();
};
func void SomeFunction ()
{
var zCModelNodeInst node; node = _^ (zCModel_SearchNode (target, "Bip01 Head"));
[...]
};
mud-freak
08.09.2016, 06:51
Das ist dir sehr gut gelungen! Vielen Dank- ich freu mich schon wie irre auf dein Feature! Geht es, dass deine Mod als eine Art "Patch" erscheint oder nicht?
Das freut mich. Genau: Zum einen werde ich hier die Skript(e) für Modder veröffentlichen, die es dann einfach in ihre Mods einbauen können, zum anderen werde ich (für nicht-Modder) eine simple Erweiterungsmod zum normalen Gothic 2 im Modifikationsforum veröffentlichen. Die kann dann jeder Spielen. Das wird dann mehr als eine Art Beta-Test fungieren mit dem es mir leichter fallen wird mögliche Bugs und Feedback zu verarbeiten.
Wie funktioniert denn momentan die Trefferwahrscheinlichkeit / Bogenskill? Geht der Pfeil dann neben das Fadenkreuz oder auch weiterhin genau auf das Fadenkreuz und verursacht nur ggf. keinen Schaden?
Bisher schiesst man noch genau dahin wo man hinzielt. Die Berechnung der Trefferwahrscheinlichkeit überlasse ich noch Gothic. Wo du das gerade aufbringst, würde ich das gern noch ändern, weil mich das schon immer gestört hat (man trifft den Gegner merklich, aber es gibt nur in x% der Fälle Schaden - das ist hässlich). Darüber habe ich noch nicht viel nachgedacht, aber ich würde eine Streuung um das Fadenkreuz einbauen (abhängig vom Bogenskill als auch von der Zugkraft) und dann müsste ich die Prozentberechnung nach Treffer von Gothic ausschalten - die muss ich dann aber noch finden. Ich nehme das mal oben in die Liste auf. Danke, dass du das erwähnst.
If this (https://github.com/degenerated1123/GD3D11/blob/master/D3D11Engine/zCModel.h) struct of class zCModelNodeInst is correct, all what you need is comparing projectile bounding box with head bounding box.
I haven't thought a lot about the headshot detection so far. So thank you for your thoughts and the code. This will definitely help!
Milky-Way
08.09.2016, 16:19
Bisher schiesst man noch genau dahin wo man hinzielt. Die Berechnung der Trefferwahrscheinlichkeit überlasse ich noch Gothic. Wo du das gerade aufbringst, würde ich das gern noch ändern, weil mich das schon immer gestört hat (man trifft den Gegner merklich, aber es gibt nur in x% der Fälle Schaden - das ist hässlich). Darüber habe ich noch nicht viel nachgedacht, aber ich würde eine Streuung um das Fadenkreuz einbauen (abhängig vom Bogenskill als auch von der Zugkraft) und dann müsste ich die Prozentberechnung nach Treffer von Gothic ausschalten - die muss ich dann aber noch finden. Ich nehme das mal oben in die Liste auf. Danke, dass du das erwähnst.
Genau so hatte ich mir das auch vorgestellt :)
Dahingehend vielleicht interessant:
http://forum.worldofplayers.de/forum/threads/1475456-Armbrust-skillen?p=25080193&viewfull=1#post25080193
mud-freak
08.09.2016, 16:29
Genau so hatte ich mir das auch vorgestellt :)
Dahingehend vielleicht interessant:
http://forum.worldofplayers.de/forum/threads/1475456-Armbrust-skillen?p=25080193&viewfull=1#post25080193
Danke, ich werde die Augen in dem Thread offen halten. Vielleicht sucht Lehona raus wo genau das in Gothic geschieht. Dann brauch ich das später nicht auch noch einmal suchen. Mir ginge es ja dann nur darum, das auszuschalten.
Kardulor
08.09.2016, 22:52
Mal so eine kleine Anregung bzgl. der Streuung:
Wäre es möglich, abhängig von dem charaktereigenen Talent für's Bogenschießen den Streuungsbereich vllt. durch eine gepunktete Kreislinie darzustellen?
Hier ein Beispiel:http://up.picr.de/26763823jm.jpg
Damit einhergehend würde nämlich gerade eben die Charakterfertigkeit im Bogenschießen weiterhin einen Sinn ergeben: wer nicht viel Erfahrung im Bogenschießen hat, der trifft bei größeren Distanzen sehr oft daneben und wer sehr gut darin ist, der trifft den Apfel eben auch noch auf hundert Meter Entfernung.
Ach ja und auch von mir übrigens noch einmal zwei fette Daumen hoch für diese Programmierleistung! So etwas hat sich bestimmt ein großer Teil der Community herbeigesehnt. :D
P.S. Funktioniert das ganze eig. auch für die Armbrust? :eek:
mud-freak
09.09.2016, 06:41
P.S. Funktioniert das ganze eig. auch für die Armbrust? :eek:
Ja, alles was bisher mit dem Bogen geht, funktioniert auch mit der Armbrust. Das wird intern gleich behandelt und ich muss da nicht noch etwas anpassen. Was noch nicht ganz funktioniert, aber ich noch einbauen werde (damit fing das ganze hier an siehe Einleitungspost), ist das freie Zielen für Magie. Darum kümmere ich mich anschliessend. Das wird aber (nach aussen hin) dann genau so ablaufen.
Mal so eine kleine Anregung bzgl. der Streuung:
Wäre es möglich, abhängig von dem charaktereigenen Talent für's Bogenschießen den Streuungsbereich vllt. durch eine gepunktete Kreislinie darzustellen?
Danke, genau wegen solcher Vorschläge führe ich diesen Thread so weiter. Ich habe selbst so meine eigenen Vorstellungen und da ist Input von anderen Köpfen immer eine gute Sache.
Mit dieser Idee sehe ich aber leider eine Komplikation: Da die grösse des Fadenkreuzes an der Distanz, wo man hinzielt, skaliert wird (grösser je näher ein Objekt ist, kleiner wenn das nächste Hinderniss weiter weg ist), müsste ein solcher Kreis auch skaliert werden, denn sonst ist die Information, die ein Spieler durch den Streukreis erhält falsch. Zwei Probleme kommen damit auf:
Wenn man weit weg zielt (z.B. in den Himmel) würde so ein Kreis zwangsweise unglaublich gross sein - bis zu der Hälfte des Bildschirms oder grösser. Wenn man das nach oben hin kappt, streut der Schuss weiter als durch den Kreis angegeben: inkonsistent.
Mal angenommen ich täte es trotzdem, müsste ich für jeden Durchmesser eine eigene Texture erstellen. Für das Fadenkreuz gibt es für alle Grössen bisher nur eine Textur (mittlerweile eine andere als auf dem Screenshot den du gepostet hast, siehe hier (https://youtu.be/eFDMM3R3Yvw)), da man es gut skalieren kann. So ein Kreis würde aber schnell extrem verzerrt und die dicke der Ränder des Kreises skaliert ja mit.
Damit einhergehend würde nämlich gerade eben die Charakterfertigkeit im Bogenschießen weiterhin einen Sinn ergeben: wer nicht viel Erfahrung im Bogenschießen hat, der trifft bei größeren Distanzen sehr oft daneben und wer sehr gut darin ist, der trifft den Apfel eben auch noch auf hundert Meter Entfernung.
Das ist ja auch ohne den Kreis der Fall. Der Kreis wäre rein ästhesteish.
Ach ja und auch von mir übrigens noch einmal zwei fette Daumen hoch für diese Programmierleistung! So etwas hat sich bestimmt ein großer Teil der Community herbeigesehnt. :D
Danke, ich hoffe am Ende ein hochflexibles Skript zu bieten, in dem man möglichst einfach alles anpassen kann was man will. Am liebsten würde ich auch deinen Vorschlag aufnehmen und einfach (von Skriptseite) ein- und ausstellbar machen. Das geht aber wegen oben genannter Gründe leider nicht.
Falls ich deine Idee aber falsch verstanden habe, oder du eine Lösung zu den aufgeführten Problemen weisst lass es mich wissen - ich möchte wie gesagt auf möglichst viele Ideeen eingehen und sie einbauen.
Kardulor
09.09.2016, 13:06
Gut, das Problem mit der Skalierung des Kreises kann ich nachvollziehen, aber könnte man nicht theoretisch die Kreisgröße anhand der maximalen Schussweite eichen? Demnach ist der Streuungskreis nicht an die Nähe des Zielobjektes angepasst, sondern immer vom jeweiligen Bogen- oder Armbrustschießtalent her gleich. Insofern könnte das ganz gut sein, da man auf dieser Art und Weise vllt. auch ein bisschen Gefühl für das Abschätzen von Distanzen und das eigene Schießtalent entwickeln muss. ;)
P.S. Theoretisch könnte die Schussreichweite auch etwas sein, was von Bogen zu Bogen unterschiedlich ist. Ein höherstufiger Langbogen mit mehr Zugkraft macht demnach nicht nur mehr Schaden, sondern kann auch weiter schießen. So etwas würde man aber vermutlich individuell als Modder einstellen müssen, oder? Es sei denn, du würdest so etwas für die Vanilla-Version vornehmen - aber das wird vermutlich auch noch ein bisschen Gefummel sein. :rolleyes:
mud-freak
17.09.2016, 16:26
Gut, das Problem mit der Skalierung des Kreises kann ich nachvollziehen, aber könnte man nicht theoretisch die Kreisgröße anhand der maximalen Schussweite eichen? Demnach ist der Streuungskreis nicht an die Nähe des Zielobjektes angepasst, sondern immer vom jeweiligen Bogen- oder Armbrustschießtalent her gleich. Insofern könnte das ganz gut sein, da man auf dieser Art und Weise vllt. auch ein bisschen Gefühl für das Abschätzen von Distanzen und das eigene Schießtalent entwickeln muss. ;)
Das würde mir persönlich den Reiz des Bogen-/Armbrustschiessen nehmen. Bei einem Maschinengewehr habe ich da nichts gegen, bei einem Bogen stört mich das aber. Man muss ja selbst etwas abschätzen, wo man hinschiesst. Die Streuung (= Accuracy) kann man dann anhand der Flugbahn erkennen und gewöhnt sich daran, je öfter man schiesst. Mit so einem Streukreis ist mir auch etwas zu viel auf dem Bildschirm. Was ich damit sagen will: ich werde es erstmal noch nicht einbauen, aber wie du schon richtig sagst, kann das dann jeder Modder nachholen und Problemlos bei sich einbauen. Das habe ich immer im Hinterkopf und versuche das Skript so offen und flexibel und gut kommentiert zu schreiben wie es geht. Edit: Siehe unten.
P.S. Theoretisch könnte die Schussreichweite auch etwas sein, was von Bogen zu Bogen unterschiedlich ist. Ein höherstufiger Langbogen mit mehr Zugkraft macht demnach nicht nur mehr Schaden, sondern kann auch weiter schießen. So etwas würde man aber vermutlich individuell als Modder einstellen müssen, oder? Es sei denn, du würdest so etwas für die Vanilla-Version vornehmen - aber das wird vermutlich auch noch ein bisschen Gefummel sein. :rolleyes:
Das allerdings finde ich eine sehr gut Idee von dir. Damit hast du mich auf die Idee gebracht, die Berechnung der Accuracy (also Streuung) und die Berechnung der Zugkraft (und einige weitere Sachen) in separate bündige Funktionen auszulagern, die jeder für sich anpassen kann (ohne sich mit dem Rest des Skriptes auseinandersetzen zu müssen). Hier mal ein kleiner Einblick. Die beiden Funktionen müssen einen Prozentwert zwischen 0 und 100 zurückgeben - wie man diesen errechnet ist völlig offen. Es ist schon etwas Vorarbeit geleistet; z.B. steht die Schusswaffe in der Variable weapon bereit. So könnte man dort einen Bogenwert mit in die Berechnung der Streuung einbeziehen. Wenn ein Modder ein Schnellzielen-Talent einbauen will, kann er das in freeAimGetDrawForce hinzufügen und die Prozentzahl anpassen.
In diesem Fall (s.u.) wird die Zugkraft nur an einem Zeitwert festgemacht (dazu steht bowDrawOnset bereit). Die Accuracy ist einfach das Bogen-/Armbrusttalent skaliert mit der Zugkraft.
/* Modify this function to alter the draw force calculation. Scaled between 0 and 100 (percent) */
func int freeAimGetDrawForce(var C_Item weapon, var int talent) {
var int drawTime; drawTime = MEM_Timer.totalTime - freeAimBowDrawOnset;
// Possibly incorporate more factors like e.g. a quick-draw talent, weapon-specific stats, ...
// Check if bow or crossbow with (weapon.flags & ITEM_BOW) or (weapon.flags & ITEM_CROSSBOW)
// For now set drawForce by draw time scaled between min and max times:
var int drawForce; drawForce = (100 * (drawTime-FREEAIM_DRAWTIME_MIN))/(FREEAIM_DRAWTIME_MAX-FREEAIM_DRAWTIME_MIN);
if (drawForce > 100) { drawForce = 100; } else if (drawForce < 0) { drawForce = 0; }; // Respect the ranges
return drawForce;
};
/* Modify this function to alter accuracy calculation. Scaled between 0 and 100 (percent) */
func int freeAimGetAccuracy(var C_Item weapon, var int talent) {
// Add any other factors here e.g. weapon-specific accuracy stats, weapon spread, accuracy talent, ...
// Check if bow or crossbow with (weapon.flags & ITEM_BOW) or (weapon.flags & ITEM_CROSSBOW)
// Here the talent is scaled by draw force: draw force=100% => accuracy=talent; draw force=0% => accuracy=talent/2
var int drawForce; drawForce = freeAimGetDrawForce(weapon, talent); // Already scaled to [0, 100]
if (drawForce < talent) { drawForce = talent; }; // Decrease impact of draw force on talent
var int accuracy; accuracy = (talent * drawForce)/100;
if (accuracy > 100) { accuracy = 100; } else if (accuracy < 0) { accuracy = 0; }; // Respect the ranges
return accuracy;
};
Wer in letzter Zeit mal in den Einleitungspost geschaut hat, wird bemerkt haben, dass sich in der Liste einiges getan hat. Mittlerweile fehlt nur noch das seitliche Laufen beim Zielen (neben einigen kleineren Sachen). Im Moment bin ich sehr mit meinem Code zufrieden und könnte, falls das seitliche Laufen nicht gut funktionieren wird oder ich irgendwann keine Lust mehr habe, ohne grosse Umstände das Skript so wie es ist veröffentlichen.
Hier, was sich getan hat:
Die Streuung funktioniert wunderbar (sieht hier nicht so gut aus, aber die ist Kreisrund). Hier aus ca. 12 Meter Entfernung mit Trefferwahrscheinlichkeit 50, ohne Zugkraft:
44809
Genau so der Headshot. Dort sind auch zwei Funktionen ausgelagert. In einer kann man den Schaden (z.B. einem bestimmten Monster) anpassen. In der anderen kann man einen Headshot-Event festlegen, wie z.B. einen Sound oder einen Print auf dem Bildschirm. Man könnte also auch mitzählen und nach 25 Headshots extra Erfahrung vergeben o.ä. Beachten muss man, dass der Schaden dem Basisschaden entspricht, also dem Waffenschaden. Stärke usw. wird von der Engine anschliessend dazuaddiert. So sieht das aus:
/* Modify this function to set the headshot damage. Caution: damage is a float and should be returned as such */
func int freeAimGetHeadshotDamage(var int damage, var C_NPC target, var C_Item weapon) {
// Possibly incorporate weapon-specific stats, headshot talent, dependecy on target, ...
// The damage may depent on the target npc (e.g. different damage for monsters). Make use of 'target' argument
// if (target.guild < GIL_SEPERATOR_HUM) { }; // E.g. special case for humans
// The weapon can also be considered (e.g. weapon specific damage). Make use of 'weapon' for that
// Caution: Weapon may have been unequipped already at this time! Use Hlp_IsValidItem(weapon)
// if (Hlp_IsValidItem(weapon)) && (weapon.certainProperty > 10) { }; // E.g. special case for weapon property
damage = mulf(damage, castToIntf(2.0)); // For now, just double the base damage
return damage; // This sets a new base damage (excl. strength, ...). This is not the final damage!
};
/* Use this function to create an event when getting a headshot, e.g. a print or a sound jingle, leave blank for none */
func void freeAimHeadshotEvent(var C_NPC target, var C_Item weapon) {
// The event may depent on the target npc (e.g. different sound for monsters). Make use of 'target' argument
// if (target.guild < GIL_SEPERATOR_HUM) { }; // E.g. special case for humans
// The headshots could also be counted here to give an xp reward after 25 headshots
// The weapon can also be considered (e.g. weapon specific print). Make use of 'weapon' for that
// Caution: Weapon may have been unequipped already at this time! Use Hlp_IsValidItem(weapon)
// if (Hlp_IsValidItem(weapon)) && (weapon.certainProperty > 10) { }; // E.g. special case for weapon property
Snd_Play("FORGE_ANVIL_A1");
PrintS("Kritischer Treffer"); // "Critical hit"
};
Die Headshot-Detection ist sehr präzise. Die Enginefunktionen mit möglichen Schnittpunkt usw. waren mir dafür zu ungenau und ich hab das selbst in die Hand genommen.
Bei Menschen klappt es sehr genau (erstes Bild mit einem möglichen Print), die Linien sind natürlich nur zu Debugzwecken:
44806
44804
44805
Bei Tieren ist das grosse Problem, dass sie kein separates Head-Visual haben (Menschen haben ja alle individuelle Köpfe). D.h. die Kopf-Boundingbox von Tieren hat die Grösse Null. Dafür sehe ich keine Lösung, daher wird jetzt einfach bei Tieren eine Kopfgrösse "geraten" (= 60x60cm). Das haut bei den meisten Tieren hin - Ausnahmen sind Monster wie Trolle (siehe zweites Bild) - dort ist dann halt ein Headshot einfach schwieriger. (Ausserdem steht man im Kampf gegen einen Troll meist eh in dessen Boundingbox, sodass man trifft bevor der Pfeil richtig losfliegt - in dem Fall wird man NIE einen Headshot erzielen können). Das sind aber Sachen, die werden einen "Endbenutzer" nicht stören, so lange man es ihm nicht unter die Nase reibt - er bekommt schliesslich nichts davon mit und wird davon aussgehen, dass der Pfeil knapp vorbei gegangen ist oder ein Headshot intern einfach anderes errechnet wird.
44807
44808
EDIT: Für Leute, denen diese Headshot-Angelegenheit bei Monstern zu ungenau ist, habe ich noch eine weitere Funktion eingebaut, in der man die Kopfgrössen der einzelnen Monster definieren kann. Die ist vor allem dann interessant, wenn jemand in seiner Mod neue Monster hat.
Damit steht natürlich noch die Frage im Raum, ob jemand trotzdem eine Möglichkeit sieht, an die Boundingbox vom Head node von Monstern zu kommen. Über Ideen würde ich mich freuen!
/* Modify this function to assign more appropriate head sizes for headshot detection: Only called for non-human npcs */
func int freeAimGetHeadSize(var C_NPC monster) {
// if (monster.aivar[AIV_MM_REAL_ID] == ID_TROLL) { // Head size for trolls
// return 120; // 120x120cm
// } else if (monster.aivar[AIV_MM_REAL_ID] == ...
// ...
// } else {
// return 60; // Default head size is 60x60cm
// };
return 60; // Default is 60x60cm
};
@Kardulor: Hier ist noch eine weitere Funktion, mit der man dann genau das erreich kann, was du dir vorstellst - oder zumindest ähnlich. In der Funktion kann das Fadenkreuz manipuliert werden (sowohl Grösse als auch Textur). Standardmässig skaliert das Fadenkreuz einfach mit Zielentfernung. In dem auskommentierten Abschnitt sind aber noch zwei Beipsiele, wie man die Grösse stattdessen (1) mit der Zugkraft oder (2) mit der Accuracy (das ist doch was du dir vorstellst, oder?) skaliert (je länger man zielt/mehr Accuracy desto kleiner wird das Fadenkreuz).
/* Modify this function to alter the reticle style. By draw force, weapon-specific stats, talent, ... */
func int freeAimGetReticleStyle(var C_Item weapon, var int talent) {
if (weapon.flags & ITEM_BOW) { return POINTY_RETICLE; }; // Bow readied
if (weapon.flags & ITEM_CROSSBOW) { return POINTY_RETICLE; }; // Crossbow readied
return NORMAL_RETICLE;
};
/* Modify this function to alter the reticle size. By draw force, weapon-specific stats, talent, ... */
func int freeAimGetReticleSize(var int size, var int weapon, var int talent) {
// The argument 'size' comes precalculated by aiming distance
// var int scale; scale = -freeAimGetDrawForce(weapon, talent)+100; // E.g. scale with draw force instead
// var int scale; scale = -freeAimGetAccuracy(weapon, talent)+100; // or scale with accuracy
// size = (((FREEAIM_RETICLE_MAX_SIZE-FREEAIM_RETICLE_MIN_SIZE)*(scale))/100)+FREEAIM_RETICLE_MIN_SIZE;
return size; // For now leave it scaled by distance
};
Kardulor
18.09.2016, 12:11
Sind ja ein paar schicke Sachen, die da wieder dazugekommen sind. :)
Vergiss aber erst einmal den visualisierten Streuungskreis, dass wird auch so schon gut sein, wie du das machst.
Was die Treffergenauigkeit anbelangt gibt es allerdings grundlegend etliche Aspekte, die man in das Schussergebnis mit ein beziehen könnte. Da wäre wie bereits erwähnt die Art des Bogens bzw. wie viel maximale Zugkraft dieser bietet. Dann natürlich die individuell für den Schuss aufgewendete Zugkraft selbst (also wie lange er den Bogen spannt), allerdings könnte dieser Punkt auch gegenteilig genutzt werden: wer nämlich zu lange den Bogen spannt, dem werden mit der Zeit die Arme schwach und wackelig, sodass sich die Streuung wieder erhöht. Ist jetzt zwar nicht unbedingt für den Singleplayer notwendig, aber speziell wenn ich an die Implementierung im Multiplayer denke, könnten solche kleinen Balancing-Elemente unter Umständen sehr wichtig sein/werden. ;)
So oder so sind das aber bloß Feinheiten, denen man sich final dank deiner offenen Scriptführung mehr oder minder selbst annehmen könnte, wenn man wollte. Dafür auf jeden Fall mal einen großherzigen Dank! :gratz
mud-freak
18.09.2016, 16:05
Ja, ich denke solche Ideen sollten sich nun im Nachhinein recht einfach einbauen lassen.
Dann natürlich die individuell für den Schuss aufgewendete Zugkraft selbst (also wie lange er den Bogen spannt), allerdings könnte dieser Punkt auch gegenteilig genutzt werden: wer nämlich zu lange den Bogen spannt, dem werden mit der Zeit die Arme schwach und wackelig, sodass sich die Streuung wieder erhöht.
Steady Aim 70% Bogen zu lang gespannt = Kamera wackelt, schwieriger zu Zielen Unnötig. Oder ist wer daran interessiert? Dann bitte melden.
Daran hatte ich auch schon gedacht. Wäre dir so etwas wichtig? Ich hatte nämlich mit so etwas schon einmal angefangen. D.h. die Kamera fängt nach zu langem Zielen an zu wackeln - ähnlich wie bei einem Erdbeben-Effekt aber etwas seichter und ich vernünftigen Ausmass/Richtungen. Allerdings war mir das irgendwie zu unwichtig.
Noch etwas anderes: Bezüglich des seitlichen Gehens (also Strafen) während dem Zielen habe ich die Arbeiten eingestellt. Mehrere Animationen gleichzeitig (zielen, gehen) abzuspielen war nicht einfach möglich - und als es klappte, blieben die Animationen manchmal hängen und schiessen und nachladen waren während dem Strafen nicht möglich.
Heute habe ich dann noch einmal einen komplett anderen Ansatz ausprobiert (nicht umfallen: Spieler-Vob manuell verschieben und eine "nicht-bewegende" Gehanimation drüber legen). Der hat überraschender Weise sehr gut geklappt. Man konnte schiessen, zielen, usw. problemlos während dem Gehen und Animationen und Bewegungen hingen auch nicht anschliessend fest. Kollision hatte man auch, sodass man nicht durch Wände verschoben wurde o.ä.
Das "einzige" Problem waren unvorhersehbare Nebeneffekte, wie man sich bei so einer unkonventionellen Methode vorstellen kann. So steckte man manchmal an einer Wand fest. Mir war dieser Ansatz aber eh zu dirty. Ich habe meine Versuche mit dem Strafen aber nicht gelöscht, sondern in einen eigenen Branch gelegt, so dass jeder der will später daran weiterarbeiten kann. Ich habe vor das Repo dann hier zu teilen.
Seitliches Gehen beim Zielen 40% Klappt fast, aber ist mir zu instabil. Habe aber einen Branch dafür angelegt.
Kardulor
18.09.2016, 16:40
Daran hatte ich auch schon gedacht. Wäre dir so etwas wichtig? Ich hatte nämlich mit so etwas schon einmal angefangen. D.h. die Kamera fängt nach zu langem Zielen an zu wackeln - ähnlich wie bei einem Erdbeben-Effekt aber etwas seichter und ich vernünftigen Ausmass/Richtungen. Allerdings war mir das irgendwie zu unwichtig.
Huch, hatte ich ganz am Anfang wohl ganz überlesen oder einfach vergessen. :eek:
In Bezug auf den Singleplayer: kann man machen, muss man aber nicht. Wenn man's hat, ist es bestimmt ganz nett, aber wirklich unbedingt brauchen tut man's eig. nicht. Das sähe dann aber im Falle eines Multiplayers (was dann vllt. eher für die Jungs vom G:UC interessant sein könnte, wenn die das dort bei sich einbauen) deutlich anders aus, da ein solches Zittern ein wichtiges Balancing-Element im Spielerkampf darstellen könnte.
Letztendlich kannst du es aber denke ich reinmachen, wenn du die Lust und Zeit hast. Kannst ja vllt. ne An- und Ausschaltmöglichkeit für dieses Feature bieten und dann hat sich das. ;)
königsgardist
18.09.2016, 16:51
Hab mal prinzipiell eine Frage zur Strafe- Animation:
geht es nicht, dass man so eine einfach von einer Website hinunterlädt, in das Gothic-Format konvertiert und dann einfach einbaut? Bin Laie...
mfg königsgardist
mud-freak
18.09.2016, 17:47
geht es nicht, dass man so eine einfach von einer Website hinunterlädt, in das Gothic-Format konvertiert und dann einfach einbaut? Bin Laie...
Die Animation dabei ist nicht das Problem. Also es ging nicht darum, dass ich keine Animation habe. Wo es knifflig wird ist was du "einfach einbauen" nennst. Leider geht das nicht so einfach. Normalerweise hast du recht - man sagt Gothic: Spiel diese Animation ab und es klappt.
Hier soll die Animation aber abgespielt werden während die Zielen-Animation (d.h. der Bogen folgt dem Fadenkreuz) weiterläuft. Die Zielen-Animation ist aber keine festgelegte Animation, sondern sie ändert ständig wenn man wo anders hinzielt. Deshalb haben sich die beiden Animationen gegenseitig blockiert.
Ich denke, dass es eventuell möglich ist beide laufen und ständig aktualisieren zu können, doch habe ich damit bisher zu viel Zeit verbracht und selbst wenn es klappt, stünde noch das Problem im Raum, dass man dann auch noch währenddessen schiessen und nachladen können muss. Irgendwann wird so etwas zu einer Aufgabe, wie ein Raumschiff aus Holz zu bauen - die Werkzeuge sind begrenzt. Gothic ist einfach nicht für so etwas gemacht.
königsgardist
18.09.2016, 19:02
Die Animation dabei ist nicht das Problem. Also es ging nicht darum, dass ich keine Animation habe. Wo es knifflig wird ist was du "einfach einbauen" nennst. Leider geht das nicht so einfach. Normalerweise hast du recht - man sagt Gothic: Spiel diese Animation ab und es klappt.
Hier soll die Animation aber abgespielt werden während die Zielen-Animation (d.h. der Bogen folgt dem Fadenkreuz) weiterläuft. Die Zielen-Animation ist aber keine festgelegte Animation, sondern sie ändert ständig wenn man wo anders hinzielt. Deshalb haben sich die beiden Animationen gegenseitig blockiert.
Ich denke, dass es eventuell möglich ist beide laufen und ständig aktualisieren zu können, doch habe ich damit bisher zu viel Zeit verbracht und selbst wenn es klappt, stünde noch das Problem im Raum, dass man dann auch noch währenddessen schiessen und nachladen können muss. Irgendwann wird so etwas zu einer Aufgabe, wie ein Raumschiff aus Holz zu bauen - die Werkzeuge sind begrenzt. Gothic ist einfach nicht für so etwas gemacht.
Alles klar! Vielen Dank für den Einblick. Schade, aber das Spiel hat ja auch ein paar Jährchen auf dem Buckel. Bin trotzdem gespannt, was du noch zusammenbringen wirst :) . Beta-Testen werde ich gerne, wenn es soweit ist.
lg königsgardist
Uuuuuh, das wird ja immer besser hier! §omg
Da kommt mir eine Idee, die sehr atmosphärisch für bestimmte Mods und Monster wäre. Man könnte über Quests oder einfach im Gespräch mit NPCs von bestimmten "Schwachstellen" von speziellen Monstern erfahren. Die müssen ja jetzt nicht zwangsweise am Kopf sein. Ein Mensch hat klar am Kopf den headshot-Bonusschaden aber zum Beispiel ein Dämon könnte sie am Herz haben oder ein alter Draceh, von dem man erfahren hat, dass ihm eine Schuppe unter dem linken Flügel fehlt eben dort (OK ich weiß billiger fake, aber nur zur Veranschaulichung der Idee) etc..
Die Frage ist, ob es Möglich ist, um bestimmte Bones diese Boundingbox zu definieren. Ich kenn mich zwar mit Bones aus, aber kaum mit Scripts. §ugly
mud-freak
18.09.2016, 20:06
Uuuuuh, das wird ja immer besser hier! §omg
Da kommt mir eine Idee, die sehr atmosphärisch für bestimmte Mods und Monster wäre. Man könnte über Quests oder einfach im Gespräch mit NPCs von bestimmten "Schwachstellen" von speziellen Monstern erfahren. Die müssen ja jetzt nicht zwangsweise am Kopf sein. Ein Mensch hat klar am Kopf den headshot-Bonusschaden aber zum Beispiel ein Dämon könnte sie am Herz haben oder ein alter Draceh, von dem man erfahren hat, dass ihm eine Schuppe unter dem linken Flügel fehlt eben dort (OK ich weiß billiger fake, aber nur zur Veranschaulichung der Idee) etc..
Die Frage ist, ob es Möglich ist, um bestimmte Bones diese Boundingbox zu definieren. Ich kenn mich zwar mit Bones aus, aber kaum mit Scripts. §ugly
Interessanter Gedanke. Bisher wird einfach der Bip01 Head geholt. Das könnte ich aber auch so auslagern, dass man mittels Guilde o.ä. den "Schwachstellen-Bone" individuell bestimmt.
Kann ich mal ausprobieren. Vielleicht sollte ich dann diese Debuganzeigen, die man in den Screenshots sieht (Boundingboxes und Flugbahn) wieder einbauen und über Skripte ein- und ausstellbar machen, damit Modder dann solche Schwachstellen für Monster klarer festlegen und überprüfen können.
Also generell sehe ich für deine Idee grünes Licht.
königsgardist
05.10.2016, 16:58
Hallo,
ich wollte einmal nachfragen, wie es geht! :)
lg königsgardist
mud-freak
09.10.2016, 10:13
Hallo,
ich wollte einmal nachfragen, wie es geht! :)
lg königsgardist
Hi, ich habe die letzten zwei Wochen etwas Abstand genommen und habe im Moment auch nicht viel Zeit. An den ein oder anderen Wochenenden werde ich immer wieder ein bisschen weiterarbeiten. Wie schnell ich also vorankomme, kann ich leider nicht abschätzen.
Ein Überblick:
Im Moment habe ich zehn offene "Aufgaben" (Implementierung für Zauber nicht einbegriffen) wovon sechs sehr wichtig für die Funktionalität sind, der Rest optional.
Was die einfachen Anpassungsmöglichkeiten für Modder angeht, sind bisher folgende Funktionen implementiert (darunter auch spezifische Schwachstellen per Gegner, wie vorgeschlagen von Simon):
/* Modify this function to alter the draw force calculation. Scaled between 0 and 100 (percent) */
func int freeAimGetDrawForce(var C_Item weapon, var int talent)
/* Modify this function to alter accuracy calculation. Scaled between 0 and 100 (percent) */
func int freeAimGetAccuracy(var C_Item weapon, var int talent)
/* Modify this function to alter the reticle texture, color and size (scaled between 0 and 100). */
func void freeAimGetReticle(var C_Npc target, var int weapon, var int talent, var int distance, var int returnPtr)
/* Modify this function to disable hit registration. E.g. 'ineffective' ranged weapons, disable friendly-fire, ... */
func int freeAimHitRegistration(var C_Npc target, var C_Item weapon, var int material)
/* Modify this function to define a critical hit by weak spot (e.g. head node for headshot), its size and the damage */
func void freeAimCriticalHitDef(var C_Npc target, var C_Item weapon, var int damage, var int returnPtr)
/* Use this function to create an event when getting a critical hit, e.g. print or sound jingle, leave blank for none */
func void freeAimCriticalHitEvent(var C_Npc target, var C_Item weapon)
/* Modify this function to alter (or remove) the projectile instance after shooting for re-using, e.g. used arrow */
func int freeAimGetUsedProjectileInstance(var int projectileInst, var C_Npc inventoryNpc)
EDIT: Der oben stehende Code ist veraltet aber zeigt beispielhaft noch wie es geht.
Kardulor
10.10.2016, 20:28
In Bezug auf den Unterpunkt "Steady Aim": Wäre es nicht möglich, die Verwackelung ebenfalls mit dem Bogenschießtalent zu kombinieren? Man könnte die Stärke des Verwackelns und die Zeit, wann die Verwackelung eintritt, vom dazugehörigen Waffentalent abhängig machen. Wer ungeübt ist, wackelt sehr viel schneller und sehr viel stärker als ein ausgebildeter Schütze. :)
Wie die große Mehrheit das fände kann ich nicht sagen, aber ich persönlich fände so etwas super toll! Das brächte in meinen Augen einen gesunden Realismus in die Geschichte und ein faires Balancing, auf dass man es als anfänglicher Bogenschützen-Neuling nicht so einfach mit dem überaus starken Fernkampf hat. :gratz
@mud-freak: Aaahh sehr schön, das entwickelt sich ja zu einem allround feature, welches selbst ein Hans-Bauer wie ich bedienen kann!
Wunderbar.
mud-freak
26.10.2016, 10:27
Ich habe gute Neuigkeiten. Ich habe mir ein vorläufiges Releasedatum gesetzt. Das basiere ich auf einem Zeitplan. Beides lässt sich im Einleitungspost finden zusammen mit einer aktualisierten Aufgabenliste und der Anzahl der offenen und geschlossenen Issues/Tickets, die ich fortlaufend Aktuell halten will.
Das mag alles etwas albern wirken, aber ich poste es hier für mich selbst, um mir ein bisschen Druck zu machen; ich will es endlich fertig haben. Sicher kann es sein, dass ich das Release nach hinten verschiebe (und still und leise im Einleitungspost anpasse), sollte es knapp werden. Aber ich denke es sollte machbar sein, es einzuhalten.
Mittlerweile habe ich die Arbeiten am Fernkampf abgeschlossen und am freien Zielen für Magie begonnen (siehe Fortschritt). Freies Zielen für Magie wird wesentlich eingeschränkter was Anpassungsmöglichkeiten angeht. Z.B. wird es keine Accuracy bei Zaubern geben, da die Kollision von Effekten zu grob ist. Die einzige Anpassungsmöglichkeit für Zauber wird die dynamische Gestaltung des Fadenkreuzes sein. Ob ein bestimmter Zauber freies Zielen unterstützt wird mit der Spell Instanz entschieden (targetCollectAlgo, targetCollectType und canTurnDuringInvest).
Es werden keine neuen Features mehr dazu kommen.
In Bezug auf den Unterpunkt "Steady Aim" [...]
Ich hatte beschlossen Steady Aim nicht mit aufzunehmen. Es bleiben noch einige Überreste dazu im Repository, d.h. du kannst später selbst (oder mit Hilfe von anderen) versuchen eine Lösung dazu zu finden. Der Grund warum ich es gestrichen hatte ist, dass Gothics "Camera Tremor" nicht leicht zu bändigen ist und es im Menü usw. weiter läuft. Sicher etwas was man beheben kann, wenn man sich die Enginefunktionen genauer anschaut (was ich nicht getan habe). Mir war es aber zu "hacky".
@mud-freak: Aaahh sehr schön, das entwickelt sich ja zu einem allround feature, welches selbst ein Hans-Bauer wie ich bedienen kann!
Wunderbar.
Genau darauf ziele ich ab. Viele Zeilen vom Kernskript sind denke ich nicht leicht nachvollziehbar (trotz Kommentaren) und einiges wird Gothic extrem instabil machen wenn man auch nur das kleinste Bisschen ändert (ohne, dass man es vielleicht direkt merkt). Es ist viel Arbeit hinein gegangen das freie Zielen stabil zu machen und ich kann nicht an jede Zeile Code schreiben, warum ich sie so gewählt habe auch wenn sie evtl. umständlich aussieht. Wenn jemand anfängt darin rumzufuschen ist er selbst Schuld. Deshalb habe ich im Vornherein versucht, alle Sachen, die man möglicherweise Anpassen wollte als Konfigurationen ausgelagert, damit man das Kernskript nicht berühren muss (darf!).
königsgardist
26.10.2016, 11:23
D.h., wir dürfen uns baldigst auf ein Freies-Zielen-Video mit Magier freuen? Das ist ja super!
Danke vielmals für deine Bemühungen!
mfg königsgardist
mud-freak
26.10.2016, 20:41
D.h., wir dürfen uns baldigst auf ein Freies-Zielen-Video mit Magier freuen?
Das eher nicht, da ich meine beschränkte Zeit lieber dafür nutze das alles möglichst schnell fertig zu bekommen. Aber so viel sei gesagt: Ich habe es gerade erstaunlich schnell eingebunden (ich dachte es würde einige Tage bis Wochen dauern); Freies Zielen für Magie funktioniert. Ich werde das jetzt noch stabilisieren und testen.
Ich freue mich schon sehr auf dieses Skriptpaket! In Orkkrieg 2 habe ich bereits dein Zauberpaket eingebunden und die neuen Zauber mit der Story/Quest verbunden. Bin schon sehr gespannt was es dieses mal schönes von dir zu sehen gibt. §wink
mud-freak
01.11.2016, 19:50
Ich freue mich schon sehr auf dieses Skriptpaket! In Orkkrieg 2 habe ich bereits dein Zauberpaket eingebunden und die neuen Zauber mit der Story/Quest verbunden. Bin schon sehr gespannt was es dieses mal schönes von dir zu sehen gibt. §wink
Danke! Sowas zu hören treibt mich immer an. Da werd ich gerade mal einen Happen hergeben: Vorschau zu animierten Fadenkreuzen.
http://upload.worldofplayers.de/files10/ezgif.com_crop.gif
(Sobald man die Aktionstaste drückt erscheint das Fadenkreuz - bis man die Taste wieder loslässt. In der Vorschau hier skaliert die Grösse mit der Zielentfernung)
You getting keys binds from gothic.ini? Or did you assign in advance? (MEM_KEYSTATE(KEY_LCTRL)==state)
2. (Free-Aim) some time ago i asked you "Can you change arrow trajectory?"
You did it?
I asked a creator AST. This is answer: "Physical Vectors, and Engine Function 'Shoot in wall'".
I don't know how i can use this infos, so i give you this infos ;)
mud-freak
02.11.2016, 10:02
You getting keys binds from gothic.ini? Or did you assign in advance? (MEM_KEYSTATE(KEY_LCTRL)==state)
Everything the user cannot change after the game starts, I read from the ini once at startup. As keystrokes may be changed in the settings menu while the game is running, Ikarus offers a function to retrieve the current Key ID from the ini (I assume it doesn't read it from the drive every time but has it loaded in memory). To match your example, this would look like this:
MEM_KEYSTATE(MEM_GetKey("keyAction"))==state // Primary key binding
MEM_KEYSTATE(MEM_GetSecondaryKey("keyAction"))==state // Secondary key binding
Nevertheless, it is completely possible to not rely on key presses at all, but instead hook the right engine functions.
2. (Free-Aim) some time ago i asked you "Can you change arrow trajectory?"
You did it?
I asked a creator AST. This is answer: "Physical Vectors, and Engine Function 'Shoot in wall'".
I don't know how i can use this infos, so i give you this infos ;)
Yes, my script alters the trajectory of projectiles. I don't understand the answer you got. Sounds a lot more complicated than it has to be. I did it by just dynamically changing the gravity of the projectile. The advantage: it is easy to do; the disadvantage: you have no chance of knowing where the projectile will land before-hand. Additionally to changing the gravity, I also manipulate the flight path by accuracy. Thank you for the info, though. Much appreciated.
mud-freak
27.11.2016, 23:08
Das Skriptpaket "G2 Free Aim" ist nun verfügbar. Dazu möchte ich auf den aktualisierten Einleitungspost verweisen.
Ich habe eine Modifikation veröffentlicht, die das freie Zielen beispielhaft implementiert. Diese kann als eine Art Demo (aber auch als eigenständige Erweiterung) angesehen werden. Downloadlink dazu auch im Einleitungspost.
Auch den Zauber Blink (https://youtu.be/__By3sgFogY) habe ich endlich veröffentlicht. Diesen kann man in der Modderdatenbank herunterladen (Link im Einleitungspost).
Viel Spass damit!
http://www.youtube.com/watch?v=9CrFlxo21Qw
Gratulation zum Release. :gratz
Ist die Animation der Entfernung auch auf Bögen anwendbar? Das habe ich im Video nicht ganz erkennen können.
mud-freak
27.11.2016, 23:35
Gratulation zum Release. :gratz
Ist die Animation der Entfernung auch auf Bögen anwendbar? Das habe ich im Video nicht ganz erkennen können.
Danke. Ja, das geht sehr einfach in der Funktion freeAimGetReticleRanged(...). Dort ist in den Standarteinstellungen ein Spezialfall für Bögen eingebaut, nach dem das Fadenkreuz mit der Zugkraft animiert. Um lieber die Entfernung zu animieren, kann man sich einfach am Fall der Armbrüste orientieren.
Man kann aber auch völlig andere Kriterien wählen. Das ist dem Konfigurationsskript (freeAim\config.d) alles in den Kommentaren genauer erklärt.
Kardulor
28.11.2016, 00:26
Super Sache! Herzlichen Glückwunsch zur Veröffentlichung und einen großen Dank für diese aufwändige und doch beispiellos liebevolle Arbeit (allein die ganzen Magie-Fadenkreuze...). §knuff:gratz
Auch von mir an dieser Stelle nochmal Glückwunsch. Ich werde heute gleich versuchen das einzubinden und werde weiter rumprobieren. $§p4
mud-freak
28.11.2016, 10:52
Super Sache! Herzlichen Glückwunsch zur Veröffentlichung und einen großen Dank für diese aufwändige und doch beispiellos liebevolle Arbeit (allein die ganzen Magie-Fadenkreuze...). §knuff:gratz
Da fällt mir auf ich könnte die mitgelieferten Fadenkreuze einmal hier auflisten. Das sind natürlich nur einige Beispiele: Man kann mit Leichtigkeit eigene hinzufügen. Wie man den Fadenkreuzen die Animation beibringt und was es da für Unterschiede gibt (kontinuierliche Animation, Animation nach äusseren Kriterien), kann man alles aus der README entnehmen.
http://upload.worldofplayers.de/files10/reticleDot.png http://upload.worldofplayers.de/files10/reticleCrossTwo.png http://upload.worldofplayers.de/files10/reticleCrossThree.png http://upload.worldofplayers.de/files10/reticleCrossFour.png http://upload.worldofplayers.de/files10/reticleX.png http://upload.worldofplayers.de/files10/reticleCircle.png http://upload.worldofplayers.de/files10/reticleCircleCross.png http://upload.worldofplayers.de/files10/reticleDoubleCircle_A.gif
http://upload.worldofplayers.de/files10/reticlePeak.png http://upload.worldofplayers.de/files10/reticleNotch_A.gif http://upload.worldofplayers.de/files10/reticleTriIn_A.gif http://upload.worldofplayers.de/files10/reticleTriInDot_A.gif http://upload.worldofplayers.de/files10/reticleTriOutDot_A.gif http://upload.worldofplayers.de/files10/reticleDrop_A.gif http://upload.worldofplayers.de/files10/reticleFrame.png http://upload.worldofplayers.de/files10/reticleEdges.png
http://upload.worldofplayers.de/files10/reticleBowl.png http://upload.worldofplayers.de/files10/reticleHorns.png http://upload.worldofplayers.de/files10/reticleBolts.png http://upload.worldofplayers.de/files10/reticleBlaze_.gif http://upload.worldofplayers.de/files10/reticleWhirl_A.gif http://upload.worldofplayers.de/files10/reticleBrush.png http://upload.worldofplayers.de/files10/reticleSpades.png http://upload.worldofplayers.de/files10/reticleSquiggle.png
MyGamingHD
28.11.2016, 13:42
Von mir auch Gratulation zum Release, aus meiner Sicht ist schon ein echt großer Schritt in der Modding Geschichte was du da vollbracht hast.
Und damit meine ich nicht nur das du dieses Meister Werk geschaffen hast, sondern auch das du obwohl du eigentlich nicht in der Modder Szene verweilen wolltest dich trotzdem hingesetzt hast und vielen Moddern einen Traum erfüllt hast.
Ich werde das, die nächsten Tage mal gründlich unter die Lupe nehmen und damit etwas rum spielen.
Nochmals danke. :D
TheEternal
28.11.2016, 18:07
big thx, sieht super aus. Ich hoffe es gibt bald paar Testbericht von Leuten die das Paket implementieren und ausführlich testen.
Bei mir taucht die Fehlermeldung:
Unknown Identifier "MEM_Info" (line 139)
auf. Weißt du, was ich da falsch gemacht hab? Passiert das sonst noch wem?
mud-freak
28.11.2016, 18:31
Bei mir taucht die Fehlermeldung:
Unknown Identifier "MEM_Info" (line 139)
auf. Weißt du, was ich da falsch gemacht hab? Passiert das sonst noch wem?
Das ist verwunderlich. MEM_Info wird ja in Ikarus definiert. Was mir dazu einfällt ist:
Wird G2 Free Aim nach Ikarus geparst?
Hast du die neuste Ikarus Version?
Steht MEM_Init() in der INIT_Global vor freeAim_Init()?
Das ist verwunderlich. MEM_Info wird ja in Ikarus definiert. Was mir dazu einfällt ist:
Wird G2 Free Aim nach Ikarus geparst?
Hast du die neuste Ikarus Version?
Steht MEM_Init() in der INIT_Global vor freeAim_Init()?
Danke für die schnelle Antwort. Lag daran: " Wird G2 Free Aim nach Ikarus geparst?"
Neuer Fehler:
Unknown Identifier: CC_REGISTER (line 148)
Was hab ich jetzt falsch gemacht? :o
Meine INIT_GLOBAL
func void INIT_GLOBAL()
{
MoreAlphaVobs(8192); //normal: 256 2048 4096 8192
MoreAlphaPolys(262144); //normal: 2048 16384 32768 65536 131072 262144
// wird fuer jede Welt aufgerufen (vor INIT_<LevelName>)
Loading_Auswahl();
Game_InitGerman();
LeGo_Init(LeGo_All & ~LeGo_Bloodsplats | LeGo_FrameFunctions | LeGo_ConsoleCommands);
// LeGo_Init(LeGo_All & ~LeGo_Bloodsplats);
MEM_Init();
// Free Aim
freeAim_Init();
};
Meine Pars-Reihenfolge:
AI\AI_INTERN\AI_CONSTANTS.D
AI\AI_INTERN\BODYSTATES.D
AI\AI_INTERN\FOCUS.D
AI\AI_INTERN\Npc_SetToMad.d
AI\AI_INTERN\Species.d
AI\AI_INTERN\PrintDebug.d
AI\AI_INTERN\PrintPlus.d
STORY\Ikarus_Const_G2.d
STORY\EngineClasses_G2\*.d
STORY\Ikarus.d
STORY\Float.d
STORY\Loading.d
LeGo\Header.src
freeAim\freeAim.src
mud-freak
28.11.2016, 18:43
Unknown Identifier: CC_REGISTER (line 148)
Hast du die neue LeGo Version 2.4.0? Die wurde gerade gestern Nacht released und enthält die neuen ConsoleCommands, die hier wohl nicht gefunden werden.
Hast du die neue LeGo Version 2.4.0? Die wurde gerade gestern Nacht released und enthält die neuen ConsoleCommands, die hier wohl nicht gefunden werden.
Jetzt klappt alles, vielen Dank. Obwohl ich das SystemPack installiert habe, tauchte bei mir der fehler auf, dass das Fadenkreuz in einer anderen Ecke vom Bildschirm warm. Das hat sich aber durch ein umstellen der Auflösung beheben lassen.
mud-freak
28.11.2016, 19:09
Jetzt klappt alles, vielen Dank. Obwohl ich das SystemPack installiert habe, tauchte bei mir der fehler auf, dass das Fadenkreuz in einer anderen Ecke vom Bildschirm warm. Das hat sich aber durch ein umstellen der Auflösung beheben lassen.
Kannst du mir sagen, bei welcher Auflösung(en) es geklappt hat und bei welcher/n nicht? Das würde mich interessieren.
Kannst du mir sagen, bei welcher Auflösung(en) es geklappt hat und bei welcher/n nicht? Das würde mich interessieren.
Es hat bei mir bei 1920*1080 geklappt.
Als es bei mir nicht geklappt hat, war auch 1920*1080 eingestellt, allerdings über die .ini, über die ich gestartet habe. (Forced Paramteres oder wie das heißt) Als ich dann die Auflösung über den normalen Regler im Menü umgestellt habe, hat alles geklappt.
mud-freak
28.11.2016, 21:09
Ich habe einen Hotfix released: v0.1.1 (Link im Einleitungspost)
Move the project under the MIT License (http://opensource.org/licenses/MIT)
Fix bug with centering the reticle on the screen
G2 Free Aim befindet sich nun unter der MIT Lizenz (http://opensource.org/licenses/MIT).
In kurz: Für Modder bedeutet das weniger Einschränkungen und erwartet bei Benutzung meinen Namen als Autoren anzugeben. Weitere Informationen dazu im Einleitungspost.
Danke an Gorilla und Lehona für die Hilfe beim Fixen des Bugs um die Bildschirmmitte.
Das Setup kann einfach drüber installiert werden.
königsgardist
28.11.2016, 21:35
Lieber mudfreak,
vielen Dank für deine Bemühungen! Ich werde dein Feature testen, sobald es mir wieder ausgeht! Es ist echt beeindruckend, was du zustande gebracht hast- und ich freue mich auf ein aktuelleres Spielegefühl :). Du bist gewaltig! :gratz
lg königsgardist
Miguel7317
29.11.2016, 17:51
Ich bin begeistert, wie viele Mod-Schätze in der letzten Zeit hier auftauchen. Das ist echt großartige Arbeit, mod-freak!
Mal ne Frage... Wie würde es mit Free Aim Support für ältere Modifikationen aussehen, welche prinziell fertig sind und keine Updates mehr erhalten? Ist es möglich, diese mit deinem Sourcecode in Eigenregie zu erweitern?
mud-freak
30.11.2016, 12:54
Dank für das gute Feedback von allen!
Mal ne Frage... Wie würde es mit Free Aim Support für ältere Modifikationen aussehen, welche prinziell fertig sind und keine Updates mehr erhalten? Ist es möglich, diese mit deinem Sourcecode in Eigenregie zu erweitern?
Falls die Skripte (also der Source Code) der Mods zur Verfügung stehen, sollte das leicht zu machen sein. Wenn nicht, ist es soweit ich weiss mindestens schwierig bis nicht möglich.
hi mud-freak,
wie auch schon bei deinem zauberpacket, wirklich eine außerordentlich gute leistung.
Auch ich als modifikationsentwickler hätte natürlich interesse dieses feature einzubauen. ich hätte da nur ein paar fragen, die ich gerne vorab mit dir klären würde.
1. wie ist das verhalten der anderen npc mit der benutzung des bogens? können die das überhaupt noch oder ist es mit dem packet nur noch möglich das der held den bogen "richtig" benutzten kann?
2. wie ist dein eindruck zum balancing? ist es sehr schwer damit zu treffen? wie würdest du es als entwickler im vergleich zum gewöhlichen bogenschießen sehen?
Beste grüße §wink
Aebo
Fisk2033
07.12.2016, 14:13
2. wie ist dein eindruck zum balancing? ist es sehr schwer damit zu treffen? wie würdest du als entwickler im vergleich zum gewöhlichen bogenschießen sehen?
Was mir letztens noch spontan eingefallen ist, ich aber noch nicht ausprobiert habe... Angenommen der Spieler trainiert gar kein Geschick... oder sagen wir so gut wie keins...Hat er dann überhaupt die Chance den Schalter auf Irdorath zu treffen? (da gibts ja eine Stelle, wo man den Schalter abschießen muss)...? §ugly
mud-freak
07.12.2016, 14:29
1. wie ist das verhalten der anderen npc mit der benutzung des bogens? können die das überhaupt noch oder ist es mit dem packet nur noch möglich das der held den bogen "richtig" benutzten kann?
NPCs sind grössenteils unbeeinflusst vom freien Zielen. Bei ihnen funktioniert alles wie zuvor. Das einzige was auch NPCs betrifft ist die Config-Funktion freeAimHitRegWld (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/config.d#L226), die über das Kollisionsverhalten von Projetilen mit der Welt entscheidet.
2. wie ist dein eindruck zum balancing? ist es sehr schwer damit zu treffen? wie würdest du als entwickler im vergleich zum gewöhlichen bogenschießen sehen?
Das ist eine gute Frage. Mit den Standardeinstallungen des Skriptpaketes skaliert die Schussgenauigkeit mit Bogen-/Armbrusttalent (das lässt sich in der Konfiguration alles ändern). Mit einem Bogentalent von 10% trifft man aus mehr als 15-20 Metern nur sehr unverlässlich würde ich mal so sagen. Beim gewöhnliche Bogenschiessen entspricht das Bogentalent eins zu eins der Trefferwahrscheinlichkeit, d.h. mit 10% Bogentalent treffen nur 10% der Schüsse. Wenn man das also vergleicht, sollte es meiner Meinung nach recht ähnlich sein.
Du kannst aber sehr leicht in der Config-Funktion freeAimGetAccuracy (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/config.d#L82) eine andere Accuracy-Berechnung (= Streuung) einbauen. Dabei entspricht 0% Accuracy einer Streuung von einem Radius von 2.2° um das Ziel (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/config.d#L61). Das hört sich nach nicht viel an, aber ist auf einige Entfernung schon gewaltig.
Was mir letztens noch spontan eingefallen ist, ich aber noch nicht ausprobiert habe... Angenommen der Spieler trainiert gar kein Geschick... oder sagen wir so gut wie keins...Hat er dann überhaupt die Chance den Schalter auf Irdorath zu treffen? (da gibts ja eine Stelle, wo man den Schalter abschießen muss)...? §ugly
Das ist ein interessanter Gedanke. Die Schussgenauigkeit skaliert wie oben erwähnt in den Standardeinstellungen des Skriptpaketes mit dem Bogen-/Armbrusttalent, nicht mit Geschicklichkeit. Aber die Frage bleibt natürlich: Was, wenn man mit 10% Bogentalent nach Irdorath fährt. Einerseits sollte man zu dem Zeitpunkt genug Pfeile haben, andererseits sind der Trigger um die Schalter bei Irdorath so gross, dass man eigentlich fast immer treffen sollte (das hatte ich mal ausprobiert).
I hast crash when i shooted to wall (only 2 times) I no have log but i remember a class name of crash
oCAICollideReport...
2)I have sometimes small bug: Arrow flight to up xD Image to example:
http://i.imgur.com/nIxSEJs.png
3)Where did you get this adress? const int mouseUpdate = 5062907; //0x4D40FB // Hook length 5 //
Can you add full function and class name?
mud-freak
08.12.2016, 13:06
I hast crash when i shooted to wall (only 2 times) I no have log but i remember a class name of crash
oCAICollideReport...
2)I have sometimes small bug: Arrow flight to up xD Image to example:
http://i.imgur.com/nIxSEJs.png
3)Where did you get this adress? const int mouseUpdate = 5062907; //0x4D40FB // Hook length 5 //
Can you add full function and class name?
Thank you for reporting these issues.
As you can imagine, I can only guess what caused the crash when shooting the wall. Can you reliably reproduce this crash, and maybe give me more information? Information that would help is:
Did you change anything in the scripts (if so, what)?
What configuration are you using? (Adjustments in freeAim/config.d (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/config.d).)
What material is the wall of that you shot? (You can find out by having the function freeAimHitRegWld (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/config.d#L226) print out the variable 'material'.) Does it happen for different materials, or only for one, e.g. only for the material stone (material == 2)?
I am aware of the issue that the arrow is shot upwards on some occaisions. However, this should only happen very rarely and only if the target is very close. Can you confirm that, or does it also happen when the target is far away?
Here an explanation why it happens:
http://upload.worldofplayers.de/files10/VJp11Q7QFffreeAim_tracerayExplained.png
This cannot be easily changed. The trace ray that is being shot looks very simple here, but in fact it is very much more complicated and sits at the core of this script package. I do not recommend changing it, this will make everything unstable. But if you have an idea of how to fix it, let me know, and I will tell you if the stability of the script will be effected.
EDIT: This issue has been resolved and will be in the next release after v0.1.2
In general for all my code, I always name the address-variables by the function-name at that address. If they have a different name, the address is either an unnamed engine function, or it is somewhere within (but not at the start) of an engine function. In the case of mouseUpdate, at the address 0x4D40FB there is an unnamed engine function (something like 'sub_4D3D90') responsible for mouse movement.
1)I shoot to tower wall. It's possible get VOB vectors? (I'm trying change a flight vector, but i don't know where i can find pointer to this :/ )
mud-freak
08.12.2016, 15:41
1)I shoot to tower wall.
This doesn't really give me much more information (I assume the material is stone). Can you elaborate more, when and how the game crashes?
It's possible get VOB vectors? (I'm trying change a flight vector, but i don't know where i can find pointer to this :/ )
What is it exactly, you are trying to do, if I may ask? Do you want to change the trajectory of the projectile?
With the script you can already manipulate the gravity (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/config.d#L63) and the point in time (after shooting) when the gravity is applied (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/config.d#L62). I can't think of anything else you would want to do with the flight path?!
Anyway, when I was working on it, I could not find a clearly defined trajectory of the projectile. Although I had already spent some time searching a while back, you can checkout the AI of the projectile. The classes oCAIArrow and oCAIArrowBase don't have a property for the trajectory, however. The only thing I could find was a velocity vector in the class zCRigidBody. I don't think changing the vob vectors will impact the trajectory.
The AI of moving objects seemed rather complicated to me as I couldn't find all engine functions involved.
I have LoG and AV window :)
Window:
======================================= UNHANDLED EXCEPTION OCCURED ======================================================
======================================= CRASH INFOS: =====================================================================
Gothic II - 2.6 (fix), Parser Version: 50
User: Siemekk, CPUType: 586, Mem: 0 MB total, 0 MB free
Camera: Pos(-3387.88208/-1449.48401/1346.63196), At(0.809637845/0.443677604/-0.384235322)
Startup Options:-game:gothicgame.ini -zreparse -znomusic -znosound -zlog:10,s -zmaxframerate:60
=============================================== CALLSTACK : ==============================================================
0023:007928EC (0x00000010 0x189542C8 0x00AB4118 0x00AB40C0) Gothic2.exe, zSTRING0023:007928EC (0x00000010 0x189542C8 0x00AB4118 0x00AB40C0) Gothic2.ex
0023:00792610 (0x00004017 0x00000003 0x18A46D4C 0x18A46D4C) Gothic2.exe, zCParser::DoStack()+3248 byte(s), P:\dev\g2addon\release\ZenGin\_ulf\zParser.cpp, line 1457+29 byte(s)
0023:00792CBF (0x009A42B8 0x0135F908 0x00800E8B 0x006A1CA5) Gothic2.exe, zCParser::CallFunc()+719 byte(s), P:\dev\g2addon\release\ZenGin\_ulf\zParser.cpp, line 1551G::z3:007928EC (0x00000010 0x189542C8 0x00AB4118 0x00AB40C0) Gothic2.exe, zSTRIN°íÇ3:007928EC (0x00000010 0x189542C8 0x00AB4118 0x00AB40C0) Gothic2.exe, zSTRING0023:007928EC (0x00000010 0x189542C8 0x00AB4118 0x00AB40C0) Gothic2.ex
0023:006A1596 (0xFFFFFFFF 0x0061EF65 0x008D7FA8 0x00000000) Gothic2.exe, oCAIArrow::ReportCollisionToAI()+102 byte(s), P:\dev\g2addon\release\Gothic\_ulf\oAiShoot.cpp, line 1073+21 byte(s)
0023:008178F6 (0x645B5D5E 0x00000D89 0xC4810000 0x0000019C) Gothic2.exe, SetFileAttributesA()+212274 byte(s)
And log:
https://ufile.io/2562f
mud-freak
09.12.2016, 14:14
I have LoG and AV window :)
Window:
[...]
And log:
https://ufile.io/2562f
Okay, thank you. So the part of the log suggests there is something wrong in the function freeAimOnArrowCollide() (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/_intern.d#L897L919).
[f] 01:15 Fault: 0 Q: [start of stacktrace]
[f] 01:15 Fault: 0 Q: FREEAIMONARROWCOLLIDE() + 168 bytes
[f] 01:15 Fault: 0 Q: [end of stacktrace]
The stacktrace does not show any previous function, since that function is a hook and called by the eninge. But since the stacktrace does not list any more nested functions within freeAimOnArrowCollide() (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/_intern.d#L897L919), I am not exactly sure what caused the crash. The access violation text would suggest some sort of string operation failed (zSTRING0023:007928EC) while calling the function (zCParser::CallFunc()).
I have a few ideas, but do the following. Add an individually identifiable print-out after every line in freeAimOnArrowCollide() (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/_intern.d#L897L919). This is a bit tedious, but will tell us exactly after which line the crash appeared. The function freeAimOnArrowCollide() (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/_intern.d#L897L919) should look like this then:
/* Arrow collides with world (static or non-npc vob). Either destroy, deflect or collide */
func void freeAimOnArrowCollide() {
MEM_Info("### DEBUG: freeAimOnArrowCollide() #1");
var oCItem projectile; projectile = _^(MEM_ReadInt(ESI+60)); // esi+3Ch
MEM_Info("### DEBUG: freeAimOnArrowCollide() #2");
var C_Npc shooter; shooter = _^(MEM_ReadInt(esi+92)); // esi+5Ch
MEM_Info("### DEBUG: freeAimOnArrowCollide() #3");
var int matobj; matobj = MEM_ReadInt(ECX); // zCMaterial* or zCPolygon*
MEM_Info("### DEBUG: freeAimOnArrowCollide() #4");
if (MEM_ReadInt(matobj) != zCMaterial__vtbl) { matobj = MEM_ReadInt(matobj+24); }; // Static world: Read zCPolygon
MEM_Info("### DEBUG: freeAimOnArrowCollide() #5");
var int material; material = MEM_ReadInt(matobj+64);
MEM_Info("### DEBUG: freeAimOnArrowCollide() #6");
var string texture; texture = MEM_ReadString(MEM_ReadInt(matobj+52)+16); // zCMaterial.texture._zCObject_objectName
MEM_Info("### DEBUG: freeAimOnArrowCollide() #7");
var int collision; collision = freeAimHitRegWld_(shooter, material, texture); // 0=destroy, 1=stay, 2=deflect
MEM_Info("### DEBUG: freeAimOnArrowCollide() #8");
if (collision == 1) { // Collide
EDI = material; // Sets the condition at 0x6A0A45 and 0x6A0C1A to true: Projectile stays
} else {
EDI = -1; // Sets the condition at 0x6A0A45 and 0x6A0C1A to false: Projectile deflects
if (!collision) {
MEM_Info("### DEBUG: freeAimOnArrowCollide() #9");
if (FF_ActiveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody))) {
FF_RemoveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody)); };
if (FREEAIM_REUSE_PROJECTILES) { // Destroy
Wld_StopEffect(FREEAIM_BREAK_FX); // Sometimes collides several times
Wld_PlayEffect(FREEAIM_BREAK_FX, projectile, projectile, 0, 0, 0, FALSE);
MEM_Info("### DEBUG: freeAimOnArrowCollide() #10");
MEM_WriteInt(ESI+56, -1073741824); // oCAIArrow.lifeTime // Mark this AI for freeAimWatchProjectile()
};
};
};
MEM_Info("### DEBUG: freeAimOnArrowCollide() #11"); // No problem
};
After that start the game and provoke the crash again and show me the log again, please.
[i] 00:27 Info: 0 Q: ### DEBUG: freeAimOnArrowCollide() #1
[i] 00:27 Info: 0 Q: ### DEBUG: freeAimOnArrowCollide() #2
[i] 00:27 Info: 0 Q: ### DEBUG: freeAimOnArrowCollide() #3
[i] 00:27 Info: 0 Q: ### DEBUG: freeAimOnArrowCollide() #4
[i] 00:27 Info: 0 Q: ### DEBUG: freeAimOnArrowCollide() #5
[i] 00:27 Info: 0 Q: ### DEBUG: freeAimOnArrowCollide() #6
[f] 00:27 Fault: 0 Q: [start of stacktrace]
[f] 00:27 Fault: 0 Q: FREEAIMONARROWCOLLIDE() + 228 bytes
[f] 00:27 Fault: 0 Q: [end of stacktrace]
This Write String?
var string texture; texture = MEM_ReadString(MEM_ReadInt(matobj+52)+16); // zCMaterial.texture._zCObject_objectName
mud-freak
09.12.2016, 19:58
This Write String?
var string texture; texture = MEM_ReadString(MEM_ReadInt(matobj+52)+16); // zCMaterial.texture._zCObject_objectName
Thank you. Yes, I assumed something like this (because the access violation mentioned a string operation). Change the function freeAimOnArrowCollide() (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/_intern.d#L897L919) to this, and post the log again, please:
/* Arrow collides with world (static or non-npc vob). Either destroy, deflect or collide */
func void freeAimOnArrowCollide() {
var oCItem projectile; projectile = _^(MEM_ReadInt(ESI+60)); // esi+3Ch
var C_Npc shooter; shooter = _^(MEM_ReadInt(esi+92)); // esi+5Ch
var int matobj; matobj = MEM_ReadInt(ECX); // zCMaterial* or zCPolygon*
MEM_Info(ConcatStrings("### DEBUG: Class ", MEM_GetClassName(matobj))); // Should return zCPolygon or zCMaterial
if (MEM_ReadInt(matobj) != zCMaterial__vtbl) { matobj = MEM_ReadInt(matobj+24); }; // Static world: Read zCPolygon
MEM_Info(ConcatStrings("### DEBUG: Class ", MEM_GetClassName(matobj))); // Should return zCPolygon
MEM_Info(ConcatStrings("### DEBUG: Class ", MEM_GetClassName(MEM_ReadInt(matobj+52)))); // Should return zCTexture
var int material; material = MEM_ReadInt(matobj+64);
var string texture; texture = MEM_ReadString(MEM_ReadInt(matobj+52)+16); // zCMaterial.texture._zCObject_objectName
var int collision; collision = freeAimHitRegWld_(shooter, material, texture); // 0=destroy, 1=stay, 2=deflect
if (collision == 1) { // Collide
EDI = material; // Sets the condition at 0x6A0A45 and 0x6A0C1A to true: Projectile stays
} else {
EDI = -1; // Sets the condition at 0x6A0A45 and 0x6A0C1A to false: Projectile deflects
if (!collision) {
if (FF_ActiveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody))) {
FF_RemoveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody)); };
if (FREEAIM_REUSE_PROJECTILES) { // Destroy
Wld_StopEffect(FREEAIM_BREAK_FX); // Sometimes collides several times
Wld_PlayEffect(FREEAIM_BREAK_FX, projectile, projectile, 0, 0, 0, FALSE);
MEM_WriteInt(ESI+56, -1073741824); // oCAIArrow.lifeTime // Mark this AI for freeAimWatchProjectile()
};
};
};
};
https://ufile.io/159d9
I don't see MEM_Infos ;/
mud-freak
09.12.2016, 20:54
Sorry, that was my fault. Without the first one. Try it like this:
/* Arrow collides with world (static or non-npc vob). Either destroy, deflect or collide */
func void freeAimOnArrowCollide() {
var oCItem projectile; projectile = _^(MEM_ReadInt(ESI+60)); // esi+3Ch
var C_Npc shooter; shooter = _^(MEM_ReadInt(esi+92)); // esi+5Ch
var int matobj; matobj = MEM_ReadInt(ECX); // zCMaterial* or zCPolygon*
if (MEM_ReadInt(matobj) != zCMaterial__vtbl) { matobj = MEM_ReadInt(matobj+24); }; // Static world: Read zCPolygon
MEM_Info(ConcatStrings("### DEBUG: Class ", MEM_GetClassName(matobj))); // Should return zCMaterial
MEM_Info(ConcatStrings("### DEBUG: Class ", MEM_GetClassName(MEM_ReadInt(matobj+52)))); // Should return zCTexture
var int material; material = MEM_ReadInt(matobj+64);
var string texture; texture = MEM_ReadString(MEM_ReadInt(matobj+52)+16); // zCMaterial.texture._zCObject_objectName
var int collision; collision = freeAimHitRegWld_(shooter, material, texture); // 0=destroy, 1=stay, 2=deflect
if (collision == 1) { // Collide
EDI = material; // Sets the condition at 0x6A0A45 and 0x6A0C1A to true: Projectile stays
} else {
EDI = -1; // Sets the condition at 0x6A0A45 and 0x6A0C1A to false: Projectile deflects
if (!collision) {
if (FF_ActiveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody))) {
FF_RemoveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody)); };
if (FREEAIM_REUSE_PROJECTILES) { // Destroy
Wld_StopEffect(FREEAIM_BREAK_FX); // Sometimes collides several times
Wld_PlayEffect(FREEAIM_BREAK_FX, projectile, projectile, 0, 0, 0, FALSE);
MEM_WriteInt(ESI+56, -1073741824); // oCAIArrow.lifeTime // Mark this AI for freeAimWatchProjectile()
};
};
};
};
I assume, the log will look like this (only the first output):
[i] 00:27 Info: 0 Q: ### DEBUG: Class zCMaterial
[f] 00:27 Fault: 0 Q: [start of stacktrace]
[f] 00:27 Fault: 0 Q: FREEAIMONARROWCOLLIDE() + 228 bytes
[f] 00:27 Fault: 0 Q: [end of stacktrace]
If that's the case, I have no idea what's wrong, but it would be definetly on your end (something wrong with the wall you are shooting).
By the way: I noticed you are using G2 Free Aim v0.1.0. I recommend using the newest version of G2 Free Aim (https://github.com/szapp/g2freeAim/releases/latest).
mud-freak
10.12.2016, 11:44
Ich habe im Einleitungspost ein FAQ hinzugefügt.
Next Log:
https://ufile.io/84be0
mud-freak
10.12.2016, 12:30
Next Log:
https://ufile.io/84be0
Do the same again, by replacing the function freeAimOnArrowCollide() and posting the log again. After that I can tell you what exactly is wrong:
/* Arrow collides with world (static or non-npc vob). Either destroy, deflect or collide */
func void freeAimOnArrowCollide() {
var oCItem projectile; projectile = _^(MEM_ReadInt(ESI+60)); // esi+3Ch
var C_Npc shooter; shooter = _^(MEM_ReadInt(esi+92)); // esi+5Ch
var int matobj; matobj = MEM_ReadInt(ECX); // zCMaterial* or zCPolygon*
if (MEM_ReadInt(matobj) != zCMaterial__vtbl) { matobj = MEM_ReadInt(matobj+24); }; // Static world: Read zCPolygon
MEM_Info(ConcatStrings("### DEBUG: address matobj: ", IntToString(matobj))); // Positive integer
MEM_Info(ConcatStrings("### DEBUG: class matobj: ", MEM_GetClassName(matobj))); // zCMaterial
MEM_Info(ConcatStrings("### DEBUG: obj vtbl: ", IntToString(MEM_ReadInt(matobj)))); // 8593940
MEM_Info(ConcatStrings("### DEBUG: material ID: ", IntToString(MEM_ReadInt(matobj+64)))); // Positive integer
MEM_Info(ConcatStrings("### DEBUG: address texture: ", IntToString(MEM_ReadInt(matobj+52)))); // Positive integer
MEM_Info(ConcatStrings("### DEBUG: class texture: ", MEM_GetClassName(MEM_ReadInt(matobj+52)))); // zCTexture
var int material; material = MEM_ReadInt(matobj+64);
var string texture; texture = MEM_ReadString(MEM_ReadInt(matobj+52)+16); // zCMaterial.texture._zCObject_objectName
var int collision; collision = freeAimHitRegWld_(shooter, material, texture); // 0=destroy, 1=stay, 2=deflect
if (collision == 1) { // Collide
EDI = material; // Sets the condition at 0x6A0A45 and 0x6A0C1A to true: Projectile stays
} else {
EDI = -1; // Sets the condition at 0x6A0A45 and 0x6A0C1A to false: Projectile deflects
if (!collision) {
if (FF_ActiveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody))) {
FF_RemoveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody)); };
if (FREEAIM_REUSE_PROJECTILES) { // Destroy
Wld_StopEffect(FREEAIM_BREAK_FX); // Sometimes collides several times
Wld_PlayEffect(FREEAIM_BREAK_FX, projectile, projectile, 0, 0, 0, FALSE);
MEM_WriteInt(ESI+56, -1073741824); // oCAIArrow.lifeTime // Mark this AI for freeAimWatchProjectile()
};
};
};
};
EDIT: You don't need to do it. I think I have figured it out: There is a surface that has no assigned texture (which is weird, it should be an empty texture, not none at all).
What world are you using for testing? Is it an original world from Gothic II or your own?
If you don't want to look for the source of your problem, you can simply fix it by this:
/* Arrow collides with world (static or non-npc vob). Either destroy, deflect or collide */
func void freeAimOnArrowCollide() {
var oCItem projectile; projectile = _^(MEM_ReadInt(ESI+60)); // esi+3Ch
var C_Npc shooter; shooter = _^(MEM_ReadInt(esi+92)); // esi+5Ch
var int matobj; matobj = MEM_ReadInt(ECX); // zCMaterial* or zCPolygon*
if (MEM_ReadInt(matobj) != zCMaterial__vtbl) { matobj = MEM_ReadInt(matobj+24); }; // Static world: Read zCPolygon
var int material; material = MEM_ReadInt(matobj+64);
var string texture; texture = MEM_ReadString(MEM_ReadInt(matobj+52)+16); // zCMaterial.texture._zCObject_objectName
var string texture; texture = "";
if (MEM_ReadInt(matobj+52)) {
texture = MEM_ReadString(MEM_ReadInt(matobj+52)+16); // zCMaterial.texture._zCObject_objectName
};
var int collision; collision = freeAimHitRegWld_(shooter, material, texture); // 0=destroy, 1=stay, 2=deflect
if (collision == 1) { // Collide
EDI = material; // Sets the condition at 0x6A0A45 and 0x6A0C1A to true: Projectile stays
} else {
EDI = -1; // Sets the condition at 0x6A0A45 and 0x6A0C1A to false: Projectile deflects
if (!collision) {
if (FF_ActiveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody))) {
FF_RemoveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody)); };
if (FREEAIM_REUSE_PROJECTILES) { // Destroy
Wld_StopEffect(FREEAIM_BREAK_FX); // Sometimes collides several times
Wld_PlayEffect(FREEAIM_BREAK_FX, projectile, projectile, 0, 0, 0, FALSE);
MEM_WriteInt(ESI+56, -1073741824); // oCAIArrow.lifeTime // Mark this AI for freeAimWatchProjectile()
};
};
};
};
Neconspictor
10.12.2016, 13:03
@mud-freak: It is possible to use a 3d model with a material, that has only diffuse color information. I did this once.
mud-freak
10.12.2016, 13:26
@mud-freak: It is possible to use a 3d model with a material, that has only diffuse color information. I did this once.
Oh, thanks for the clarification! I committed a fix to github, in case somebody has the same problem. I might create a new release at some point in the future (but not for this small fix alone).
MyGamingHD
10.12.2016, 16:38
Hey Mud-Freak,
ich wollte mich heute einmal hinsetzen und versuchen free-aim in ein Test Projekt zu intergrieren, mit dem Installer, allerdings kommt bei jedem Versuch das Spiel ohne weitere Anpassungen zu starten die Fehler Meldung
00:13 Fatal:-1 U: PAR: Syntax error :  ( line 1 ) .... <zParser.cpp,#599>
Ohne FreeAim kommt sie nicht, mit FreeAim schon (5 mal getestet um sicher zu sein).
Hier noch der ZSpy Log (https://www.dropbox.com/s/d0l0u462f5tu36h/Error.log?dl=0).
Istalliert ist neuste Ikarus und LeGo Version sowie das Systempack.
Vielleicht hast du ja eine Idee woran dies liegen könnte.
mud-freak
10.12.2016, 16:43
Hey Mud-Freak,
ich wollte mich heute einmal hinsetzen und versuchen free-aim in ein Test Projekt zu intergrieren, mit dem Installer, allerdings kommt bei jedem Versuch das Spiel ohne weitere Anpassungen zu starten die Fehler Meldung
00:13 Fatal:-1 U: PAR: Syntax error :  ( line 1 ) .... <zParser.cpp,#599>
Ohne FreeAim kommt sie nicht, mit FreeAim schon (5 mal getestet um sicher zu sein).
Hier noch der ZSpy Log (https://www.dropbox.com/s/d0l0u462f5tu36h/Error.log?dl=0).
Istalliert ist neuste Ikarus und LeGo Version sowie das Systempack.
Vielleicht hast du ja eine Idee woran dies liegen könnte.
Das ist ein Fehler der mit dem Encoding zusammenhängt. Leider scheint der Installer nach Einfügen von Zeilen die Datei anders wieder abzuspeichern (das konnte ich nicht besser programmieren, weil nicht immer eindeutig ist um welche Kodierung es sich handelt). Dass es beim Blink-Setup vorkommt war mir bekannt - dass es auch bei der G2 Free Aim Installation passieren kann, wusste ich noch nicht.
Danke fürs Anhängen des zSpy-Logs. Laut dem scheint die betroffene Datei die Startup.d zu sein. Öffne sie einfach und speichere sie mit der Kodierung ANSI (Windows-1252) wieder ab. Dann sollte es klappen.
Ich nehme den Fehler mal ins FAQ mit auf.
UTF-8? Ich bin mir ziemlich sicher, dass der Parser ANSI-codierte (Latin-1) Dateien erwartet.
mud-freak
10.12.2016, 16:53
UTF-8? Ich bin mir ziemlich sicher, dass der Parser ANSI-codierte Dateien erwartet.
Bei mir hat das immer geklappt. Solange es ohne BOM ist.
Bei mir hat das immer geklappt. Solange es ohne BOM ist.
Und solange man keine Zeichen verwendet, die nicht Teil von ASCII sind (die werden üblicherweise nämlich mit 2 Byte kodiert).
Ich glaube, niemand verwendet Umlaute im eigentlichen Code, aber innerhalb von Strings treten sie nunmal doch auf.
Also: Einfach Latin-1 nehmen ;)
mud-freak
10.12.2016, 17:02
Und solange man keine Zeichen verwendet, die nicht Teil von ASCII sind (die werden üblicherweise nämlich mit 2 Byte kodiert).
Ich glaube, niemand verwendet Umlaute im eigentlichen Code, aber innerhalb von Strings treten sie nunmal doch auf.
Also: Einfach Latin-1 nehmen ;)
Stimmt du hast recht. Ich hatte mal die Text.d mit UTF-8 kodiert, das war nicht so hübsch im Spiel. Ich änder das mal im Post oben.
I found way how to easy change a arrow speed :D
Add this code under:
// Set gravity (but not enabled)
MEM_WriteInt(rBody+4,castToIntf(0.15));
I don't know if it is a good pointer, but in my script working good :D
mud-freak
11.12.2016, 00:30
Eine Sache, die ich komplett vergessen habe zu teilen:
Wie im Einleitungspost erwähnt habe ich für die Mod "Gothic II - Freies Zielen" Schwachstellen für fast alle Gothic 2 Wesen einzeln für den jeweiligen Kopf und dessen grösse festgelegt (Kopfschussmultiplikator). Wie das in den Skripten aussieht, kann man sich in den Mod Skripten in der Modderdatenbank (http://www.worldofgothic.de/?go=moddb&action=view&fileID=1330) anschauen.
Wenn man nun aber verschiedene Schwachstellen für Monster festlegen will (Arm/Bein/Körper/...), wie von Simon vorgeschlagen, kann es etwas mühselig werden diese festzulegen (passenden Bone für jedes Monster herausfinden und die Grösse anständig definieren, damit ein Pfeil auch tatsächlich nur dann trifft, wenn er nah genug am Mittelpunkt des Bones eintrifft).
Für die oben genannten Skripte hatte ich mir ein Hilfsskript gebaut, dass mir alle Gothic 2 Monster nach einander eingefügt und eingefroren und mit einer Boundingbox versehen hat, entsprechend der für das Monster definierten Position und Grösse. So konnte ich leicht überprüfen, was passt und was noch angepasst werden muss. Das hat mir einiges an Arbeit abgenommen.
Ich möchte hier dazu das Skript teilen. Wie es funktioniert, sollte aus den Kommentaren ersichtlich sein. Dazu sei erwähnt, dass es nur zu Testzwecken benutzt und keinesfalls in einer fertigen Mod eingebunden werden sollte, da es ab und zu zu Crashs führen kann. Geparst werden sollte dieses Skript natürlich nach G2 Free Aim.
/*
* Inspect weakspots for all monster models by inserting them iteratively one-by-one through console commands.
* The weakspot node will be visualized automatically by a bbox. This script is useful to decide on suitable weakspots.
* This script is obviously strictly for testing purposes and will occasionally lead to crashes.
*
* Usage:
* Open the console and type
* debug insert next To insert the next (first) monster (will remove the previous monster)
* debug insert again To insert the previous monster again
* debug insert set [X] To set the index to [X] (where [X] is an integer between 1 and MONSTER_INSERT_MAX)
*
* This script contains parts of G2 Free Aim (C) Copyright 2016 mud-freak (@szapp) <http://github.com/szapp/g2freeAim>.
*/
const string MONSTER_INSERT_WP = "NW_CITY_MERCHANT_PATH_28_D"; // Way point to spawn and inspect the monsters
const int MONSTER_INSERT_MAX = 80; // Total number of monsters (see getMonsterInst() below)
var int lastMonster; // Instance ID of previous monster inserted (internal)
/* Register console commands */
func void freeAim_inspectWeakspots() {
CC_Register(insertMonster, "debug insert ", "insert all monsters iteratively");
};
/* Update the position and size of the weakspot bbox (taken from freeAimDetectCriticalHit() from G2 Free Aim) */
func void updateWeakspot(var int npcInst) {
var C_Npc targetNpc; targetNpc = Hlp_GetNpc(npcInst);
var int damage; var int damagePtr; damagePtr = _@(damage);
var zCVob targetVob; targetVob = Hlp_GetNpc(npcInst);
targetVob.bitfield[2] = targetVob.bitfield[2] &~ zCVob_bitfield2_sleepingMode; // Prevent idle animations
var int target; target = _@(targetNpc);
// Get model from target npc
const int call = 0;
if (CALL_Begin(call)) {
CALL__thiscall(_@(target), oCNpc__GetModel);
call = CALL_End();
};
var int model; model = CALL_RetValAsPtr();
// Get weak spot node from target model
var int autoAlloc[8]; var Weakspot weakspot; weakspot = _^(_@(autoAlloc)); // Gothic takes care of freeing this ptr
MEM_CopyWords(_@s(""), _@(autoAlloc), 5); // weakspot.node (reset string)
freeAimCriticalHitDef_(targetNpc, MEM_ReadInt(damagePtr), _@(weakspot)); // Retrieve weakspot specs
var int nodeStrPtr; nodeStrPtr = _@(weakspot);
if (Hlp_StrCmp(MEM_ReadString(nodeStrPtr), "")) { return; }; // No critical node defined
const int call2 = 0;
if (CALL_Begin(call2)) {
CALL_PtrParam(_@(nodeStrPtr));
CALL__thiscall(_@(model), zCModel__SearchNode);
call2 = CALL_End();
};
var int node; node = CALL_RetValAsPtr();
if (!node) { MEM_Warn("updateWeakspot: Node not found!"); return; };
if (weakspot.dimX == -1) && (weakspot.dimY == -1) { // Retrieve the bbox by model
if (MEM_ReadInt(node+8)) { // node->nodeVisual // If the node has a dedicated visual, retrieve bbox
// Get the bbox of the node (although zCModelNodeInst has a zTBBox3D property, it is empty the first time)
CALL_PtrParam(node); CALL_RetValIsStruct(24); // sizeof_zTBBox3D // No recyclable call possible
CALL__thiscall(model, zCModel__GetBBox3DNodeWorld);
var int nodeBBoxPtr; nodeBBoxPtr = CALL_RetValAsPtr();
MEM_CopyWords(nodeBBoxPtr, _@(freeAimDebugWSBBox), 6); // zTBBox3D
MEM_Free(nodeBBoxPtr); // Free memory
} else {
MEM_Error("updateWeakspot: Node has no boundingbox!");
return;
};
} else if (weakspot.dimX < 0) || (weakspot.dimY < 0) { // Bbox dimensions must be positive
MEM_Error("updateWeakspot: Boundingbox dimensions illegal!");
return;
} else { // Create bbox by dimensions
weakspot.dimX /= 2; weakspot.dimY /= 2;
// Get the position of the node (although zCModelNodeInst has a position property, it is empty the first time)
CALL_PtrParam(node); CALL_RetValIsStruct(12); // sizeof_zVEC3 // No recyclable call possible bc of structure
CALL__thiscall(model, zCModel__GetNodePositionWorld);
var int nodPosPtr; nodPosPtr = CALL_RetValAsInt();
var int nodePos[3]; MEM_CopyWords(nodPosPtr, _@(nodePos), 3);
MEM_Free(nodPosPtr); // Free memory
freeAimDebugWSBBox[0] = subf(nodePos[0], mkf(weakspot.dimX)); // Build an own bbox by the passed node dimensions
freeAimDebugWSBBox[1] = subf(nodePos[1], mkf(weakspot.dimY));
freeAimDebugWSBBox[2] = subf(nodePos[2], mkf(weakspot.dimX));
freeAimDebugWSBBox[3] = addf(nodePos[0], mkf(weakspot.dimX));
freeAimDebugWSBBox[4] = addf(nodePos[1], mkf(weakspot.dimY));
freeAimDebugWSBBox[5] = addf(nodePos[2], mkf(weakspot.dimX));
};
FREEAIM_DEBUG_WEAKSPOT = 1;
MEM_Info(ConcatStrings(ConcatStrings(ConcatStrings(ConcatStrings(ConcatStrings(" Weakspot :: node size ",
IntToString(weakspot.dimX)), "x "), IntToString(weakspot.dimY)), "y "), targetNpc.name));
};
/* Retrieve monster instance id by number */
func int getMonsterInst(var int num) {
var int monster;
if (num == 1) { monster = Alligator; };
if (num == 2) { monster = Blattcrawler; };
if (num == 3) { monster = Bloodhound; };
if (num == 4) { monster = Giant_DesertRat; };
if (num == 5) { monster = Gobbo_Warrior; };
if (num == 6) { monster = Gobbo_Warrior_Visir; };
if (num == 7) { monster = Icewolf; };
if (num == 8) { monster = Keiler; };
if (num == 9) { monster = Undead_Mud; };
if (num == 10) { monster = Summoned_Mud; };
if (num == 11) { monster = OrcBiter; };
if (num == 12) { monster = Razor; };
if (num == 13) { monster = Shadowbeast_Addon_Fire; };
if (num == 14) { monster = Summoned_Guardian; };
if (num == 15) { monster = Stoneguardian; };
if (num == 16) { monster = StonePuma; };
if (num == 17) { monster = SwampDrone; };
if (num == 18) { monster = SwampGolem; };
if (num == 19) { monster = Swamprat; };
if (num == 20) { monster = SwampZombie; };
if (num == 21) { monster = Swarm; };
if (num == 22) { monster = Bloodfly; };
if (num == 23) { monster = YBloodfly; };
if (num == 24) { monster = Demon; };
if (num == 25) { monster = Summoned_Demon; };
if (num == 26) { monster = DemonLord; };
if (num == 27) { monster = Draconian; };
if (num == 28) { monster = Dragon_Fire; };
if (num == 29) { monster = Dragon_Ice; };
if (num == 30) { monster = Dragon_Rock; };
if (num == 31) { monster = Dragon_Swamp; };
if (num == 32) { monster = Dragon_Undead; };
if (num == 33) { monster = DragonSnapper; };
if (num == 34) { monster = FireGolem; };
if (num == 35) { monster = FireWaran; };
if (num == 36) { monster = Giant_Bug; };
if (num == 37) { monster = YGiant_Bug; };
if (num == 38) { monster = Giant_Rat; };
if (num == 39) { monster = YGiant_Rat; };
if (num == 40) { monster = Gobbo_Black; };
if (num == 41) { monster = Gobbo_Green; };
if (num == 42) { monster = YGobbo_Green; };
if (num == 43) { monster = Gobbo_Skeleton; };
if (num == 44) { monster = Summoned_Gobbo_Skeleton; };
if (num == 45) { monster = Harpie; };
if (num == 46) { monster = IceGolem; };
if (num == 47) { monster = Lurker; };
if (num == 48) { monster = Meatbug; };
if (num == 49) { monster = Minecrawler; };
if (num == 50) { monster = Minecrawler_Priest; };
if (num == 51) { monster = GoldMinecrawler; };
if (num == 52) { monster = MinecrawlerWarrior; };
if (num == 53) { monster = Molerat; };
if (num == 54) { monster = Scavenger; };
if (num == 55) { monster = Scavenger_Demon; };
if (num == 56) { monster = Shadowbeast; };
if (num == 57) { monster = Shadowbeast_Skeleton; };
if (num == 58) { monster = Sheep; };
if (num == 59) { monster = Hammel; };
if (num == 60) { monster = Skeleton; };
if (num == 61) { monster = Summoned_Skeleton; };
if (num == 62) { monster = Lesser_Skeleton; };
if (num == 63) { monster = Skeleton_Lord; };
if (num == 64) { monster = SkeletonMage; };
if (num == 65) { monster = Snapper; };
if (num == 66) { monster = StoneGolem; };
if (num == 67) { monster = Summoned_Golem; };
if (num == 68) { monster = Shattered_Golem; };
if (num == 69) { monster = MagicGolem; };
if (num == 70) { monster = Swampshark; };
if (num == 71) { monster = Troll; };
if (num == 72) { monster = Troll_Black; };
if (num == 73) { monster = Waran; };
if (num == 74) { monster = Warg; };
if (num == 75) { monster = BlackWolf; };
if (num == 76) { monster = Wisp; };
if (num == 77) { monster = Wolf; };
if (num == 78) { monster = Summoned_Wolf; };
if (num == 79) { monster = YWolf; };
if (num == 80) { monster = Summoned_Zombie; };
return monster;
};
/* Core function: Insert/remove monsters by console commands */
func string insertMonster(var string command) {
var int idx; var int monster;
if (Hlp_StrCmp(command, "next")) {
if (idx >= MONSTER_INSERT_MAX) { return "No further monsters to insert."; };
idx += 1;
monster = getMonsterInst(idx);
} else if (Hlp_StrCmp(command, "again")) {
if (idx > MONSTER_INSERT_MAX) { return "No further monsters to insert."; };
if (idx < 1) { return "No monster was inserted so far. Use 'debug insert next' first."; };
monster = getMonsterInst(idx);
} else if (Hlp_StrCmp(STR_SubStr(command, 0, 4), "set ")) {
var int numRequest; numRequest = STR_ToInt(STR_SubStr(command, 4, STR_Len(command)-4));
if (numRequest <= MONSTER_INSERT_MAX) && (numRequest > 0) {
idx = numRequest;
return ConcatStrings("Set index to #", IntToString(idx));
} else {
return ConcatStrings(ConcatStrings("Requested index #", IntToString(numRequest)), " is invalid");
};
} else { return "Please specify either 'next', 'again' or 'set [newId]'"; };
FREEAIM_DEBUG_WEAKSPOT = 0; // Remove bbox (will be shown again by updateWeakspot() once new monster is inserted)
var C_Npc lastMonsterInst; lastMonsterInst = Hlp_GetNpc(lastMonster);
if (Hlp_IsValidNpc(lastMonsterInst)) && (!Npc_IsPlayer(lastMonsterInst)) { // First time lastMonster is empty
FF_RemoveData(updateWeakspot, lastMonster);
AI_Teleport(lastMonsterInst, "TOT"); // This does not work if monsters inserted to rapidly
lastMonsterInst.attribute[ATR_HITPOINTS] = 0;
};
Wld_InsertNpc(monster, MONSTER_INSERT_WP);
var C_Npc monsterInst; monsterInst = Hlp_GetNpc(monster);
if (Hlp_IsValidNpc(monsterInst)) && (!Npc_IsDead(monsterInst)) { // Seems not to work -> crash if out of AI range
monsterInst.senses_range = -1;
monsterInst.senses = 0;
monsterInst.start_aistate = ZS_MM_Rtn_DragonRest; // Non-responsive
monsterInst.aivar[AIV_MM_RestStart] = OnlyRoutine;
FF_ApplyExtData(updateWeakspot, 1000, 1, monster); // FF here, because monster takes a while to fully insert
};
lastMonster = monster;
return ConcatStrings(ConcatStrings(ConcatStrings("Inserted '", monsterInst.name), "' #"), IntToString(idx));
};
___
I found way how to easy change a arrow speed :D
Add this code under:
// Set gravity (but not enabled)
MEM_WriteInt(rBody+4,castToIntf(0.15));
I don't know if it is a good pointer, but in my script working good :D
Thanks for sharing!
Where you have a code of distance of fly arrow? I have crazy idea, but i don't know where you save this code ;)
And change projectile acceleration (Presentation):
https://youtu.be/u_I6caYbJAA
Old Code is bad :< this is new code:
/* Once a projectile stopped moving keep it alive */
func void freeAimWatchProjectile() {
var int arrowAI; arrowAI = ECX; // oCAIArrow*
var int projectilePtr; projectilePtr = MEM_ReadInt(ESP+4); // oCItem*
var int removePtr; removePtr = MEM_ReadInt(ESP+8); // int* (call-by-reference argument)
if (!projectilePtr) { return; }; // oCItem* might not exist
var oCItem projectile; projectile = _^(projectilePtr);
if (!projectile._zCVob_rigidBody) { return; }; // zCRigidBody* might not exist the first time
// Reset projectile gravity (zCRigidBody.gravity) after collision (oCAIArrow.collision)
if (MEM_ReadInt(arrowAI+52)) // Set gravity and acceleration to default
{
MEM_WriteInt(projectile._zCVob_rigidBody+236, FLOATONE);
MEM_WriteInt(projectile._zCVob_rigidBody+236, castToIntf(0.1)); //back to normal (when collide)
}
else
{
MEM_WriteInt(projectile._zCVob_rigidBody+4, castToIntf(FREEAIM_PROJECTILE_ACCELERATION));
};
if (!FREEAIM_REUSE_PROJECTILES) { return; }; // Normal projectile handling
// If the projectile stopped moving (and did not hit npc)
if (MEM_ReadInt(arrowAI+56) != -1073741824) && !(projectile._zCVob_bitfield[0] & zCVob_bitfield0_physicsEnabled) {
if (FF_ActiveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody))) {
FF_RemoveData(freeAimDropProjectile, _@(projectile._zCVob_rigidBody)); };
if (Hlp_StrCmp(projectile.effect, FREEAIM_TRAIL_FX)) { // Remove trail strip fx
const int call2 = 0;
if (CALL_Begin(call2)) {
CALL__thiscall(_@(projectilePtr), oCItem__RemoveEffect);
call2 = CALL_End();
};
};
var C_Npc emptyNpc; emptyNpc = MEM_NullToInst();
// Call customized function
MEM_PushIntParam(projectile.instanz);
MEM_PushInstParam(emptyNpc);
MEM_Call(freeAimGetUsedProjectileInstance); // freeAimGetUsedProjectileInstance(projectile.instanz, emptyNpc);
var int projInst; projInst = MEM_PopIntResult();
if (projInst > 0) { // Will be -1 on invalid item
if (projInst != projectile.instanz) { // Only change the instance if different
const int call3 = 0; const int one = 1;
if (CALL_Begin(call3)) {
CALL_IntParam(_@(one)); // Amount
CALL_PtrParam(_@(projInst)); // Instance ID
CALL__thiscall(_@(projectilePtr), oCItem__InitByScript);
call3 = CALL_End();
};
};
projectile.flags = projectile.flags &~ ITEM_NFOCUS; // Focusable
MEM_WriteInt(arrowAI+56, FLOATONE); // oCAIArrow.lifeTime // Set high lifetime to ensure item visibility
MEM_WriteInt(removePtr, 0); // Do not remove vob on AI destruction
MEM_WriteInt(ESP+8, _@(FREEAIM_ARROWAI_REDIRECT)); // Divert the actual "return" value
};
} else if (MEM_ReadInt(arrowAI+56) == -1073741824) { // Marked as positive hit on npc: do not keep alive
MEM_WriteInt(arrowAI+56, FLOATNULL); // oCAIArrow.lifeTime
};
};
And global Const:
const float FREEAIM_PROJECTILE_ACCELERATION = 0.15; // Add by @Siemekk. How fast is projectile.
mud-freak
15.12.2016, 08:34
Thank you for the code. I looked at it and will integrate it into the repo on github. However, I will change it a little bit, because I think there is a more efficient way to do it and I will not use FREEAIM_PROJECTILE_ACCELERATION, but a function to allow dynamic definition of the acceleration instead of one fixed acceleration for all weapons, talent values, draw force values, etc. I don't know when I will do that. (See EDIT below.)
For now I noticed a minor mistake in your code. I think you meant to do it this way:
func void freeAimWatchProjectile() {
...
if (!projectile._zCVob_rigidBody) { return; }; // zCRigidBody* might not exist the first time
// Reset projectile gravity (zCRigidBody.gravity) after collision (oCAIArrow.collision)
if (MEM_ReadInt(arrowAI+52)) { // Reset projectile gravity and acceleration after collision (oCAIArrow.collision)
MEM_WriteInt(projectile._zCVob_rigidBody+236, FLOATONE); // zCRigidBody.gravity
MEM_WriteInt(projectile._zCVob_rigidBody+4, castToIntf(0.1)); // zCRigidBody.bMass
} else {
MEM_WriteInt(projectile._zCVob_rigidBody+4, castToIntf(FREEAIM_PROJECTILE_ACCELERATION)); // zCRigidBody.bMass
};
if (!FREEAIM_REUSE_PROJECTILES) { return; }; // Normal projectile handling
// If the projectile stopped moving (and did not hit npc)
...
};
EDIT: I looked into it and what you are doing is changing the mass of the projectile, not its velocity. These things are related, of course. That's why you see the desired effect. But because of that, it is not possible to assign separate velocities to individual projectiles. The mass cannot be set when first setting up the projectile, because it is relative. (I assume you noticed that, and that's why you changed your code to set the mass at every frame instead of in the function freeAimSetupProjectile.)
What I am trying to say: Your code works, if you are okay with changing the velocity of all projectiles with no chance of setting individual velocities (based on weapon stats, draw force, etc.). Since I don't really see a point in this, I won't integrate your changes into the scripts in the repo. Someone who wants to use it anyways, can, of course, add the lines of code you provided by themselves. And that is what it's all about: personal preference.
Where you have a code of distance of fly arrow? I have crazy idea, but i don't know where you save this code ;)
Have your read the README (https://github.com/szapp/g2freeAim/blob/master/README.md#customization) and read through freeAim/config.d (https://github.com/szapp/g2freeAim/blob/v0.1.1/_work/data/Scripts/Content/freeAim/config.d)? I strongly recommend doing that.
The function freeAimGetReticleRanged (https://github.com/szapp/g2freeAim/blob/0caf5e8ff1d18f945f71e899831177b3d9cdd489/_work/data/Scripts/Content/freeAim/config.d#L121-L142) is provided with the current distance to the next obstacle (var int dist) at every point in time while aiming.
I don't really understand what you want. Please explain what exactly you are looking for, maybe you can explain that crazy idea you speak of. Then it's easier to help.
mud-freak
07.01.2017, 19:45
Ich habe jetzt mal die letzten Commits, die schon eine Weile auf Github lagen, in ein nächstes Release gesteckt. Es sind nur kleine Fixes und Anpassungen.
v0.1.2 - 2017-01-07 20:05:
Apply screen center fix to hit marker (config)
Fix collision for materials without texture
Fix bbox check for critical hits
Add FAQ to README
Das Setup kann wie immer einfach drüber installiert werden.
gladi1994
19.01.2017, 16:26
Hallo Mud-Freak §wink,
das ist echt eine Hammer-Erweiterung, die du da entworfen hast! Da hast du dir echt riesigen Respekt und Dank verdient! :gratz
Und darüber hinaus hast du so ein wahnsinnig einfaches Setup erstellt, die Integration in "mein" kleines Modprojekt hat keine 10 Minuten gedauert, obwohl ich im Thema Modding nicht so bewandert bin. Super kommentiert und beschrieben und schönes Setup, einfach toll.
Jetzt teste ich noch einmal mit einem umfangreichen Spieldurchgang, aber bisher siehts super aus. ;)
Vielen Dank für diese tolle Erweiterung! :)
Liebe Grüße,
Gladi
gladi1994
20.01.2017, 15:20
Ich bins nochmal §wink
Also ich hab jetzt eine ganze Weile alles mögliche rumprobiert. Hier mal meine Eindrücke:
Bogen und Armbrust klappten bei mir bisher zu 100% einwandfrei, Streuung ist vorhanden, Pfeile gehen ab und zu kaputt, man kann sie wieder aufsammeln usw. Auch das Problem, von dem ich hier irgendwo gelesen hatte, dass Pfeile bei sehr nahem Ziel ab und zu nach oben wegfliegen, trat bei mir noch überhaupt nicht auf. (Oder wurde das schon gefixt?) Ich hab die Skripte, so wie sie waren, eingebunden und nichts daran verändert.
Allerdings habe ich bei Zaubern zwei ("relativ nervige kleine Schönheits-") Fehler gefunden, die sogar ziemlich häufig auftreten. Und zwar fliegt einer von fünf Zaubern (das Mathegenie muss kurz rechnen - etwa 20% :D) nicht ins Ziel. Man sieht ganz kurz den Zauber (z.B. einen Blitzschlag oder Feuerball) aus der Hand des SC gehen, der verschwindet aber sofort und bringt auch keinen Effekt. Möglicherweise fliegt er nach oben weg, so wie es bei den Pfeilen gewesen sein soll? Ich weiß es nicht, vielleicht kann ich ein Video machen und dir mal schicken oder so? Schwer zu erklären... :dnuhr:
Und zweitens ist mir aufgefallen, dass man mit Zaubern in Nahkampfreichweite nicht mehr treffen kann, zumindest wüsste ich nicht wie. :dnuhr: Ein Wolf steht vor mir und greift mich an und mein Blitzschlag "trifft" ihn einfach nicht mehr. Oder bin ich da nur zu doof zu? ^^
Soviel erstmal zu meinen Eindrücken, ansonsten macht es echt total viel Spaß, so zu spielen!
Vielleicht kannst du ja mit meinem Bericht was anfangen?
Liebe Grüße,
Gladi :gratz
mud-freak
21.01.2017, 16:49
Danke für das ausgiebige Feedback! Das ist definitiv willkommen. Mir sind beide Probleme nicht bekannt. Tatsächlich wäre ich dafür dankbar, wenn du von beiden ein Video machen könntest, wenn das für dich nicht all zu viel Arbeit macht.
Dass die Pfeile bei zu nahem Ziel bei nach oben weg fliegen, ist (noch) nicht gefixt. Aber es ist ein gutes Zeichen, dass das bei dir (gar) nicht auftritt.
Eine Frage nebenbei, weil du dich scheinbar schon ein bisschen damit auseinander gesetzt hast, sind die Anpassungsmöglichkeiten in der freeAim/config.d leicht zu verstehen und was damit möglich ist?
gladi1994
22.01.2017, 13:04
Hallo Mud-Freak,
freut mich, dass dich mein Feedback freut. ;)
Also ich hab jetzt mal zwei Aufnahmen gemacht.
Die Erste zeigt das Problem (welches zumindest ich habe) mit den nicht am Ziel ankommenden Zaubern: (wobei ich inzwischen glaube, dass das davon abhängig ist wo man steht und wo man hinzielt und nicht zufallsbedingt einfach so passiert. Sieht manchmal wie ein unsichtbares Hindernis aus, aber ich kann mich auch total täuschen. :dnuhr: Im Minental passiert mir das jedenfalls deutlich öfter.)
http://ul.to/u7ssc2os
Die Zweite zeigt, dass Zauber im Nahkampf oft wirkungslos sind: (Auch hier passiert mir das bei Wölfen und Wargen nicht mehr so häufig, wie ich es in Erinnerung hatte, aber es passiert. Und gegen größere Gegner wie Orks passiert es fast durchgehend. Hängt vermutlich mit der Größe der Kollisionsboxen zusammen? Aber auch hier gilt: Ich bin Laie und habe nicht so wirklich Ahnung ^^ Sorry)
http://ul.to/n1emir92
Ich hoffe, du kannst mit den Aufnahmen was anfangen? Sie sind leider etwas groß geworden, habe sie deshalb mal bei Uploaded hochgeladen, ich hoffe das passt dir?
Ich freu mich, von dir zu lesen! :gratz
Bis dann, Gladi
Edit: Mit der config.d habe ich mich wie gesagt bisher noch gar nicht groß auseinandergesetzt. Aber ich hab sie mir jetzt mal angesehen und zusammen mit der ReadMe und deinen Kommentaren in der Datei selbst sieht das alles sehr benutzerfreundlich für mich aus. Werde mir das auf jeden Fall nochmal ansehen! So wie ich das sehe, kann ja alles direkt dort eingestellt werden. Sehr komfortabel. ;)
Edit#2: Sollte ich die Videos besser bei Youtube hochladen?
mud-freak
22.01.2017, 23:17
Die Erste zeigt das Problem (welches zumindest ich habe) mit den nicht am Ziel ankommenden Zaubern: (wobei ich inzwischen glaube, dass das davon abhängig ist wo man steht und wo man hinzielt und nicht zufallsbedingt einfach so passiert. Sieht manchmal wie ein unsichtbares Hindernis aus, aber ich kann mich auch total täuschen. :dnuhr: Im Minental passiert mir das jedenfalls deutlich öfter.)
Vielen Dank für das Video. Da war es gut zu erkennen. Wie bei dem zweiten Problem scheinst du mit der Kollisionbox richtig zu liegen. Das sieht man beim Baum am Anfang des Videos sehr gut. Wenn du dir diese ikonische rote Boundingbox um den Baum vorstellst, die den kleinsten Quader darstellt, der alle Punkte des Vobs einschliesst, trifft der Blitz genau auf diese (wegen der Baumkrone) und kollidiert also offiziell mit dem Baum. Natürlich nicht sehr schön.
Wie du vielleicht bemerkt hast, geschieht das nur mit Zaubern aber (evlt.) nicht mit Pfeilen/Bolzen. Das liegt an deren unterschiedlichem Kollisionsverhalten (Pfeile sind "schlauer"). Mich würde interessieren, ob das gleiche passiert, wenn du freies Zielen an der selben Stelle im Menu deaktivierst. Es ist natürlich etwas eingeschränkter dann mit dem Zauber zu "zielen". Ich würde schätzen, es passiert genau das gleiche, nur ist es nie aufgefallen, weil man ja mit dem klassischen Auto-Aim für gewöhnlich Gegner anvisiert hat. Ich kann das leider gerade nicht testen, weil ich kein Gothic installiert habe. Wenn du das mal probieren willst, würde ich die gleich Stelle vorschlagen (der Baum am Anfang des Videos). Der ist schön gross und da sollte es eindeutig sein.
Dass das ganze auch am Pass passiert, schreibe ich der Neigung des Bodens und möglichen herausragenden Boundingboxen der Steine oder Gräser zu. Dass das gerade im Minental besonders aufzutreten scheint, ist natürlich fragwürdig.
Wenn ich mit der Vermutung richtig liege, kann ich daran so leider nichts ändern.
Die Zweite zeigt, dass Zauber im Nahkampf oft wirkungslos sind: (Auch hier passiert mir das bei Wölfen und Wargen nicht mehr so häufig, wie ich es in Erinnerung hatte, aber es passiert. Und gegen größere Gegner wie Orks passiert es fast durchgehend. Hängt vermutlich mit der Größe der Kollisionsboxen zusammen? Aber auch hier gilt: Ich bin Laie und habe nicht so wirklich Ahnung ^^ Sorry)
Dazu konnte ich das Video noch nicht ganz gucken, da uploaded.net eine sehr flache Bandbreite für Gäste bereithält und ich nach dem ersten Video einige Stunden warten musste bevor ich wieder etwas herunterladen durfte. Dann ist der Download mittendrin abgebrochen. Aber die Hälfte des Video habe ich gesehen.
Das Problem kommt mir doch bekannt vor. Ich wusste auch woran das genau liegt (weiss es jetzt aber nicht mehr so genau). Ich hatte es dann zu Seite gelegt, weil ich es nur bei Menschen getestet hatte und da klappte es glaub ich wenn man etwas tiefer zielte. Bei dem Ork im Video scheint das ja nicht zu helfen. Ich hätte aber auf die schnelle eine Vermutung woran es liegen könnte und auch einen möglichen Fix. Wenn du möchtest kannst du ihn einmal ausprobieren:
In der config.d gibt es ganz unten die Funktion freeAimShiftAimVob (https://github.com/szapp/g2freeAim/blob/639936be25d30f9f458b3105c85213f509cf9021/_work/data/Scripts/Content/freeAim/config.d#L340-L343). Die kannst du einmal so ändern (100 anstatt der 0 zurückgeben):
/* Shift the aimvob along the camera out vector for spells (if you don't know what this is, you don't need it) */
func int freeAimShiftAimVob(var int spellID) {
// if (spellID == ...) { return -100; }; // Push the aim vob 100 cm away from any wall
return 100; 0;
};
Was das macht: Wenn der Ork zu nah am Spielermodell ist, ist der von G2 Free Aim ermittelte Zielpunkt nicht weit genug vom Abflugpunkt (Hand) entfernt, bzw. die Boundingbox des Orks und der Spielermodells kreuzen sich. Die Funktion oben war ein Zusatz, den ich eingebaut habe um diesen Zielpunkt manuell (pro Zauber; und nur für Zauber) zu verschieben. Das ist z.B. für Blink nötig damit man sich nicht in, sondern vor die nächstgelegene Wand teleportiert. Dort wird der Zielpunkt also etwas in Richtung des Spielers verschoben. Was die Änderung oben tut ist das Gegenteil. Wir verschieben der Zielpunkt etwas weiter (100cm), sodass die Kollision mit dem Ork vielleicht doch noch zu Stande kommt. Ob das funktioniert kann ich nicht sagen (weil ich die genaue Ursache des Problems nicht kenne), aber du könntest es einmal ausprobieren. Die kleine Änderung (+ Skripte parsen) ist klein genug, dass du damit deine Speicherstände fortsetzen kannst (kein neues Spiel nötig).
Zu dem Testen wo denn nun dieser Zielpunkt gesetzt wird, kannst du übrigens über die Konsole mit folgendem Befehl eine kleine Hilfe an- und ausschalten.
debug freeaim traceray
Edit: Mit der config.d habe ich mich wie gesagt bisher noch gar nicht groß auseinandergesetzt. Aber ich hab sie mir jetzt mal angesehen und zusammen mit der ReadMe und deinen Kommentaren in der Datei selbst sieht das alles sehr benutzerfreundlich für mich aus. Werde mir das auf jeden Fall nochmal ansehen! So wie ich das sehe, kann ja alles direkt dort eingestellt werden. Sehr komfortabel. ;)
Sehr gut! So soll es sein.
gladi1994
23.01.2017, 09:54
Hallo,
Zu 1.:
Wenn ich automatisches Zielen ausschalte und einfach so durch die Gegend schieße, scheinen die Zauber auch den Baum zu treffen. Doch sobald ich einen Ork dahinter anvisiere, geht der Zauber in sein Ziel (vorausgesetzt, der Ork bleibt auf die große Distanz an Ort und Stelle stehen und bewegt sich nicht weg^^).
Was mir auch aufgefallen ist: Wenn ich mit freiem Zielen auf einen Gegner ziele, sodass er im Fokus steht und sein Name und die Gesundheitsleiste oben erscheinen, kommt der Zauber auch beim Gegner an. Und er wird dann so geschossen, wie als wenn ich gar nicht frei zielen würde. Beispiel: Wenn ich auf den Kopf oder noch weiter nach oben rechts ziele (Hauptsache der Gegner ist noch im Fokus), fliegt der Zauber, wie als wenn ich ohne freies Zielen spielen würde, genau in den Körper des Gegners (quasi genau auf die Mitte der Box oder so). Sorry für die umständliche Erklärung, ist ziemlich schwierig.
Wäre es denn irgendwie möglich das "schlaue" Verhalten der Pfeile / Bolzen auch auf Zauber zu übertragen?
Zu 2.:
Was du gesehen hast sollte ausreichen, viel mehr kommt da auch nicht. ;) Falls noch Videos benötigt werden, lade ich sie dann einfach bei Youtube hoch, an das Downloadlimit hab ich nämlich gar nicht gedacht...
Ich habe mal geändert, was du mir vorgeschlagen hast. Skripte dann geparst und getestet, aber es funktionierte leider trotzdem nicht. Ich hab auch verstanden, was damit geändert wird, aber anscheinend liegt es doch nicht daran? Oder sind 100cm möglicherweise zu wenig?
Und dann hätte ich mal noch eine "kleine" andere Frage :grinundwe:
Es betrifft wieder nur die Zauber, denn das Abschießen von Pfeilen / Bolzen beinhaltet keine lange Animation vorher. Da drückt man (standardmäßig) W, wenn anvisiert ist, und der Pfeil fliegt dahin los, wo hingezielt wurde.
Wenn man aber bei einigen Zaubern W drückt (auch hier dient wieder der Blitzschlag als gutes Beispiel), wird eine kleine Zauberanimation ausgeführt und erst danach fliegt der Zauber los.
Wenn man nun, nachdem man schon W gedrückt und die Animation eingeleitet hat, aber nochmal seine Zielrichtung leicht nachkorrigiert, fliegt der Zauber trotzdem in die ursprünglich eingezielte Richtung. Kann man das eventuell irgendwo umstellen? (Z.B. in der config) Oder wäre da der Aufwand für dich oder auch für mich viel zu groß / wäre das überhaupt möglich?
Ich hoffe, du weißt, was ich meine. Sonst lad ich dazu auch einfach mal noch ein Video hoch. :)
Lange Rede, nicht so viel Sinn; ich freu mich erneut auf Antwort von dir! :)
Alles Gute, Gladi
mud-freak
23.01.2017, 12:27
Was mir auch aufgefallen ist: Wenn ich mit freiem Zielen auf einen Gegner ziele, sodass er im Fokus steht und sein Name und die Gesundheitsleiste oben erscheinen, kommt der Zauber auch beim Gegner an. Und er wird dann so geschossen, wie als wenn ich gar nicht frei zielen würde. Beispiel: Wenn ich auf den Kopf oder noch weiter nach oben rechts ziele (Hauptsache der Gegner ist noch im Fokus), fliegt der Zauber, wie als wenn ich ohne freies Zielen spielen würde, genau in den Körper des Gegners (quasi genau auf die Mitte der Box oder so). Sorry für die umständliche Erklärung, ist ziemlich schwierig.
Keine Sorge ich weiss was du meinst. Das habe ich extra so gemacht, weil Zauber einen Target-Bone im Opfer ansteuern können. Die meisten fliegen zentral auf den Körper (Bip01), es besteht aber die Möglichkeit, dass ein Zauber etwas mit dem Kopf des Gegners anstellt oder immer auf dessen rechten Fuss fliegen soll. Das muss gewährleistet bleiben, weil sonst manche Zauber nicht mehr das machen was sie sollen. Sobald man also einen Gegner im Fokus hat (egal ob das Fadenkreuz ein paar cm abweicht), fliegt der Zauber dorthin, wo er laut seiner Definition landen soll. Das ganze kann also wie eine Art "Aim Assist" wirken, lässt sich aber nicht ändern ohne die Definition von Zaubern einzuschränken. Zusätzlich gewährleistet diese etwas gelenkte Flugbahn auch verlässlicheres Treffen von Zaubern, da je nach Effekt des Zaubers die Kollision bestimmt wird.
Wäre es denn irgendwie möglich das "schlaue" Verhalten der Pfeile / Bolzen auch auf Zauber zu übertragen?
Das geht leider nicht, da Effekte grundlegend ein anderes Kollisionsverhalten haben. Z.B. ist ja ein Pfeil relativ klein und eine Kollision lässt sich daher sehr präzise bestimmen. Eine grosse Effektwolke wie beim Feuerball muss die Kollision von jedem Partikel abfragen (vielleicht wird hier aber auch nur die Boundingbox des Effektes genommen) und die Oberfläche ist dementsprechend grösser. Deshalb überprüfen Effekte die Boundingbox von Hindernissen etwas gröber als Pfeile.
Ändern kann ich daran nichts.
Ich habe mal geändert, was du mir vorgeschlagen hast. Skripte dann geparst und getestet, aber es funktionierte leider trotzdem nicht. Ich hab auch verstanden, was damit geändert wird, aber anscheinend liegt es doch nicht daran? Oder sind 100cm möglicherweise zu wenig?
Du kannst es mal mit 200 oder mehr ausprobieren (obwohl darunter die Zielgenauigkeit zwischen Auftreffen des Zaubers und der Position des Fadenkreuzes leidet) - einfach für Testzwecke. Aber ich gehe davon aus, dass dieser Ansatz wohl nicht der Richtige war. Mit dem vorgeschlagenen Konsolenbefehl vom letzten Post könntest du mal schauen, wo genau der Zauber auftreffen hätte sollen. Du könntest mittels Konsole die Bbox vom Ork anzeigen lassen (weiss den Befehl gerade nicht auswendig; irgendwas wie "fbbox" wenn du den Ork anvisierst) und dann mit F9 die Zeit einfrieren sobald du einen Zauber wirfst, damit der Ork und dessen Bbox bleiben wo sie sind, so wie auch die Debug-anzeige vom Zielpunkt des Zaubers. Dann kannst du mit F6 etwas umherfliegen und vergleichen, ob die beiden BBoxen ineinanderliegen = der Zauber getroffen haben müsste. Das schreibe ich deshalb so genau, weil das eigentlich meine Aufgabe ist, aber ich weiss noch nicht wann ich dazu komme. Wenn du es also selbst probieren möchtest, kannst du es machen, ansonsten schau ich mir das demnächst mal an.
Wenn man nun, nachdem man schon W gedrückt und die Animation eingeleitet hat, aber nochmal seine Zielrichtung leicht nachkorrigiert, fliegt der Zauber trotzdem in die ursprünglich eingezielte Richtung. Kann man das eventuell irgendwo umstellen? (Z.B. in der config) Oder wäre da der Aufwand für dich oder auch für mich viel zu groß / wäre das überhaupt möglich?
Ich hoffe, du weißt, was ich meine. Sonst lad ich dazu auch einfach mal noch ein Video hoch. :)
Ein Video brauchst du mir dafür nicht schicken, ich weiss was du meinst. Eine Einstellung dafür gibt es nicht. Ich fand das beim Entwickeln auch schon etwas unschön, hab daran aber nichts geändert (den Grund dafür weiss ich schon nicht mehr - vielleicht ging das nicht anders). Wenn ich die Zeit dafür habe, werde ich mir das auch noch einmal anschauen.
Nochmals danke für all die Fragen und Gedanken. Da merke ich erst, was ich alles nicht dazu geschrieben habe und was beim Benutzen nicht offensichtlich ist. Sicher können andere auch von den Erklärungen hier profitieren.
mud-freak
24.01.2017, 21:27
Ich hatte jetzt etwas Zeit die Sachen einmal zu testen. Die Probleme jeweils noch mal als Zitate (damit Mitleser wissen worum es geht) mit Antwort.
Und zweitens ist mir aufgefallen, dass man mit Zaubern in Nahkampfreichweite nicht mehr treffen kann, zumindest wüsste ich nicht wie. :dnuhr: Ein Wolf steht vor mir und greift mich an und mein Blitzschlag "trifft" ihn einfach nicht mehr.
Die Zweite zeigt, dass Zauber im Nahkampf oft wirkungslos sind: (Auch hier passiert mir das bei Wölfen und Wargen nicht mehr so häufig, wie ich es in Erinnerung hatte, aber es passiert. Und gegen größere Gegner wie Orks passiert es fast durchgehend. Hängt vermutlich mit der Größe der Kollisionsboxen zusammen? [...])
Es hat wie vermutet was mit den Boundingboxen zu tun: Bei grossen Gegnern kann es vorkommen, dass sich das Spielermodel in der Boundingbox des Gegners befindet. Ich habe jetzt viel herum getestet und hatte eigentlich eine Lösung dafür. Als diese immer noch nicht klappte, habe ich gemerkt, dass dieses Verhalten auch ohne freies Zielen auftritt: Selbst wenn man mit seinem Feuerpfeil den Ork anvisiert und er sich sichtbar im Fokus befindet, kann man ihn nicht treffen, wenn er zu nah ist. Das könntest du zum Sichergehen vielleicht selbst noch einmal ohne freies Zielen austesten.
Hier ein kleiner Screenshot: Das Spielermodel ist "im" Ork. Die orange Boundingbox ist die des Orks, die grüne zeigt den ersten Schnittpunkt und die grüne Linie die Schussbahn. Selbst wenn ich den Ork als Ziel setze (wie das ohne freies Zielen der Fall ist), wird er nicht getroffen.
Da es sich also scheinbar um ein schon im originalen Gothic bestehendes Problem handelt, werde (und kann) ich es nicht beheben.
https://upload.worldofplayers.de/files10/miss_01.png
Wenn man nun, nachdem man schon W gedrückt und die Animation eingeleitet hat, aber nochmal seine Zielrichtung leicht nachkorrigiert, fliegt der Zauber trotzdem in die ursprünglich eingezielte Richtung. Kann man das eventuell irgendwo umstellen? (Z.B. in der config) Oder wäre da der Aufwand für dich oder auch für mich viel zu groß / wäre das überhaupt möglich?
Das habe ich mir jetzt auch noch einmal angeschaut und kann dir jetzt den Grund sagen, warum das so ist und ich es nicht ändern kann: Bei Zaubern wird kontinuierlich das Ziel erfasst (anders als beim Fernkampf). Diese Zielerfassung wird jedes mal von G2 Free Aim überschrieben. Scheinbar wird aber nach Abfeuern des Zaubers während der Animation keine weitere solcher Erfassungen unternommen, sodass mir da die Hände gebunden sind. Denn dann wird der Zauber den visuellen Effekten übergeben und die sind unfassbar komplex. Anders ausgedrückt: das Ziel wird beim Drücken der Aktionstaste bestimmt, nicht beim Verlassen des Zaubers von der Hand.
Und zwar fliegt einer von fünf Zaubern (das Mathegenie muss kurz rechnen - etwa 20% :D) nicht ins Ziel. Man sieht ganz kurz den Zauber (z.B. einen Blitzschlag oder Feuerball) aus der Hand des SC gehen, der verschwindet aber sofort und bringt auch keinen Effekt. Möglicherweise fliegt er nach oben weg, so wie es bei den Pfeilen gewesen sein soll?
Die Erste zeigt das Problem (welches zumindest ich habe) mit den nicht am Ziel ankommenden Zaubern: (wobei ich inzwischen glaube, dass das davon abhängig ist wo man steht und wo man hinzielt und nicht zufallsbedingt einfach so passiert. Sieht manchmal wie ein unsichtbares Hindernis aus, aber ich kann mich auch total täuschen. :dnuhr: Im Minental passiert mir das jedenfalls deutlich öfter.)
EDIT: [Falsche Annahmen gelöscht]
Vielen Dank für deine Funde! Falls dir noch mehr ins Auge fällt, freue ich mich auf weiteres!
TL;DR
Problem (kein Treffer im Nahkampf): Ist schon ein Bug im originalen Gothic (lässt sich nicht ändern)
Problem (abflugzeitpunkt des Zaubers): Bleibt bei einem Schönheitsfehler - man gewöhnt sich beim Spielen aber daran
Problem (zu kurz fliegende Zauber): [Unfug gelöscht] Das hat nichts mit statischen Vobs zu tun. Das Problem ist mittlerweile behoben
Milky-Way
24.01.2017, 22:05
TL;DR
Problem (kein Treffer im Nahkampf): Ist schon ein Bug im originalen Gothic (lässt sich nicht ändern)
Problem (abflugzeitpunkt des Zaubers): Bleibt bei einem Schönheitsfehler - man gewöhnt sich beim Spielen aber daran
Problem (zu kurz fliegende Zauber): Die Map vom Minental ist schlecht bespacert: Damit G2 Free Aim vernünftig laufen kann, müssen statische Vobs auch mit cdStatic = TRUE versehen sein.
Der letzte Punkt erscheint mir problematisch. cdStatic bedeutet, dass das Objekt Kollision mit dem Weltmesh hat, ich kann es dann also nicht ins Weltmesh reinschieben und habe daher schwebende Objekte. Meinst du vielleicht etwas anderes?
mud-freak
24.01.2017, 22:20
Der letzte Punkt erscheint mir problematisch. cdStatic bedeutet, dass das Objekt Kollision mit dem Weltmesh hat, ich kann es dann also nicht ins Weltmesh reinschieben und habe daher schwebende Objekte. Meinst du vielleicht etwas anderes?
Da hab ich über die Bedeutung gerade komplett hinweg gesehen. Klar dürfen Steine u.Ä. nicht mit der statischen Welt kollidieren, da hast du recht. Darüber habe ich nicht nachgedacht.
An der Aussage, dass das Minental ungünstig bespacert ist halte ich aber trotzdem fest. Anstatt dieser zahlreichen Steingruppen wäre eine Integration ins Levelmesh schöner gewesen. Denn nicht nur G2 Free Aim, sondern jeglicher TraceRay leidet darunter. Dass das im Normalverlauf des Originalspiels nicht auffällt wundert mich.
Wenn man mit dem Konsolenbefehl ZTOGGLE VOBBOX um die Burg im Minental wandert, sieht man kaum noch etwas vor unzähligen grössenteils ungefüllten Boundingboxes. Ich hab jetzt nicht geschaut, ob das in der NewWorld auch so extrem der Fall ist - aber ich gehe nicht davon aus, weil ich meine Tests in der Entwicklung von G2 Free Aim alle um Khorinis herum unternommen habe und mir so etwas nie aufgefallen ist. Ist es "normal"/geläufig eine Map dermassen mit Vobs zuzuklatschen wie im Minental? Alles unsinn.
Milky-Way
24.01.2017, 22:40
Ist es "normal"/geläufig eine Map dermassen mit Vobs zuzuklatschen wie im Minental?
Bei vielen Mods dürfte das ebenfalls so sein. Steine, Bäume, Tische, Regale, Betten... sind meist als Vobs gesetzt mit cdStatic = false.
mud-freak
24.01.2017, 22:42
Bei vielen Mods dürfte das ebenfalls so sein. Steine, Bäume, Tische, Regale, Betten... sind meist als Vobs gesetzt mit cdStatic = false.
Ich werd die Tage noch einmal schauen, ob wirklich diese Eigenschaft Probleme verursacht.
mud-freak
25.01.2017, 07:07
Ich kann den Fehler derzeit plötzlich nicht mehr reproduzieren. Ein vermeintliches Problem auf die cdStatic=FALSE Vobs zu schieben war zu vorschnell. Ich schreibe, wenn ich es besser eingrenzen kann.
gladi1994
25.01.2017, 16:28
Hallo Mud-Freak,
ich hatte die letzten beiden Tage leider keine Zeit und meinen PC nicht in der Nähe, deshalb konnte ich nicht testen... Schön zu sehen, dass dich das Thema scheinbar immernoch so sehr packt. :)
Wenn ich dir vielleicht irgendwie Arbeit abnehmen kann, sags mir einfach!
Ich kann den Fehler derzeit plötzlich nicht mehr reproduzieren. Ein vermeintliches Problem auf die cdStatic=FALSE Vobs zu schieben war zu vorschnell. Ich schreibe, wenn ich es besser eingrenzen kann.
Heißt das, es besteht noch Hoffnung, dass das mysteriöse Verschwinden der Zauber doch noch aufgeklärt wird? :D
Bis dann, Gladi
mud-freak
25.01.2017, 17:00
Wenn ich dir vielleicht irgendwie Arbeit abnehmen kann, sags mir einfach!
Heißt das, es besteht noch Hoffnung, dass das mysteriöse Verschwinden der Zauber doch noch aufgeklärt wird? :D
Ich denke schon. Es wäre sonst zu unzufrieden stellend. Ich werde mein bestes geben, der Sache auf den Grund zu gehen - vorausgesetzt es lässt sich innerhalb kürzerer Zeit aufklären (Zeit ist hier ein grosser Faktor). Glücklicherweise sind nur Zauber betroffen und man kann ja über die config.d das freies Zielen für diese ausschalten, während es im Fernkampf problemlos klappt (siehe FREEAIM_DISABLE_SPELLS (https://github.com/szapp/g2freeAim/blob/639936be25d30f9f458b3105c85213f509cf9021/_work/data/Scripts/Content/freeAim/config.d#L54)). Das ist fürs erste auch mein Tipp für Skeptiker. EDIT: Das Problem ist mittlerweile sehr vernünftig und verlässlich behoben. Bis zur nächsten Version nach v0.1.2 kann man sich des Fixes schon auf Github (https://github.com/szapp/g2freeAim/blob/cffc54a08f79dc3f533cdf4a1aeabe9d4190f265/_work/data/Scripts/Content/freeAim/_intern.d#L437) bedienen und in der Datei freeAim\_intern.d die Zeile 436 korrigieren.
Falls ich bei Tests o.Ä. Hilfe brauchen kann, werde ich dich anschreiben, danke! Ich habe im Moment nämlich nur begrenzte Möglichkeiten, wie man in dem Screenshot aus Post #122 erkennen kann.
Abuyin Sharidi
02.02.2017, 14:56
You could also make it possible to move while aiming. :P
Like in Gothic 3, you can still aim and move slowly to right/left/forward/backward. ^^
Would be pretty fun to play with a bow/crossbow then.
mud-freak
02.02.2017, 15:34
You could also make it possible to move while aiming. :P
Like in Gothic 3, you can still aim and move slowly to right/left/forward/backward. ^^
Would be pretty fun to play with a bow/crossbow then.
Yes, that was actually a pretty big part of this script. I worked a lot on it, but eventually threw it out, as it was not working sufficiently good enough. You can read about it/try it here:
#13 Implement strafing (https://github.com/szapp/g2freeAim/issues/13#issuecomment-262215409)
Latest commit in branch 'strafing' (https://github.com/szapp/g2freeAim/commit/cbb03ff15d158af2ed5b8eda4b352d1a0c3c9d77)
Forum post about strafing (bottom half)
TL;DR: With trying to implement it, I reached the engine's limitations. Going beyond didn't seem like a good idea with Deadalus.
If you have another idea how to go about this - other then the attempts mentioned in the links - feel free to share them, or try to implement them.
Abuyin Sharidi
02.02.2017, 16:16
I believe the easiest way of doing that would be disabling the disabling of animation while aiming (simply enabling all animations :P).
The only problem is to find the right function that prevents the animations.
mud-freak
02.02.2017, 16:30
I believe the easiest way of doing that would be disabling the disabling of animation while aiming (simply enabling all animations :P).
The only problem is to find the right function that prevents the animations.
That's not really that simple. There is no such function that prevents animations. It is more of an incapability of the engine to play multiple animations simultaneously, while still reacting to user input to both (player movement and aiming direction). There is a layer system for animations but it doesn't support two independently moving animations of which one actually also moves the player model. This would have to be implemented in to the engine which is way to big for Deadalus.
Abuyin Sharidi
02.02.2017, 16:46
Well... yeah. I forgot it's impossible to play two animations at once. So this is basically impossible.
mud-freak
11.02.2017, 18:52
Heißt das, es besteht noch Hoffnung, dass das mysteriöse Verschwinden der Zauber doch noch aufgeklärt wird? :D
Ich hab nun Zeit gefunden und konnte dem Problem auf den Grund gehen. Das Problem, dass Zauber einfach mitten in der Luft stehen bleiben habe ich behoben. Dabei ist mir noch etwas anderes aufgefallen. Ich konnte nun die Performance beim Zielen optimieren. Das ganze werde ich dann demnächst in ein neues Release packen. Bis dahin, ist der Fix aber schon auf Github (ccd4eaa (https://github.com/szapp/g2freeAim/commit/ccd4eaa7875cea9ce9a7fff892f8bea3631bd2ee) mit genauerer Beschreibung der Fixes). Eine bessere Debugging Visualisierung ist nun auch eingebaut.
Dir, Gladi, vielen Dank. Ohne deinen Fehlerbericht wäre mir der Fehler mit der Performance nie aufgefallen. Da du dich zu dem Fehler mit den stehenbleibenden Zaubern als einziger geäussert hast, könntest du den Fix schon einmal testen. Dazu kannst du einfach die Datei freeAim\_intern.d mit der neuen (https://raw.githubusercontent.com/szapp/g2freeAim/ccd4eaa7875cea9ce9a7fff892f8bea3631bd2ee/_work/data/Scripts/Content/freeAim/_intern.d) ersetzen, bis das neue Release online geht.
EDIT: Ich will hier noch einmal korrigieren, dass das Problem nichts mit statische Vobs zu tun hatte. Das war eine völlig falsche Annahme meinerseits.
EDIT 2: Das Problem mit den nach oben weg fliegenden Pfeilen (siehe Post #90) konnte ich jetzt übrigens auch genauer anschauen, bin aber zu dem Schluss gekommen, dass ich den (selten auftretenden) Fehler nicht beheben kann. EDIT: Mittlerweile gefixt.
http://upload.worldofplayers.de/files10/VJp11Q7QFffreeAim_tracerayExplained.png
I have AST source code of FreeAim. I can't give you this, because creators kill me $§p4
I can give you hint: They're getting distance from 2 arg to 3 arg in this Engine function:
oCAIArrow::SetupAIVob(zCVob*, zCVob*, zCVob*);
float a = 2arg->GetDistanceToVob(3arg);
I have AST source code of FreeAim. I can't give you this, because creators kill me $§p4
I can give you hint: They're getting distance from 2 arg to 3 arg in this Engine function:
oCAIArrow::SetupAIVob(zCVob*, zCVob*, zCVob*);
float a = 2arg->GetDistanceToVob(3arg);
That is... not very helpful. I'd argue (although I don't know the specifics of mud-freaks implementation) that this is not quite an engineering problem. As far as the trace ray is concerned, shooting upwards is exactly what the player wanted to do. To get a better angle, one "only" needs to find a more accurate target location, e.g. the actual polygon the traceray will hit instead of the bounding box.
There are other possible solutions such as lowering the camera angle (so it's more aligned with the arrow) when the supposed target is close. None of these are inherently hard, but it may be quite the task to provide a smooth user experience that has no drawbacks.
gladi1994
11.02.2017, 22:30
Ich hab nun Zeit gefunden und konnte dem Problem auf den Grund gehen. Das Problem, dass Zauber einfach mitten in der Luft stehen bleiben habe ich behoben. Dabei ist mir noch etwas anderes aufgefallen. Ich konnte nun die Performance beim Zielen optimieren. Das ganze werde ich dann demnächst in ein neues Release packen. Bis dahin, ist der Fix aber schon auf Github (ccd4eaa (https://github.com/szapp/g2freeAim/commit/ccd4eaa7875cea9ce9a7fff892f8bea3631bd2ee) mit genauerer Beschreibung der Fixes). Eine bessere Debugging Visualisierung ist nun auch eingebaut.
Dir, Gladi, vielen Dank. Ohne deinen Fehlerbericht wäre mir der Fehler mit der Performance nie aufgefallen. Da du dich zu dem Fehler mit den stehenbleibenden Zaubern als einziger geäussert hast, könntest du den Fix schon einmal testen. Dazu kannst du einfach die Datei freeAim\_intern.d mit der neuen (https://raw.githubusercontent.com/szapp/g2freeAim/ccd4eaa7875cea9ce9a7fff892f8bea3631bd2ee/_work/data/Scripts/Content/freeAim/_intern.d) ersetzen, bis das neue Release online geht.
EDIT: Ich will hier noch einmal korrigieren, dass das Problem nichts mit statische Vobs zu tun hatte. Das war eine völlig falsche Annahme meinerseits.
EDIT 2: Das Problem mit den nach oben weg fliegenden Pfeilen (siehe Post #90) konnte ich jetzt übrigens auch genauer anschauen, bin aber zu dem Schluss gekommen, dass ich den (selten auftretenden) Fehler nicht beheben kann.
Hallo Mud-Freak §wink
Das ist eine richtig tolle Nachricht und ich kanns kaum erwarten, das zu testen! Ich brauche allerdings noch ein bisschen Zeit, da ich auch gerade an einem kleinen Problemchen sitze. Aber das steht auf jeden Fall auf meiner ToDo Liste! :)
Vielen Dank für den Fix! :gratz
mud-freak
12.02.2017, 15:46
I have AST source code of FreeAim. I can't give you this, because creators kill me
I can give you hint: They're getting distance from 2 arg to 3 arg in this Engine function:
oCAIArrow::SetupAIVob(zCVob*, zCVob*, zCVob*);
float a = 2arg->GetDistanceToVob(3arg);
I also don't understand what you are trying to tell me here. I am well aware that I can measure the distance between shooter and target (which I actually already do in my scripts). But this is completely unrelated to any issue here. I haven't done a great job in explaining why a trace ray is necessary and I should do this now. Here I will roughly explain how the free aiming works in this script (I will do this in English so everybody has a better chance to understand):
Gothic shoots arrows by setting up a starting point and a target point in the world. In the vanilla Gothic, the target point is always an npc (except if none is in focus). So the general idea behind free aiming is quite simple: Just intercept the definition of the target point and set it far away along the camera viewing angle, such that the arrow will fly in that direction. Now, anyone who ever thought about how shooter games work, might have realized that a problem arises with this simple approach.
There is a discrepancy between flight path of the arrow and the camera viewing angle. In other words, the arrow will not fly from the camera, but from the player model. This means the arrow will not exactly fly where the reticle is on the screen. If you stand close in front of a wall, your shot hits to the right of the reticle. So what is the solution? The target position has to be where the reticle is on the screen. So the target position cannot just be a constant distance from the camera, but depends on the distance of the obstacle the arrow will hit. I deliberately called it "obstacle" because it can be anything (npc, vob, static world). Before the arrow is shot, we need to measure the distance to this obstancle (including collision vobs and excluding any non-collision vobs). Voila: That is what the trace ray is for. It reports the nearest/all intersections along a line with a start point and a direction.
In this script here there are three kinds of trace rays.
(1.) The first one is what I just described, to determining the target position. It is called only once: at time of shooting.
(2.) The second one is not of concern here (it is only in effect sometimes to check collisions with npcs) and is inspired of how the engine does it.
(3.) The third one continually measures the aiming distance to offer dynamical reticle adjustments (smaller/bigger, etc).
So, trace rays are no limitation or drawback as Siemekk keeps treating them, but actually a severe (necessary) improvement over the simple method. I couldn't care less how free aiming is implemented in AST, but if its done without trace rays, then it just cannot be accurate.
Grosser Fix
So. Diese Trace rays können verschiedene Eigenschaften ("Flags") haben, um z.B. Vobs oder Wasser zu ignorieren, oder um einen echten Schnittpunkt zurückzugeben anstatt einen Boundingbox-Check, usw. Das sind einige an der Zahl, die ich im Skript alle balancieren musste (manche igonieren Npcs, andere machen es dann wieder zu ungenau) und nicht das zu halten schienen was sie versprachen. So dachte ich - bis heute.
Ich hatte diese Flags seltsamerweise als eine Konstante definiert, und später versehentlich mit anderen Flags überschrieben. Deshalb gab es so viele Probleme. Jetzt sind tatsächlich die richtigen Flags gesetzt und alles klappt wunderbar und verlässlich. Was bedeutet das?
Nun werden Schnittpunkte sauber mit Polygonen anstatt mit Boundingboxes ermittelt (ausser für Npcs), so wie sich das gehört.
Der gravierende Bug, dass Pfeile manchmal nach oben wegfliegen ist damit gefixt (ausser bei nahen Gegnern, was äusserst selten auftritt).
Auch das Verschwinden der Zauber von Gladi beschrieben war eine Ursache davon. Und treten jetzt nicht mehr auf.
Selbst Blink profitiert davon: Man kann sich nun nicht mehr durch Gitter und Zäune teleportieren (alles mit Alphapolys). EDIT: Dieses Verhalten bleibt leider bestehen.Dieser Riesenfix ist worauf ich schon lang gewartet habe und ist mittlerweile auf Github und wird demnächst in der nächsten Version von G2 Free Aim released.
Ich würde mich über Interessenten freuen, die den Fix in den oben aufgelisteten Fällen ausgiebig testen wollen, bevor ich das neue Release packe. Über eine PN würde ich mich in dem Fall freuen.
mud-freak
24.02.2017, 12:39
Ich wollte das hier auch noch einmal hier speziell alle Modder fragen (bereits im Modifikationsforum gepostet):
TL;DR: Schreibt mir bitte alles was ich am freien Zielen verbessern soll (möglichst ausführlich), egal ob es bisher schon gesagt wurde.
Ich werde diesen Thread jetzt einmal etwas missbrauchen, denn in diesem Post hier soll es nicht um die Mod, sondern das unterliegende Skriptpaket gehen. Ich schreibe, deshalb hier, weil ich besonders die Spieler erreichen möchte.
Ich habe mich überwunden, noch einmal etwas mehr Arbeit in dieses Skriptpaket zu stecken, um in einem etwas grösseren Update einiges auszubessern. Damit nicht ständig eine kleine Version nach der anderen herauskommt (sehr nervig für Modder, die das freie Zielen in ihren Mods einbauen wollen, und auch für mich, mich ständig neu damit zu befassen), soll es das letzte grosse Update werden. Danach sollen nur noch ggf. kleine Bugfixes released werden.
Dazu möchte ich auch mögliche Mangel adressieren, die das freie Zielen haben mag.
Leider sind die mir nicht alle bekannt oder offensichtlich, da seit dem ersten Release verhältnismässig wenig Kritik dazu bei mir ankam. Es scheint allgemein bekannte Einschränkungen zu geben über die mich aber nie jemand informiert hat. Ab und zu habe ich per Zufall(!) einige scheinbar allgemein bekannte Nachteile in verschiedenen Mod-Ankündigungsthreads in Nebensätzen gelesen, die mir direkt nie berichtet wurden. (Wie soll ich denn da was für unternehmen, wenn mir das niemand sagt?)
Einige Sachen wurden mir tatsächlich berichtet, dafür bin ich sehr dankbar. Leider war das aber bisher sehr zaghaft und immer nur tröpfelweise und ich bin sicher es gibt weitaus mehr was ausgebessert werden sollte.
Deshalb wollte ich jetzt noch einmal den grossen Aufruf machen:
Schreibt mir doch bitte alle möglichen Mängel, Ungereimtheiten oder Sachen, die euch fehlen, nerven oder Ausbesserung bedürfen - eben alles was euch am freien Zielen nicht gefällt! Es müssen nicht nur Bugs sein, sondern können auch Features sein, die euch fehlen. Vor allem interessieren mich auch die Gründe von Leitern von Modprojekten, die sich gegen das freie Zielen entschieden haben.
Deshalb hier eine Liste von mir bisher bekannten Mängeln, die ich euch bitten würde zu erweitern:
✔ Eine Unterstützung für die Gothic 2 Steuerung fehlt.
✔ Unter Umständen gibt es Leistungseinbrüche (zu geringe FPS).
✖ Das Fadenkreuz soll schon während dem ziehen des Bogens, der Armbrust, der Zauber sichtbar sein (nicht erst beim Drücken der Aktionstaste). Unnötig
✔ Zauber verschwinden im Nichts, bzw. stoppen beim Schiessen zu früh in der Luft.
✔ Pfeile/Bolzen fliegen manchmal senkrecht nach oben.
✔ Pfeile/Bolzen fliegen bei weit entfernten Zielen nicht aufs Fadenkreuz zu (sondern etwas zu weit nach oben).
✔ Portierung nach Gothic 1 vorbereiten (das werde ich nicht machen, aber einige Schritte dahin gehend unternehmen, damit das später besser möglich ist).
✔ Es bestehen einige allgemeine Balancing-Bedenken zwischen normalem und freiem Zielen (welche genau?).
✖ Herannahende Gegner sollten verlangsamen, wenn sie von Fernkampfwaffen getroffen werden (siehe Post). Würde erneute Balancingprobleme mit sich bringen.
✔ Zu geringe Schwerkraft von Bolzen (siehe Post).
✔ Gegner greifen bei zu grosser Entfernung nicht an und lassen sich hilflos totschiessen (siehe Post).
✔ Streuung ist zu klein, um ausschlaggebend zu sein. Treffen ist zu einfach (siehe Post).
✔ Kritische Treffer erhöhen durchschnittlich den Schade so sehr, dass Spielen ohne freies Zielen sehr viel schwieriger ist.
✔ Armbrust ist nun unweigerlich stärker als Bogen, da sie sofort gespannt ist, und weniger stark von Gravitation beeinflusst wird.
...Was fehlt ansonsten noch?
Es besteht keinerlei Grund dafür ein Blatt vor den Mund zu nehmen; sagt alles heraus: Was ich nicht weiss, kann ich auch nicht verbessern.
Selbst wenn ihr nichts neues habt, würde ich auch bitten mir so viele Details zu den bisher gelisteten Mängeln zu geben wie möglich. Z.B. "Nummer 1 nervt mich besonders, weil ich mit der Gothic 1 Steuerung gar nicht umgehen kann." oder "Nummer 5 passiert bei mir nur wenn ich auf besonders nahe Objekte schiesse, aber nicht mit Zaubern." Egal, ob etwas schon da steht, schreibt es noch einmal. Damit bekomme ich auch einen Eindruck über die Wichtigkeit der verschiedenen Probleme.
Apropros "tröpfelweise": Ich würd hier gern alles auf einmal sammeln und bin ich hier auf Kritik gespannt.
"Nummer 1 nervt mich besonders, weil ich mit der Gothic 1 Steuerung gar nicht umgehen kann."
:p
Naja, zumindest fast. Mich würde es freuen, wenn es unabhängig funktionieren würde.
Ansonsten fände ich es gut, wenn man die "Fokusreichweite" einstellen könnte, also die Entfernung auf die Namen und Lebensbalken angezeigt werden :)
Milky-Way
24.02.2017, 15:54
Bei LoA werden wir es vermutlich optional einbauen, wenn wir dazu kommen. Hauptsächlich haben wir nicht die Kapazität, dafür ein eigenes Balancing abzustimmen. Schwierigkeit des Bogenschießens und Anzahl benötigter Pfeile ändern sich ja schon. Letzteres kann insbesondere problematisch sein, wenn es "besondere" Pfeile in begrenzter Stückzahl gibt. Daher würden wir vermutlich die Option nutzen, dass Pfeile nicht wieder eingesammelt werden können. (Dafür gab es doch eine ganz einfache Variable, die wir umstellen können?)
Ein Grund ist natürlich auch, dass wir nicht (zusätzliches) Fehlerpotential einbauen wollen. Daher haben wir es nicht direkt bei uns eingebaut sondern warten erst mal das Feedback auf deine Mod ab. Zu gegebener Zeit würden wir das dann auswerten und die aktuellste Version einbauen (ist noch eine Weile hin, bis LoA ganz fertig ist). Sollte es zu dem Zeitpunkt schwerwiegende Fehler geben, würden wir es wohl nicht einbauen. (Dieser Punkt ist aber allgemein und auf kein bestehendes Problem bezogen, für dich im Moment also vermutlich wenig nützlich. Vielleicht erklärt er aber, wieso nicht ganz so viel Feedback kam, falls andere Projekte eine ähnliche Strategie gewählt haben.)
Hi, I use to hero and NPC's custom LeGo bars for HP that colored to green when its poisoned. For NPC's I get other.attribute[ATR_HITPOINTS], other.attribute[ATR_HITPOINTS_MAX] and other aivar for poison status from Loop functioun with "if(Hlp_Is_oCNpc(her.focus_vob))" or "if(Npc_GetTarget(hero))", that work before I start use free aim. When I start aiming with bow, crossbow or magic, function don't get other attributes to custom bars. How I can solved this problem?
That's because Free Aim is using a helper vob (I think), which obviously is a zCVob, not an oCNpc.
The cleanest solution would be to hook at the point the bar is drawn and just use the corresponding NPC. That does require reading the assembly to figure out which register he's hiding in, though... :p
mud-freak
03.03.2017, 12:52
Danke schonmal für das Feedback zu möglichen Verbesserungen. Die sind sehr hilfreich.
Dazu schon mal ein paar Worte: Eine Unterstützung für die Gothic 2 Steuerung ist schon (fast) fehlerfrei implementiert. Ebenso einige andere Bugfixes (Performance, Schussverhalten, AI), dazu habe ich in Post 140 Häkchen neben die Auflistung gesetzt um zu zeigen was schon verbessert ist.
Ansonsten fände ich es gut, wenn man die "Fokusreichweite" einstellen könnte, also die Entfernung auf die Namen und Lebensbalken angezeigt werden :)
Bei Zaubern läuft das nach wie vor über deren einzeln anpassbare Eigenschaft C_Spell.targetCollectRange (siehe z.B. Todeshauch), für den Fernkampf kann man diese diese Konstante (https://github.com/szapp/g2freeAim/blob/639936be25d30f9f458b3105c85213f509cf9021/_work/data/Scripts/Content/freeAim/_intern.d#L49) anpassen. Standardmässig habe ich sie auf 50 Meter eingestellt. Ohne freies Zielen ist in Gothic die Standard-Fokusreichweite 35 Meter. Ich habe 50 Meter gewählt, weil man tatsächlich weiter schiessen kann, egal wie weit nun die Fokuserfassung reicht. Die Konstante in eine Variable zu ändern würde erlauben, die Fokuserfassung während des Spiels anzupassen (z.B. durch Talente). Allerdings fände ich das etwas unglücklich, weil man ja schon weit genug schauen und schiessen kann - die Fokusreichweite zu verringern würde den Spieler also nur "nerven".
Bei LoA werden wir es vermutlich optional einbauen, wenn wir dazu kommen. Hauptsächlich haben wir nicht die Kapazität, dafür ein eigenes Balancing abzustimmen. Schwierigkeit des Bogenschießens und Anzahl benötigter Pfeile ändern sich ja schon. Letzteres kann insbesondere problematisch sein, wenn es "besondere" Pfeile in begrenzter Stückzahl gibt. Daher würden wir vermutlich die Option nutzen, dass Pfeile nicht wieder eingesammelt werden können. (Dafür gab es doch eine ganz einfache Variable, die wir umstellen können?)
Danke für den Einblick in den - ich nenn es mal - Entscheidungsprozess. Das hilft mir das ganze besser zu verstehen. Tatsächlich muss ich zugeben, dass das sehr gerechtfertigte Einwände sind. Hier schon mal ein paar Gedanken dazu, was bisher schon möglich ist und was ich verbessern will:
Die Option Pfeile aufzusammeln (siehe diese Konstante (https://github.com/szapp/g2freeAim/blob/639936be25d30f9f458b3105c85213f509cf9021/_work/data/Scripts/Content/freeAim/config.d#L53) in der Config) lässt sich tatsächlich ausstellen.
Die Pfeile aufsammeln zu können ist allerdings ein übergreifendes Feature, dass auch aktiv ist, wenn man freies Zielen im Menu deaktiviert. Das bedeutet, man könnte Pfeile aufsammelbar machen und - weil es nicht über das Menu an- und ausstellbar ist - ergeben sich dadurch keine weiteren Balancingprobleme (weil es immer an ist).
Unter welchen Umständen Pfeile aufsammelbar sind, kann man in der Config hier (https://github.com/szapp/g2freeAim/blob/639936be25d30f9f458b3105c85213f509cf9021/_work/data/Scripts/Content/freeAim/config.d#L225-L249) (Kollision mit Welt/Objekten) und hier (https://github.com/szapp/g2freeAim/blob/639936be25d30f9f458b3105c85213f509cf9021/_work/data/Scripts/Content/freeAim/config.d#L208-L223) (Kollision mit NPCs) genaustens definieren. Wie dort schon beispielhaft eingebaut, kann man dort einen Zufallswert, oder eine Abhängigkeit von Oberflächenmaterial und -textur abfragen. Genauso könnte man dort auch festlegen, dass "besondere" Pfeile immer beim Aufprall zerstört werden, um sie als "Einwegpfeile" zu definieren und deren übermässigen Einsatz zu kontrollieren/balancieren.
Auf der anderen Seite ist es aber auch richtig, dass man im bisherigen Zustand mit freiem Zielen wesentlich häufiger trifft als ohne. Wie die Streuung mit dem Bogen-/Armbrusttalent zusammenhängt überarbeite ich gerade und will die Trefferchance mit ohne-freies-Zielen abgleichen, um das Balanceproblem zwischen freiem Zielen und normalem Zielen auszuräumen.
Generell will ich G2FreeAim so verbessern, dass es technisch keine Imbalance mehr zwischen freiem Zielen und ohne-freiem-Zielen gibt. Das sollte das nahtlose Einbauen in ein Modprojekt dann einfacher machen.
Hi, I use to hero and NPC's custom LeGo bars for HP that colored to green when its poisoned. For NPC's I get other.attribute[ATR_HITPOINTS], other.attribute[ATR_HITPOINTS_MAX] and other aivar for poison status from Loop functioun with "if(Hlp_Is_oCNpc(her.focus_vob))" or "if(Npc_GetTarget(hero))", that work before I start use free aim. When I start aiming with bow, crossbow or magic, function don't get other attributes to custom bars. How I can solved this problem?
That's because Free Aim is using a helper vob (I think), which obviously is a zCVob, not an oCNpc.
Although Lehona is right about the helper vob, this does not affect the focus vob. her.focus_vob is maintained and it should work (after all the npc you are aiming at still appears in the focus). Npc_GetTarget, however, is always set to zero by G2FreeAim for different reasons. I could look into reworking that. Can you confirm that "if(Hlp_Is_oCNpc(her.focus_vob))" does actually work?
Nevertheless, I think Lehona's suggestion for hooking the healthbars directly might be more elegant and reliable anyway.
Can you confirm that "if(Hlp_Is_oCNpc(her.focus_vob))" does actually work?
I try "if(Npc_GetTarget(hero))", then "if(Hlp_Is_oCNpc(her.focus_vob))", both don't working with free aim.
That block working if I don't freeaim mode.
if(Hlp_Is_oCNpc(her.focus_vob))
{
var c_npc targetNpc; targetNpc = MEM_PtrToInst(her.focus_vob);
Bar_SetMax(NPC_HPBar, targetNpc.attribute[ATR_HITPOINTS_MAX]); Bar_SetValue(NPC_HPBar, targetNpc.attribute[ATR_HITPOINTS]);
if(NPC_HPBarShow == FALSE) {
Bar_Show(NPC_HPBar);
NPC_HPBarShow = TRUE;
};
if(targetNpc.aivar[AIV_NPCIsPoisoned] > 0)
{
Bar_SetBarTex(NPC_HPBar, "Bar_Poison_Mod.tga");
}
else
{
Bar_SetBarTex(NPC_HPBar, "Bar_Health_Mod.tga");
};
};
mud-freak
03.03.2017, 14:49
I try "if(Npc_GetTarget(hero))", then "if(Hlp_Is_oCNpc(her.focus_vob))", both don't working with free aim.
That block working if I don't freeaim mode.
if(Hlp_Is_oCNpc(her.focus_vob))
{
var c_npc targetNpc; targetNpc = MEM_PtrToInst(her.focus_vob);
Bar_SetMax(NPC_HPBar, targetNpc.attribute[ATR_HITPOINTS_MAX]); Bar_SetValue(NPC_HPBar, targetNpc.attribute[ATR_HITPOINTS]);
if(NPC_HPBarShow == FALSE) {
Bar_Show(NPC_HPBar);
NPC_HPBarShow = TRUE;
};
if(targetNpc.aivar[AIV_NPCIsPoisoned] > 0)
{
Bar_SetBarTex(NPC_HPBar, "Bar_Poison_Mod.tga");
}
else
{
Bar_SetBarTex(NPC_HPBar, "Bar_Health_Mod.tga");
};
};
Thank you for the code. I will look into it.
mud-freak
03.03.2017, 18:58
I try "if(Npc_GetTarget(hero))", then "if(Hlp_Is_oCNpc(her.focus_vob))", both don't working with free aim.
That block working if I don't freeaim mode.
I cannot reproduce your problem. For me it works. This is the code I used, called every frame by FrameFunction (yours is grey):
FF_ApplyOnce(ff_herFocus); // In INIT_Global
/* ... */
func void ff_herFocus() {
var int NPC_HPBarShow;
var int NPC_HPBar;
if(!Hlp_IsValidHandle(NPC_HPBar)) {
NPC_HPBar = Bar_Create(GothicBar@);
};
var oCNpc her; her = Hlp_GetNpc(hero);
if(Hlp_Is_oCNpc(her.focus_vob))
{
var c_npc targetNpc; targetNpc = MEM_PtrToInst(her.focus_vob);
MEM_Info(targetNpc.name); // DEBUG
Bar_SetMax(NPC_HPBar, targetNpc.attribute[ATR_HITPOINTS_MAX]);
Bar_SetValue(NPC_HPBar, targetNpc.attribute[ATR_HITPOINTS]);
if(NPC_HPBarShow == FALSE)
{
Bar_Show(NPC_HPBar);
NPC_HPBarShow = TRUE;
};
//if(targetNpc.aivar[AIV_NPCIsPoisoned] > 0)
//{
// Bar_SetBarTex(NPC_HPBar, "Bar_Poison_Mod.tga");
//}
//else
//{
// Bar_SetBarTex(NPC_HPBar, "Bar_Health_Mod.tga");
//};
} else if (NPC_HPBarShow) {
Bar_Hide(NPC_HPBar);
NPC_HPBarShow = FALSE;
};
};
You could add this debugging output (marked in green) to your code, to check whether the problem doesn't lie somewhere else. Maybe you could provide more context when your function is called. Is it called every frame, is it a hook, etc.?
I cannot reproduce your problem. For me it works. This is the code I used, called every frame by FrameFunction (yours is grey)
I use that function FF_ApplyOnce(B_GlobalLoop); in first dialog with first NPC.
You could add this debugging output (marked in green) to your code, to check whether the problem doesn't lie somewhere else. Maybe you could provide more context when your function is called. Is it called every frame, is it a hook, etc.?
Name NPC in focus write in LOG, but i also see custom NPC HP bar while I not use aiming.
"[i] [....2354...]
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего
[i] 00:17 Info: 0 Q: Диего"
And screenshot...
45371
UPD!
Thank you very much for your help! The mistake was in my carelessness in big lines functions. I use script for show NPC HP bar with new condition if(Hlp_Is_oCNpc(her.focus_vob))
if(NPC_HPBarShow == FALSE)
{
Bar_Show(NPC_HPBar);
NPC_HPBarShow = TRUE;
};
but i forgot old condition if(Npc_GetTarget(hero)) to hide NPC HP bar.
Now i use Show and Hide condition with if(Hlp_Is_oCNpc(her.focus_vob)) and HP NPC bar normal functions!
mud-freak
24.04.2017, 09:43
Ich habe zwar seit März nicht daran weiterarbeiten können und werde dazu auch bis auf weiteres erst einmal keine Zeit für haben, aber hier ein wenig alte Neuigkeiten.
Weil ich einige Änderungen seit v0.1.2 als wichtig erachte, wollte ich mittels eines "Pre-Releases" darauf hinweisen. Vielleicht hat sogar jemand Lust die vermerkten Änderungen anzutesten. Dieses Pre-Release ist ein Vorgeschmack auf einige weitere nette Verbesserungen, die ca. im Juni/Juli in v1.0.0 erscheinen werden.
Wichtig:
Diesmal (auch aus Gründen des Zeitmangels) ist kein automatisches Setup dabei. Das auch aus dem Grund, weil sich die Dateistruktur komplett geändert hat. Eine Abwärtskompatibilität ist also nur aufgrund der Funktionsnamen, nicht aber auf den Dateinamen gewährleistet. Die bisherigen G2 Free Aim Content-Skripte sollten also entfernt werden. Dazu reicht es lediglich den Ordner _work\data\Scripts\Content\freeAim zu löschen. Mögliche Änderungen in der Config sollten vorher gesichert werden und können problemlos in den gleichnamigen Funktionen anschliessend wieder eingetragen werden. Die Config ist nun aufgeteilten in verschiedene Dateien, die sich im Unterordner freeAim\config befinden.
Die Änderungen enthalten einige Bug-Fixes, Verbesserungen und eine erste Unterstützung der Gothic 2 Steuerung. Ich empfehle diese neuen Skripte besonders wegen eines enormen Performance-Boosts.
v0.2.0-alpha - 2017-03-05 10:32 (English release notes on Github (https://github.com/szapp/g2freeAim/releases/tag/v0.2.0-alpha)):
Code in verschiedene Dateien aufgeteilt (bessere Lesbarkeit)
Erste Implementierung für Gothic 2 Steuerung (Stabilität bisher nicht vollständig getestet)
Verbesserter Umgang mit Trace Rays (ca. zehn-facher Performance-Boost)
Zauber stoppen nun nicht mehr mitten in der Luft (siehe Post)
Flugbahn von Projektilen korrigiert (diese fliegen nun vernünftig aufs Fadenkreuz zu)
Neue kritische Trefferzonen für (fast) alle Gothic 2 Wesen (siehe hier (https://github.com/szapp/g2freeAim/blob/v0.2.0-alpha/_work/data/Scripts/Content/freeAim/config/criticalHit.d#L5-L133) für eine Liste) - alles Headshots. Bisher war die Trefferzone zu gross und nicht für jedes Wesen angepasst.
Bugfix für nicht reagierende KI, wenn man aus zu weiter Entfernung schiesst (siehe Post)
Download auf Github (https://github.com/szapp/g2freeAim/releases/tag/v0.2.0-alpha)
Da es sich nur um ein "Pre-Release" handelt, sind die Änderungen nicht ausgiebig getestet. Wenn also jemand einen Bug entdeckt würde ich mich über Feedback freuen.
Echt toll, dass du immer noch am Freien Zielen weiterarbeitest! §respekt :dup:
Leider bin ich was Scripts betrifft, nie weit über Quests, Startup und PFX hinausgekommen. §gnah
D.h. wenn ich was testen sollte, bräuchte ich Ikarus und LeGo - kann ich sonst noch was falsch machen? Gut möglich, dass ich ansonsten Bugs reporte, die nur meiner unzureichenden Fähigkeiten zuzuschreiben sind.
mud-freak
24.04.2017, 19:30
Echt toll, dass du immer noch am Freien Zielen weiterarbeitest! §respekt :dup:
Leider bin ich was Scripts betrifft, nie weit über Quests, Startup und PFX hinausgekommen. §gnah
D.h. wenn ich was testen sollte, bräuchte ich Ikarus und LeGo - kann ich sonst noch was falsch machen? Gut möglich, dass ich ansonsten Bugs reporte, die nur meiner unzureichenden Fähigkeiten zuzuschreiben sind.
Danke. Das ist gut zu hören!
Du kannst dich mal dran versuchen. Hier (https://github.com/szapp/g2freeAim/blob/v0.2.0-alpha/README.md#installation) gibt es eine Installationsanleitung, die, wie ich mittlerweile finde, sehr kompliziert wirkt. Sollte ich dann auch mal ändern. Ab Punkt vier sind die Anweisung etwas umständlich. Falls es also nicht hinhaut, meld dich ruhig hier noch einmal. Im Grunde ist die Installation nicht so wild.
EDIT:
Hier ein paar Anstösse für dich zum Vergleichen.
Am Ende sollte der Anfang deiner Gothic.src ca. so aussehen:
_INTERN\CONSTANTS.D
_INTERN\CLASSES.D
Ikarus\Ikarus_Const_G2.d
Ikarus\EngineClasses_G2\*.d
Ikarus\Ikarus.d
Ikarus\float.d
Lego\Header.src
AI\AI_INTERN\AI_CONSTANTS.D
AI\AI_INTERN\BODYSTATES.D
AI\AI_INTERN\FOCUS.D
AI\AI_INTERN\Npc_SetToMad.d
AI\AI_INTERN\Species.d
AI\AI_INTERN\PrintDebug.d
AI\AI_INTERN\PrintPlus.d
freeAim\freeAim.src
...
Die Startup.d in etwa so:
...
func void INIT_GLOBAL()
{
// wird fuer jede Welt aufgerufen (vor INIT_<LevelName>)
Game_InitGerman();
...
// Ikarus initialisieren
MEM_InitAll();
// LeGo initialisieren
LeGo_Init(LeGo_FrameFunctions | LeGo_ConsoleCommands);
// G2 Free Aim initialisieren
freeAim_Init();
...
};
...
Was die Menü-Skripte angeht, weiss ich das gerade nicht auswendig und kann das leider gerade nicht genau nachschauen. Zur Not kannst du alles ab Punkt vier in der Installationsanleitung weglassen - dort wird nur die Menü-Option zum An- und Ausschalten eingepflegt. Obwohl das fürs Testen nicht ganz unwichtig wäre (z.B. ob an- und ausschalten auch mit aktivierter Gothic 2 Steuerung funktioniert).
Vielleicht kann dort jemand aushelfen, wie das Skript _work\data\Scripts\System\Menu\Menu_Opt_Game.d anschliessend aussieht.
Falls ein Multi Arrow System noch nicht drin ist: https://forum.worldofplayers.de/forum/threads/1493364-Skript-Tutorial-Pfeilsorten-Auswahl-Mutli-Arrow-System
mud-freak
29.04.2017, 15:40
Falls ein Multi Arrow System noch nicht drin ist: https://forum.worldofplayers.de/forum/threads/1493364-Skript-Tutorial-Pfeilsorten-Auswahl-Mutli-Arrow-System
Werde ich mir dann mal anschauen. Obwohl es auf den ersten Blick so aussieht, als gäbe es einiges an Einschränkungen mit der Implementierung.
mud-freak
22.06.2017, 20:46
Hallo, ich habe eine Frage und würde mich sehr über Meinungen und Ideen freuen.
Sorry für diesen langen Post. Ich habe versucht mein Problem möglichst einfach zu erklären, dass jeder seinen Senf dazu geben kann. Bitte teilt doch eure Gedanken und Ideen dazu, denn ich steh komplett auf dem Schlauch und weiss da echt nicht weiter.
Wer möchte kann es als Rätsel oder Knobelaufgabe beachten. Vielen Dank an alle, die sich die Zeit nehmen, den Text durchzulesen.
Ein bisher verbleibender Nachteil beim freien Zielen ist es, dass sich das Bogentalent nicht mit der Trefferchance übereinstimmen lässt. Im Charaktermenu bedeutet 10% Bogentalent klassisch, dass 10% aller Schüsse treffen. Im Original wird das einfach per Zufallszahl gewährleistet, beim freien Zielen sieht man aber wie ein Pfeil physikalisch trifft oder nicht. Das freie Zielen muss also wirklich 10% der Pfeile treffen lassen, gleichzeitig aber auch 100% der Pfeile bei 100% Bogentalent.
Nun wo ist das Problem?
Gothics Hitregistration (also wann ein Pfeil einen NPC trifft oder nicht) hängt nicht vom Model, sondern rein von den Boundingboxen ab. Ein Gegner ist also eine riesen Zielscheibe, da die Boundingbox sehr grosszügig gross ist. Pfeile bei 10% Bogentalent müssen also mit sehr grosser Streuung verschickt werden, damit wirklich nur 10% der Pfeile treffen und auch wieder 100% der Pfeile bei 100% Bogentalent. Also einfach alles hochskalieren.
Problem gelöst?
Leider nicht, denn damit auch wirklich erst bei 100% alle Pfeile treffen und nicht schon bei 80% oder 90% muss die Streuung bis zu letzt eine gewisse Grösse haben. Das führt aber dazu, dass kritische Treffer komplett nutzlos werden, denn bei 100% ist die Streuung noch so gross, dass es viel zu schwer wird einen kritischen Treffer (z.B. einen Kopfschuss) verlässlich zu landen. Das kann man nicht als 100% Talent verkaufen (sieht auch dumm aus, wenn man mit 100% immer noch nicht genau dahin schiesst wo man hinzielt).
Ein Beispiel-video im Spiel kann ich leider gerade nicht entwerfen aber hier einige Illustrationen:
https://upload.worldofplayers.de/files10/freeAimScattering.png
Im ersten Bild links seht ihr das Szenario mit der Streuung. Ein Schuss kann, je nach Bogentalent, mit bestimmten Winklen (grün und blau) von der perfekten Flugbahn abweichen und in dem grauen Umkreis mit entsprechendem Radius landen. (Oben drüber steht noch mal die Angabe von 15 Metern um es mit den Originaltrefferchancen zu vergleichen. Nicht so wichtig.)
Rechts im ersten Bild sind zwei Fälle (A und B) mit exemplarischen Werten gelistet. In A stimmt das Bogentalent mit der Trefferchance überein (grün), aber kritische Treffer sind selbst bei 100% Bogentalent noch sehr schwierig, wegen zu grosser Streuung (2° in alle Richtungen, rot).
In B sind kritische Treffer mit 100% Bogentalent wirklich verlässlich zu treffen (fast 0° Abweichung vom perfekten Schuss, grün), dafür entspricht das Bogentalent nicht der Trefferchance (man trifft viel zu häufig, da die Streuung insgesamt zu klein ist).
https://upload.worldofplayers.de/files10/figureScatter_AB.png
Im zweiten Bild sind diese beiden Fälle A und B noch einmal anders visualisiert. Für vier verschiedene Bogentalente (10%, 40%, 75% und 100%) sind in blau die Treffer markiert und in rot verfehlte Schüsse (500 "Schüsse" insgesamt). Der graue Kreis zeigt, welcher Radius als Treffer behandelt wird, was durchschnittlich ziemlich gut mit der Grösse der Boundingboxen übereinstimmt.
In B (unten im zweiten Bild) ist das Bogentalent auch so mit den Treffern skaliert, dass genau alles so trifft wie es soll, nur eben mit viel viel kleinerer Streuung. Dadurch trifft man mit 100% Bogentalent genau wo man hinzielt, allerdings treffen Bogentalente wie 10% viel zu häufig, da die Hitregistrierung bei NPCs halt sehr grob ist.
Milky-Way
23.06.2017, 01:39
Theoretisch ließe sich eine 10% Treffer-Wahrscheinlichkeit ja auch so einbauen:
Mit 10% Wahrscheinlichkeit landet der Pfeil genau dort, wo man hinzielt.
Mit 90% Wahrscheinlichkeit verzieht er sehr stark (sagen wir mal, jeweils 10-20 Grad daneben nach links / rechts und oben / unten).
Deine bisherige Methode scheint mir ja eher in die Richtung zu gehen, dass es einen kleiner werdenden Kreis gibt, in den man schießt und dann innerhalb des Kreises zufällig getroffen wird, so dass insgesamt die Trefferwahrscheinlichkeit in etwa passend ist.
Ich könnte mir vorstellen, dass eine Kombination der beiden Methoden im Spiel akzeptabel wäre. Im Spiel wäre es dann bei 90% so, dass man eben ab und an mal mit dem Bogen abgerutscht ist oder zum falschen Zeitpunkt geatmet oder sonst wie gezittert hat.
Das ganze so auszutarieren, dass die Trefferwahrscheinlichkeit überall (sowohl mit 10% als auch mit 90%) in etwa hinkommt, ist natürlich ein Gefummel, aber im Großen und Ganzen denke ich, dass es möglich sein sollte. Dabei sollte man, um dein Problem tatsächlich zu lösen, vermutlich dafür sorgen, dass die "groben Schnitzer" bei hohem Bogentalent tatsächlich für alle Fehlschüsse zuständig sind und sonstige Treffer sehr präzise sind. Bei geringem Bogentalent hingegen ist es eine Mischung aus beidem: öfter mal geht der Pfeil ganz daneben, ab auch die große Streuung sorgt für Fehlschüsse.
So in etwa könnte ich mir das vorstellen :)
Tandrael
23.06.2017, 06:45
Wir haben uns gedanklich auch schon mit dem Thema beschäftigt, da uns das Freie Zielen auch etwas zu stark vorkam. Das eigentliche Balancing-Problem ist ja derzeit, dass man praktisch kein Bogentalent braucht.
Wir haben uns daher entschieden, eher etwas an dem Balancing der Bögen zu drehen, um das Bogentalent trotzdem nützlich zu machen. Dafür planen wir, die Schadenswerte aller Bögen zu halbieren und den Prozentsatz des Bogentalentes als kritische Trefferwahrscheinlichkeit einzuführen. 10% Bogentalent bedeutet in diesem Fall eine 10%ige Wahrscheinlichkeit auf doppelten Schaden. Wenn man 100% Bogentalent hat, trifft man demzufolge immer mit doppeltem Schaden und hat so wieder normal starke Bögen. Das ganze gilt dann natürlich analog für Armbrüste.
Das ist natürlich keine richtige Lösung für dein Problem, ich wollte nur mal aufzeigen, was wir derzeit geplant hatten. Sorry, dass ich dir nicht mit Mathe oder irgendwelchen anderen Ratschlägen zur Hilfe eilen kann.
Wir haben uns gedanklich auch schon mit dem Thema beschäftigt, da uns das Freie Zielen auch etwas zu stark vorkam. Das eigentliche Balancing-Problem ist ja derzeit, dass man praktisch kein Bogentalent braucht.
Wir haben uns daher entschieden, eher etwas an dem Balancing der Bögen zu drehen, um das Bogentalent trotzdem nützlich zu machen. Dafür planen wir, die Schadenswerte aller Bögen zu halbieren und den Prozentsatz des Bogentalentes als kritische Trefferwahrscheinlichkeit einzuführen. 10% Bogentalent bedeutet in diesem Fall eine 10%ige Wahrscheinlichkeit auf doppelten Schaden. Wenn man 100% Bogentalent hat, trifft man demzufolge immer mit doppeltem Schaden und hat so wieder normal starke Bögen. Das ganze gilt dann natürlich analog für Armbrüste.
Das ist natürlich keine richtige Lösung für dein Problem, ich wollte nur mal aufzeigen, was wir derzeit geplant hatten. Sorry, dass ich dir nicht mit Mathe oder irgendwelchen anderen Ratschlägen zur Hilfe eilen kann.
Ich habe mich bewusst nun doch für "Freies Zielen" entschieden. Ich habe extra dafür eine neue Schadensberechnung eingefügt. §wink
Kellendil
24.06.2017, 20:35
Die Lösung für das Problem ist es, den Abschuss-Winkel nicht aus einem gleichverteilten Intervall zufällig zu berechnen,
sondern unterschiedliche Wahrscheinlichkeiten für unterschiedliche Winkel-Bereiche (Intervalle) zu nutzen.
Ausgeblendete Probleme:
- Unterschiedliche Ziele haben unterschiedlich große Bounding-Boxen
- Die Crit-Bounding-Box befindet sich nicht exakt in der Mitte der Bounding-Box
In Pseudo-Mathe:
Annahme: Der Spieler zielt entweder exakt in die Mitte der Bounding-Box, oder in die Mitte der Crit-Bounding-Box
Abweich-Winkel eines ausgeführten Schusses ("Fehler"), den wir ausrechnen wollen:= r
Maximaler Abweich-Winkel:= rmax
Für Hit benötigter Winkel:= rhit (festgelegt durch Bounding-Box des Ziels, wenn Spieler in deren Mitte zielt)
Für Crit benötigter Winkel:= rcrit (festgelegt durch Crit-Bounding-Box des Ziels, wenn Spieler in deren Mitte zielt)
Es gilt: 0 < rcrit < rhit < rmax < 180
Bogentalent:= skill (1 = 100%, frei wählbar, bestimmt, wie einfach es werden soll, einen Hitzu landen)
Wahrscheinlichkeit, einen Hit zu landen:= phit
Wahrscheinlichkeit, einen Crit zu landen:= pcrit
Wahrscheinlichkeit, dass ein Hit ein Crit ist:= critchance (frei wählbar, bestimmt wie einfach es werden soll, einen Crit zu landen)
Zufallsfunktion:= rand(r1, r2)
Berechnet eine Zufallszahl zwischen r1 und r2 (gleichverteilt)
Ziele (folgendes soll wahr sein):
phit = skill
pcrit = phit * critchance
Einfache Möglichkeiten, r zu berechnen, die aber alle nicht das Ziel erfüllen:
r = rand(0, rcrit) => garantierter crit
=> phit = 1, pcrit = 1
r = rand(0, rhit) => garantierter hit
=> phit = 1, pcrit = (rcrit / rhit)
r = rand(0, rmax)
=> phit = (rhit / rmax), pcrit = (rcrit / rmax)
Offensichtlich sind alle diese Lösungen zu simpel und erfüllen nicht das Ziel (bzw. müsste man ständig die Bounding-Boxen an skill und critchance anpassen, damit die Ziele erfüllt werden).
Korrekte Art, r zu berechnen (Aufteilen des Winkels r in mehrere Zonen):
rZoneCrit = rand(0, rcrit) => grantiertert crit
rZoneHit = rand(rcrit, rhit) => garantiert hit, aber kein crit
rZoneMiss = rand(rhit, rmax) => garantiert weder hit noch crit (= miss)
Jetzt brauchen wir brauchen eine nicht-gleichverteilte Wahrscheinlichkeit, die wir uns leicht aus einer gleichverteilten basteln können, um daraus zu entscheiden, aus welcher Zone wir den zufälligen Winkel berechnen:
zone = rand(0, 1)
r = {
rZoneCrit if 0 < zone < pcrit,
rZoneHit if pcrit < zone < phit,
rZoneMiss if phit < zone < 1
}
Jetz nur noch pcrit und phit ausrechnen (siehe Ziele) und fertig.
Jetzt fliegen die Pfeile mit exakt der richtigen Wahrscheinlichkeit in die entsprechenden Winkel-bereiche.
Auch schön ist, dass man rmax frei wählen kann. Solange rmax groß genug ist, dass man auch wirklich nicht trifft,
wenn rZoneMiss berechnet wird, kann man fmax nach ästhetischen Gesichtspunkten auswählen.
Edit:
Zeug korrigiert.
PS: Das nächste schwierige Problem ist dann, rhit und rcrit zu bestimmen. Letztendlich läuft es darauf hinaus, dass man große Dinge viel einfacher treffen können wird als kleine Dinge. Aber so funktioniert nunmal die Realität auch^^.
Edit2:
Mit der gleichen Methode kann man auch noch mehr Zonen hinzufügen, um z.B. zwischen knappen und starken Danebenschießen zu unterschieden (z.B. mit rZoneNearMiss und rZoneFarMiss), und kann die Wahrscheinlichkeiten dann auch wieder von skill abhängig machen, sodass man mit höherem Skill, wenn man nich trifft, wenigstens knapper daneben schießt.
Wenn man das weiterdenkt, kommt man irgendwann zu dem Punkt, wo man unendlich viele Zonen mit unterschiedlichen Wahrscheinlichkeiten haben möchte (d.h. einfach, dass der Übergang zwischen den Wahrscheinlichkeiten fließend ist), und das ganze ohne den Bounding-Box Kram machen will. Dann definiert man einfach eine Umverteilungsfunktion:
zone = rand(0, 1);
r = zone^(1,5 - skill) * rmax
=>
- skill = 0 => exponentielle Verteilung, d.h. man es ist viel wahrscheinlicher dass man stark daneben schießt als dass man knapp daneben schießt/trifft.
- skill = 0.5 => lineare Verteilung, also alle Winkel zwischen 0 und rmax sind gleich wahrscheinlich
- skill = 1 => Wurzel-Verteilung bei , d.h. es ist viel wahrscheinlicher dass man genau trifft als ungenau/gar nicht
Die Funktion kann man sich natürlich so zurechtbiegen, wie man das halt haben möchte.
Hi,
habe mal ne Frage zu deinem Script. In dem video auf Youtube ist der Stand des Helden beim Abschuss der Pfeile ja immer wie der, des Anfängers. Gleichzeitig muss man einen Augenblick den Bogen gespannt lassen, damit der Cursor "enger" wird und die Treffergenauigkeit erhöht ist.
Ist es möglich das bei anderem Overlay (z.b. Meister) die Geschwindigkeit des verkleinern des Cursor beschleunigt wird? Also man schneller Pfeile mit höherer Genauigkeit schießen kann?
Dann würde ich das Script nämlich gerne nutzen wollen. Habe mir auch eine neue Schadensberechnung erstellt. Damit würde dieses Script sehr viel sinn machen.
beste Grüße
EDIT:
Nochmal in Kurz:
Untrainierter Schütze = längere Phase in der der Cursor enger wird.
besser trainierter Schütze = kürzere Phase in der der Cursor enger wird.
mud-freak
29.06.2017, 13:25
Danke für die zahlreichen Gedanken zu dem Problem.
Milky-Ways Ansatz, die Trefferwahrscheinlichkeit dem Schusswinkel vorweg zu nehmen, ist eine gute Idee. Zusammen mit der Demonstration von Kellendil lässt sich da etwas Gutes finden (Danke für die ausführliche Rechnung!). Wobei eine Differenzierung für kritische Treffer nicht bestimmt werden muss, das geht gut über die zuvor berechnete Streuung. Wie genau ich es dann implementieren will, kann ich hier dann ja noch mal vorrechnen. Das ist sicher für Modteams interessant. Erst muss ich mich mit euren Vorschlägen noch genauer ausseinandersetzen.
@Tandrael: Dass Ihr da so viel Mühe reingesteckt habt, tut mir Leid. Das sollte hoffentlich bald nicht mehr notwendig sein. Für jetzt hast du mich auf die Idee gebracht, mittels Config die Gothic Standard Trefferberechnung einschaltbar zu machen. D.h. wenn ein Pfeil einen NPC trifft wird mittels Wahrscheinlichkeit des Bogentalents bestimmt, ob ein Pfeil als Treffer oder nicht registriert wird.
Das habe ich in diesem Commit (https://github.com/szapp/g2freeAim/tree/1ef6d9d44a40817f2b6127bb7e7651b734f64d64) bereits eingebaut. Um es anzustellen muss man lediglich die Konstante FREEAIM_TRUE_HITCHANCE (https://github.com/szapp/g2freeAim/blob/1ef6d9d44a40817f2b6127bb7e7651b734f64d64/_work/data/Scripts/Content/freeAim/config/settings.d#L13) auf FALSE setzen.
Dabei wird bisher noch die Streuung von Schüssen komplett ausgeschaltet. Das will ich noch ändern, damit kritische Treffer nicht all zu einfach sind. Also eine kleinere Streuung soll dann immer noch möglich sein.
@aebo: Mich würde interessieren, was du da für eine Schadensberechnung eingebaut hast und wie sie das Problem überwindet. Vielleicht sind dort auch gute Ansätze dabei.
Zu deinen anderen Fragen:
Was du da beschreibst habe ich Zugkraft (oder in den Skripten "draw force") genannt. Es gibt einen ganzen Ordner "config" voller Skripte, in denen man all so etwas anpassen kann. Die README (https://github.com/szapp/g2freeAim/blob/1ef6d9d44a40817f2b6127bb7e7651b734f64d64/README.md#customization) ist zwar mittlerweile veraltet, gibt aber Einblick was man alles problemlos anpassen kann. Die empfehle ich sehr zu lesen.
Für dich ist die Funktion freeAimGetDrawForce() (https://github.com/szapp/g2freeAim/blob/1ef6d9d44a40817f2b6127bb7e7651b734f64d64/_work/data/Scripts/Content/freeAim/config/ranged.d#L6-L35) genau richtig. Dort kannst du dann einfach mittels dem übergebenen Funktionsargument "talent" abfragen, was für ein Bogentalent der Spieler hat und dementsprechend den Rückgabewert anpassen. Hier ein Beispiel, wie du das machen könntest (neue Zeilen in grün):
/*
* This function is called at the point of shooting a bow or a crossbow. The return value scales the gravity of the
* projectile in percent, where 0 is fast gravity drop-off and 100 is the straightest shot possible. Regardless of the
* percentage, however, all shots are impacted by gravity at the latest after FREEAIM_TRAJECTORY_ARC_MAX milliseconds.
* Here, bows are scaled with draw time, whereas crossbows always have 100% draw force (they are mechanical).
* This function is also well-suited to be used by the other functions of this file defined below.
*
* Ideas: Incorporate more factors like e.g. a quick-draw talent, weapon-specific stats, ...
*/
func int freeAimGetDrawForce(var C_Item weapon, var int talent) {
if (weapon.flags & ITEM_CROSSBOW) {
// Always full draw force on crossbows
return 100;
};
// Get the current draw time (how long has the shot been drawn)
var int drawTime; drawTime = MEM_Timer.totalTime - freeAimBowDrawOnset;
// For now the draw time is scaled by a maximum. Replace FREEAIM_DRAWTIME_MAX by a variable for a quick-draw talent
var int maxDrawTime;
if (talent < 30) {
// Beginner (talent 0-30%): longest draw time
maxDrawTime = FREEAIM_DRAWTIME_MAX;
} else if (talent < 60) {
// Intermediate skill (talent 30-60%): half the draw time
maxDrawTime = FREEAIM_DRAWTIME_MAX/2;
} else if (talent >= 60) {
// Expert shooter (talent 60-100%): a third of the draw time
maxDrawTime = FREEAIM_DRAWTIME_MAX/3;
};
var int drawForce; drawForce = (100 * drawTime) / maxDrawTime;
// Respect the percentage ranges
if (drawForce < 0) {
drawForce = 0;
} else if (drawForce > 100) {
drawForce = 100;
};
return drawForce;
};
Tandrael
29.06.2017, 13:34
@Tandrael: Dass Ihr da so viel Mühe reingesteckt habt, tut mir Leid.
Mach' dir keine Sorgen, ich hatte doch geschrieben, dass wir bisher nichts umgesetzt hatten, sondern nur mit dem Gedanken gespielt haben. Also haben wir es genau richtig gemacht. Wir warten einfach ab, bis das freie Zielen mechanisch so gut funktioniert wie ein moderner Shooter und können es dann übernehmen :D So wie es aussieht, sind wir ja nicht mehr allzu weit davon entfernt.
Danke für die zahlreichen Gedanken zu dem Problem.
@aebo: Mich würde interessieren, was du da für eine Schadensberechnung eingebaut hast und wie sie das Problem überwindet. Vielleicht sind dort auch gute Ansätze dabei.
Zu deinen anderen Fragen:
Was du da beschreibst habe ich Zugkraft (oder in den Skripten "draw force") genannt. Es gibt einen ganzen Ordner "config" voller Skripte, in denen man all so etwas anpassen kann. Die README (https://github.com/szapp/g2freeAim/blob/1ef6d9d44a40817f2b6127bb7e7651b734f64d64/README.md#customization) ist zwar mittlerweile veraltet, gibt aber Einblick was man alles problemlos anpassen kann. Die empfehle ich sehr zu lesen.
Für dich ist die Funktion freeAimGetDrawForce() (https://github.com/szapp/g2freeAim/blob/1ef6d9d44a40817f2b6127bb7e7651b734f64d64/_work/data/Scripts/Content/freeAim/config/ranged.d#L6-L35) genau richtig. Dort kannst du dann einfach mittels dem übergebenen Funktionsargument "talent" abfragen, was für ein Bogentalent der Spieler hat und dementsprechend den Rückgabewert anpassen. Hier ein Beispiel, wie du das machen könntest (neue Zeilen in grün):
/*
* This function is called at the point of shooting a bow or a crossbow. The return value scales the gravity of the
* projectile in percent, where 0 is fast gravity drop-off and 100 is the straightest shot possible. Regardless of the
* percentage, however, all shots are impacted by gravity at the latest after FREEAIM_TRAJECTORY_ARC_MAX milliseconds.
* Here, bows are scaled with draw time, whereas crossbows always have 100% draw force (they are mechanical).
* This function is also well-suited to be used by the other functions of this file defined below.
*
* Ideas: Incorporate more factors like e.g. a quick-draw talent, weapon-specific stats, ...
*/
func int freeAimGetDrawForce(var C_Item weapon, var int talent) {
if (weapon.flags & ITEM_CROSSBOW) {
// Always full draw force on crossbows
return 100;
};
// Get the current draw time (how long has the shot been drawn)
var int drawTime; drawTime = MEM_Timer.totalTime - freeAimBowDrawOnset;
// For now the draw time is scaled by a maximum. Replace FREEAIM_DRAWTIME_MAX by a variable for a quick-draw talent
var int maxDrawTime;
if (talent < 30) {
// Beginner (talent 0-30%): longest draw time
maxDrawTime = FREEAIM_DRAWTIME_MAX;
} else if (talent < 60) {
// Intermediate skill (talent 30-60%): half the draw time
maxDrawTime = FREEAIM_DRAWTIME_MAX/2;
} else if (talent >= 60) {
// Expert shooter (talent 60-100%): a third of the draw time
maxDrawTime = FREEAIM_DRAWTIME_MAX/3;
};
var int drawForce; drawForce = (100 * drawTime) / maxDrawTime;
// Respect the percentage ranges
if (drawForce < 0) {
drawForce = 0;
} else if (drawForce > 100) {
drawForce = 100;
};
return drawForce;
};
Danke für die Antwort. Ich habe mir inzwischen ein anderes System überlegt. Klappt nun alles so, wie ich mir das vorgestellt habe. Also gibts in meiner Modifikation dein schönes "freies Zielen". §wink
mud-freak
06.07.2017, 13:22
Ich habe das Problem jetzt folgendermassen gelöst.
Anhand der Accuracy (einstellbar durch die Config, standardmässig: Accuracy = Bogentalent) als Wahrscheinlichkeit wird bestimmt, ob ein Schuss treffen sollte oder nicht. Abhängig davon wird der Schuss weit gestreut oder innerhalb eines kleineren Radiuses proportional mit der Accuracy verschossen.
In der Grafik unten kann man das besser nachvollziehen: Der schwarze Kreis (rmiss) ist die maximale Streuung (gleich für alle Bogentalente).
Alles innerhalb des grauen Kreises (rhit) ist präzise genug, um einen NPC zu treffen, wenn man auf ihn zielt.
Der rote Kreis (rmax) führt zusätzlich noch eine höhere Genauigkeit entsprechend des Bogentalents ein.https://upload.worldofplayers.de/files10/figureScatter_small.png
Hier ist die genaue Rechnung, die sich dahinter verbirgt, falls jemand es genau wissen will. Im Deadalus-Code (https://github.com/szapp/g2freeAim/blob/aca1a333671f82f50fd0f255f53fa17b82641570/_work/data/Scripts/Content/freeAim/_intern/ranged.d#L343-L417) ist es sehr schwer nachzuvollziehen, da es wegen der Nutzung der Float-Funktionen sehr unübersichtlich wird. Deshalb hier in Pseudocode mit mathematischer Notation.
https://upload.worldofplayers.de/files10/bL7Bf6B7cQM7png.latex.png
_
Hier noch ein paar Erklärungen:
Die Abweichung von einem perfekten Schuss wird durch die Winkel x und y (Azimuth und Elevation) bestimmt. Diese werden aus der Range [rmin, rmax] zufällig gesampled und anschliessend zufallsbedingt negiert (damit die Abweichungen in alle Richtungen möglich sind). Damit die Streuung kreisrund bleibt, wird y aus einer von x abhängigen Range gesampled.
Die Radei rmin und rmax werden entsprechend der Accuracy vorher angepasst. Bei einer Accuracy von 20% werden 80% der Schüsse mit rmin=rhit und rmax=rmiss weit gestreut. Die anderen 20% der Schüsse, werden mit Abweichungen zwischen rmin=0 und rmax=rhit' verschossen. Der Radius rhit' ist mit der Accuracy skaliert. Da die Beziehung zwischen Radius und Fläche nicht linear ist, wird die Streuung anhand der Fläche des Kreises amax skaliert und anschliessend wieder zu einem Radius rmax zurückkonvertiert.
Auch wenn es soweit gut funktioniert, bin ich noch nicht fertig die Radei rhit und rmiss genau anzupassen, damit die Streuung im Spiel mit dem Bogentalent übereinstimmt. Aber ich bin schon nah dran. (100 Schüsse treffen momentan ca. 70 mal bei Bogentalent 75%.)
Nach ein paar weiteren Tests, sollte dieses Balancingproblem zwischen free aim und auto aim weitesgehend beseitigt sein.
Tandrael
07.07.2017, 06:31
Ausgezeichnet :gratz Dann können wir das Freie Zielen ja bedenkenlos einbauen.
mud-freak
09.07.2017, 02:35
So nun hier noch ein kleines Update. Die Streuung von Schüssen stimmt jetzt mit dem Bogentalent überein (mit einigen Voraussetzungen[1][2][3]).
Ich kann gut nachvollziehen, dass einige sehr kritisch dem Balancing gegenüber waren, was die Trefferwahrscheinlichkeit mit und ohne freiem Zielen angeht und ob sie übereinstimmt. Wenn man in seiner Mod beides anbietet, kommt es zu Ungleichgewicht, wenn Schüsse vom freien Zielen viel häufiger treffen würden. Deshalb habe ich es diesmal genau wissen wollen und habe geprüft wie viele aus 1000 Schüssen treffen. Damit sich jeder selbst davon überzeugen kann, habe ich davon ein Video gemacht.
Zum Test/Video: Um die Trefferwahrscheinlichkeit zwischen mit und ohne freiem Zielen vergleichen zu können, habe ich den Hero genau 15 meter vom Ziel-NPC entfernt gehalten. Das entspricht der Konstante RANGED_CHANCE_MINDIST, bei dessen Entfernung mit der Gothic Standard Hitchance das Bogentalent genau mit der Trefferprozent übereinstimmt (d.h. 10% Bogentalent entspricht 10% Trefferwahrscheinlichkeit). Auf diese Entfernung muss also auch die Accuracy, die man in der Config vom freien Zielen festlegen kann, und deren Streuung mit der Trefferwahrscheinlichkeit übereinstimmen, sodass auch hier gilt: 10% Accuracy = 10% Trefferwahrscheinlichkeit.
Ich habe das getestet für 10% Accuracy (links) und 80% Accuracy (rechts) für jeweils 1000 Schüsse. Entsprechend mussten am Ende jeweils ca. 100, bzw. ca. 800 Pfeile getroffen haben.
Die Ergebnisse im Video sind sehr zufriedenstellend. (Auch wenn 788 etwas ferner von 800 zu sein scheint, liegt das nur an den letzten 150 Schüssen, bis 800 passen die 80% haargenau. Nicht vergessen, dass es sich hier um Wahrscheinlichkeiten handelt.)
https://www.youtube.com/watch?v=Gf3zFufo4qU
Die Änderungen sind bereits auf Github (https://github.com/szapp/g2freeAim/commit/8516492c8e3cd15a69d237c8ad2b861a0b183a6c). Eventuell werde ich das aber noch etwas finetunen. EDIT: Fertig. Hier noch einmal zwei Screenshots für 5000 Schüsse.
45759 45758
Bemerkungen:
[1] Weil die Gothic Standard Trefferwahrscheinlichkeit erst beim Aufschlag entscheidet, ob ein Schuss als Treffer zählt, macht die Grösse des Gegners keinen Unterschied. Trolle z.B. werden (wenn sie nicht immun gegenüber Pfeilen sind) mit der selben Wahrscheinlichkeit getroffen, wie eine Fleischwanze. Das ist bei der Streuung im freien Zielen nicht so. Dort sind grössere Gegner auch logischerweise leichter zu treffen. Das ergibt meiner Meinung nach auch mehr Sinn.
Wem das aber nicht gefällt, der kann in der Config die Streuung ausschalten (https://github.com/szapp/g2freeAim/blob/c558d01b54fc7e55363d11e5a22509c47c6a8437/_work/data/Scripts/Content/freeAim/config/settings.d#L13) und erhält so die Gothic Standard Trefferwahrscheinlichkeit zurück, während die anderen Features des freien Zielens unberührt bleiben.
[2] Gothics Standard Trefferwahrscheinlichkeit hängt nicht nur vom Bogentalent, sondern auch stark von der Entfernung zum Ziel ab. Darauf wird im freien Zielen keine Rücksicht genommen. Das hat aber auch einen guten Grund: Da die Streuung nach Winkeln berechnet wird, nimmt die Trefferwahrscheinlichkeit mit höherer Entfernung auf natürliche Weise ab und auf nähere Entfernung zu. Mit der Standard Trefferwahrscheinlichkeit von Gothic stimmen die Werte bei verschiedenen Entfernungen aber trotzdem nicht überein, da Gothic die Wahrscheinlichkeiten "künstlich" (nicht nach Winkeln) und non-linear berechnet.
[2] Für den Test war die Zugkraft (draw force) stehts 100%. Wenn man die Accuracy mit der Zugkraft koppelt (wie das standardmässig der Fall ist), sinkt die Trefferwahrscheinlichkeit, bei kürzerem Bogenspannen.
Sim0s0on2
12.07.2017, 11:09
Als normalerweise reiner Leser des Forums muss ich an dieser Stelle nochmal sagen: Hut Ab! :gratz
Das klingt wirklich toll. Ich freue mich, demnächst hoffentlich alle meine Lieblingsmodifikationen erneut mit freiem Zielen spielen zu können!
Danke für die gute Arbeit!
mud-freak
18.08.2017, 15:18
Von Seiten des freien Zielens möchte ich mich mal wieder melden mit vier Neuigkeiten. Einige haben vielleicht schon mitbekommen, dass ich an einem Gothic 1 Port fürs freie Zielen gearbeitet habe. Daher hat sich auch der Titel dieses Forenthreads geändert: Die Portierung war erfolgreich!
Die bisher bedenkliche Resonanz von verschiedenen Mod-Teams kann ich gut nachvollziehen. Daher habe ich Gothic 1 komplett mit freien Zielen durchgespielt. Gothic 1 deshalb, weil man Bogen, Armbrust und Magie innerhalb eines Durchspielens alles meistern kann und weil Gothic 1 ja vermutlich anfälliger ist als Gothic 2.
Dabei kamen keine Crashes mehr auf (in den gesamten 27 Std Spielzeit), die Balance (Trefferchance, kritische Treffer) stimmte, und ein/zwei kleine Unschönheiten wurden noch beseitigt. Die Gothic-Atmosphäre blieb m.E. unangetastet. Insgesamt bin ich sehr überrascht, wie gut sich das freie Zielen nun mittlerweile nahtlos in Gothic einfindet (sogar eben in Gothic 1!). Kämpfe geben noch mehr Tiefe/Kontrolle und es hat mir mehr Spass gemacht als ich gedacht hätte (z.B. das Geräusch eines Headshots, wenn man endlich genug LP investiert hat um richtig Zielen zu können).
Damit will ich jetzt nicht das freie Zielen zu sehr preisen, sondern eher meinen ehrlichen Eindruck geben und auch bestätigen, dass Gothic überhaupt damit funktioniert, anstatt das einfach immer nur zu behaupten. Ich kann da gern auch noch genaueres zu sagen, wenn Interesse besteht.
Was Gothic 2 angeht, startet ca. nächste Woche ein Beta-Test. Es haben sich schon einige Tester gefunden (schon einmal grossen Dank!). Wer aber zusätzlich noch unverbindlich mit-testen will kann sich gern noch bei mir melden. Jegliches Feedback hilft. Getestet wird nach Wahl mit MOD-Datei oder Skripten.
Danach will ich freies Zielen als Erweiterungsmod für Gothic 1 und 2 veröffentlichen, bzw. updaten und das überarbeitete Skriptpaket hier mit einigen Tutorials zu den mittlerweile vielen Konfigurationsmöglichkeiten geben. Auch eine grosse Liste an getanen Änderungen seit der letzten Version soll dann kommen.
Zuletzt möchte ich noch erwähnen, dass dieses Skriptpaket mittlerweile aus 5 komplett unabhängig verwendbaren Features besteht:
Freies Zielen für Fernkampf (Bogen, Armbrust)
Freies Zielen für Magiekampf (Runen, Spruchrollen)
Anpassbares Kollisionsverhalten von Projektilen mit Welt und NPCs
Projektile wiederaufsammeln
Kritische Treffer im Fernkampf
Das bedeutet, man kann mit diesem Skriptpaket auch Pfeile wiederaufsammelbar machen und ihnen bestimmtes Kollisionsverhalten mit verschiedenen Oberflächen geben, ohne überhaupt das freie Zielen zu verwenden! Da eben nun so viel damit möglich ist, sind detailiertere Tutorials angebrachter, als nur eine trockene Readme, die niemand anschauen möchte.
Mehr Infos (vor allem zum Gothic 1 Port und zu den hier nicht erwähnten Verbesserungen) kommen demnächst. Stay tuned...
Fisk2033
18.08.2017, 15:33
:gratz:gratz:gratz
Mehr Infos (vor allem zum Gothic 1 Port und zu den hier nicht erwähnten Verbesserungen) kommen demnächst. Stay tuned...
Vielen, vielen Dank für die ganze Arbeit!
Ich bin schon sehr gespannt, wie es sich spielen wird. In den nächsten Wochen werde ich G1 an die nächste Generation weitergeben und selbst einen Durchlauf mit einem Dex/Bogen-Charakter machen - natürlich mit Freiem Zielen :)
Tandrael
18.08.2017, 16:14
Bester Mann! :gratz
Create aim when player is moving it's no hard :)
https://www.youtube.com/watch?v=qMszZ63PC4Q
The biggest problem is animation, BIP01 and BIP01 PLEVIS must have this same rotation in first layer animation, and second layer animation.
mud-freak
23.08.2017, 17:44
Create aim when player is moving it's no hard :)
https://www.youtube.com/watch?v=qMszZ63PC4Q
The biggest problem is animation, BIP01 and BIP01 PLEVIS must have this same rotation in first layer animation, and second layer animation.
Interesting, did you take the same address to hook that I tried? Because that was the problem I had.
If you want you could share the code, I could add it to the script package. What do you say?
Hallo,
ich habe deine Mod zwar noch nicht angespielt, aber die Interesse ist da!
Ich spiele momentan Gothic - Welt der Verurteilten und Gothic 2 - MiniModBalance Updated (felsenschmied).
Was mich an Gothic 2 momentan am meisten stört, ist der Fokus-/Anvisier-mechanismus, also das wenn eine Waffe oder Zauber gezogen/eingesetzt wird, die Kamera sich immer Automatisch an das nächste Ziel fixiert und sich "Q" und "E" an dessen Orientieren, nur die Mausbewegung lässt diese Einstellung manuell ändern. Störend daran ist das die Kamera so auch oft zu Freundlich gesinnten NPC's springt (wie begleiter Lares oder das Irrlicht) ..
Gibt es in Vanilla Gothic eine Möglichkeit das zu Deaktivieren, oder vielleicht mit deiner Mod ?
Ich würde das Freie Zielen gerne in jeder Mod sehen. Aber bisher sehe ich es nur in der RespawnMod für Gothic 2.
Schade eigentlich. Ist ein super Feature.
Danke für deine Arbeit.
mud-freak
27.09.2017, 12:19
Was mich an Gothic 2 momentan am meisten stört, ist der Fokus-/Anvisier-mechanismus [...]
Gibt es in Vanilla Gothic eine Möglichkeit das zu Deaktivieren, oder vielleicht mit deiner Mod ?
Verstehe ich richtig, dass du mit "Q" und "E" seitliches Laufen meinst? Oder sprichst du vom wechseln des Fokus zur nächst-stehenden Person?
Für ersteres: Beim freien Zielen ist, wie der Name schon sagt, die automatische Zielerfassung ausgehebelt. Das betrifft auch das automatische Drehen zu Gegnern, bzw. der "Targetlock". Das betrifft aber nicht den Nahkampf.
Bei GFA gibt es ausserdem noch eine Konfiguration (standardmässig ist sie aktiviert), bei der ein Fokus nur während des Zielens angezeigt wird, sodass das gar nicht mehr vorkommt. Ausnahme bleiben Zauber in der Gothic-2-Steuerung, aber dort tritt das Fixieren nur auf, wenn man bevor man anfängt seitlich zu Laufen jemand im Fokus hatte.
Für letzteres: Das ist hier auch deaktiviert, da das Zielen nun ausschliesslich über die Maus funktioniert. (Hier sei noch einmal gesagt, dass Mods, die freies Zielen verwenden, die Benutzung von der Maus nicht voraussetzen. Das freie Zielen ist automatisch deaktivert, wenn man nur mit Tastatur spielt und es bleibt alles beim alten.)
Ich würde das Freie Zielen gerne in jeder Mod sehen. Aber bisher sehe ich es nur in der RespawnMod für Gothic 2.
Schade eigentlich. Ist ein super Feature.
Danke für deine Arbeit.
Dass noch nicht so viele Mods das freie Zielen eingebaut haben, mag einerseits natürlich daran liegen, dass seit dem freien Zielen noch nicht so viele Mods veröffentlicht wurden (bzw. wenn, dann war es den Moddern zu knapp noch schnell das freie Zielen einzubauen) und andererseits, weil es noch viele Mängel am freien Zielen gab.
Mittlerweile habe ich das ganze System überarbeitet und es wird gerade eifrig getestet. Bald kommt dann eine stabilere und vor allem balanciertere Version heraus, die ein "kurzfristiges" Integrieren in Mods ermöglichen soll. Gleichzeitig wird die Gothic II - Freies Zielen Mod aktualisiert, in der man das freie Zielen dann in seiner verbesserten Form entspannt ausprobieren kann.
Fisk2033
27.09.2017, 12:22
Verstehe ich richtig, dass du mit "Q" und "E" seitliches Laufen meinst? Oder sprichst du vom wechseln des Fokus zur nächst-stehenden Person?
Für ersteres: Beim freien Zielen ist, wie der Name schon sagt, die automatische Zielerfassung ausgehebelt. Das betrifft auch das automatische Drehen zu Gegnern, bzw. der "Targetlock". Das betrifft aber nicht den Nahkampf.
Bei GFA gibt es ausserdem noch eine Konfiguration (standardmässig ist sie aktiviert), bei der ein Fokus nur während des Zielens angezeigt wird, sodass das gar nicht mehr vorkommt. Ausnahme bleiben Zauber in der Gothic-2-Steuerung, aber dort tritt das Fixieren nur auf, wenn man bevor man anfängt seitlich zu Laufen jemand im Fokus hatte.
Für letzteres: Das ist hier auch deaktiviert, da das Zielen nun ausschliesslich über die Maus funktioniert. (Hier sei noch einmal gesagt, dass Mods, die freies Zielen verwenden, die Benutzung von der Maus nicht voraussetzen. Das freie Zielen ist automatisch deaktivert, wenn man nur mit Tastatur spielt und es bleibt alles beim alten.)
Wenn ich ihn richtig verstehe, dann meint er deine erste Variante bzw. möchte er gern freundliche NPCs (wie er sagt z.B. Lares oder das Irrlicht) von diesem Targetlock ausgeschlossen haben, damit er niemals als nächstes Target quasi Lares/Irrlicht sondern immer ein feindlichen NPC/Monster hat.
Verstehe ich richtig, dass du mit "Q" und "E" seitliches Laufen meinst? Oder sprichst du vom wechseln des Fokus zur nächst-stehenden Person?
Für ersteres: Beim freien Zielen ist, wie der Name schon sagt, die automatische Zielerfassung ausgehebelt. Das betrifft auch das automatische Drehen zu Gegnern, bzw. der "Targetlock". Das betrifft aber nicht den Nahkampf.
Bei GFA gibt es ausserdem noch eine Konfiguration (standardmässig ist sie aktiviert), bei der ein Fokus nur während des Zielens angezeigt wird, sodass das gar nicht mehr vorkommt. Ausnahme bleiben Zauber in der Gothic-2-Steuerung, aber dort tritt das Fixieren nur auf, wenn man bevor man anfängt seitlich zu Laufen jemand im Fokus hatte.
Stimmt das meinte ich
Wenn ich ihn richtig verstehe, dann meint er deine erste Variante bzw. möchte er gern freundliche NPCs (wie er sagt z.B. Lares oder das Irrlicht) von diesem Targetlock ausgeschlossen haben, damit er niemals als nächstes Target quasi Lares/Irrlicht sondern immer ein feindlichen NPC/Monster hat.
Genau darum geht's mir!
Dass noch nicht so viele Mods das freie Zielen eingebaut haben, mag einerseits natürlich daran liegen, dass seit dem freien Zielen noch nicht so viele Mods veröffentlicht wurden (bzw. wenn, dann war es den Moddern zu knapp noch schnell das freie Zielen einzubauen) und andererseits, weil es noch viele Mängel am freien Zielen gab.
Mittlerweile habe ich das ganze System überarbeitet und es wird gerade eifrig getestet. Bald kommt dann eine stabilere und vor allem balanciertere Version heraus, die ein "kurzfristiges" Integrieren in Mods ermöglichen soll. Gleichzeitig wird die Gothic II - Freies Zielen Mod aktualisiert, in der man das freie Zielen dann in seiner verbesserten Form entspannt ausprobieren kann.
Verstehe ich. Hoffentlich lässt sich deine stabilere Version soweit gut in bereits vorhandene Mods integrieren sodass viele es auch in Betracht ziehen.
Würde ich mich für dich und mich freuen. :D
@mudfreak
You forgot a function called LIST_ADDFRONT, it causes me an error when starting up.
I've found this on themodders.org but it gives me another error on startup ( expected ';' at line 3)
func int List_AddFront(var int list, var int data)
{
if(!list)
{
_List_ErrPtr("AddFront");
return;
};
var zCList l; l = _^(list);
var int next; next = l.next;
l.next = create(zCList@);
var zCList ln; ln = _^(l.next);
ln.next = next;
ln.data = l.data;
l.data = data;
};
So I don't know if it's the correct one or if there's an updated function somewhere.
@Vic7im
This function isn't void ;)
mud-freak
01.10.2017, 18:42
You forgot a function called LIST_ADDFRONT, it causes me an error when starting up.
That function (https://app.assembla.com/spaces/lego2/subversion/source/HEAD/dev/List.d#ln194) is part of LeGo. I hadn't realized that it is not yet in the latest version of LeGo.
Thanks for pointing that out, I should make sure the next LeGo version is released before GFA hits the 1.0 release. Speaking of: keep in mind that GFA is only in beta right now. I am grateful for any bug reports.
Mir ist beim Testen von Free Aim eine Sache Richtung Zauber aufgefallen. Und zwar Zauber, deren Logik auf der C_CanNpcCollideWithSpell basieren. Als Beispiel der Zauber Untote Vernichten.
Wenn ich diesen auf einen Npc feuere, der aber nicht in meinem Fokus ist (das kann zum Beispiel passieren, wenn ich mit einem Zauber in der Hand aus dem Laufen springe und dann einen NPC anvisiere), dann wird die Funktion C_CanNpcCollideWithSpell ignoriert. Und im Falle des Zauber Untote Vernichten kann jeder beliebige NPC leicht vernichtet werden.
Ich weiß nicht, ob das eine Sache ist, um die sich Free Aim kümmern sollte, aber zumindest sollte man das als Free Aim Nutzer zur Kenntnis nehmen.
Hi.
Can you add optional ability for Gothic2 with Gothic1 control style for MELEE combat autoswitch to use Gothic2 control style with FAR or MAGIC combat?
Gothic Free Aim v1.0.0-beta.20
I get bug:
If I save the game, then exit game, then start game and load the saved game, bow will always shoot accurately at the target, ignoring the deviations:
GFA_SCATTER_HIT
GFA_SCATTER_MISS
GFA_SCATTER_MAX
If the bow is unequiped, and then equiped again, deviations will start work.
mud-freak
10.10.2017, 18:19
Mir ist beim Testen von Free Aim eine Sache Richtung Zauber aufgefallen. Und zwar Zauber, deren Logik auf der C_CanNpcCollideWithSpell basieren. Als Beispiel der Zauber Untote Vernichten.
Wenn ich diesen auf einen Npc feuere, der aber nicht in meinem Fokus ist (das kann zum Beispiel passieren, wenn ich mit einem Zauber in der Hand aus dem Laufen springe und dann einen NPC anvisiere), dann wird die Funktion C_CanNpcCollideWithSpell ignoriert. Und im Falle des Zauber Untote Vernichten kann jeder beliebige NPC leicht vernichtet werden.
Ich weiß nicht, ob das eine Sache ist, um die sich Free Aim kümmern sollte, aber zumindest sollte man das als Free Aim Nutzer zur Kenntnis nehmen.
Ich denke auf jeden Fall, dass es Aufgabe von GFA ist, weil dieses Verhalten beim freien Zielen wohl häufiger auftreten wird als im Normalfall. Allerdings konnte ich das Verhalten (wie beschrieben) nicht reproduzieren. Auf welche Version von GFA beziehst du dich mit dem aus dem Laufen rennen und dann anvisieren?
Trotzdem habe ich es gefixt. Obwohl ich den beschriebenen Fall nicht testen kann, sollten nun alle Zauber die C_CanNpcCollideWithSpell() mit dem getroffenen NPC passieren, egal ob im Fokus oder nicht.
Hi.
Can you add optional ability for Gothic2 with Gothic1 control style for MELEE combat autoswitch to use Gothic2 control style with FAR or MAGIC combat?
To be honest, I have no idea what you mean. The newer versions of GFA (>= 1.0.0-beta) support Gothic 1 as well as Gothic 2 controls. Any mix between those two across melee and ranged combat makes no sense to me. Maybe I misunderstood, could you rephrase your question?
Gothic Free Aim v1.0.0-beta.20
I get bug:
If I save the game, then exit game, then start game and load the saved game, bow will always shoot accurately at the target, ignoring the deviations:
GFA_SCATTER_HIT
GFA_SCATTER_MISS
GFA_SCATTER_MAX
If the bow is unequiped, and then equiped again, deviations will start work.
Thanks for reporting, but I cannot reproduce this bug on neither a clean Gothic 1 nor a clean Gothic 2 installation with v1.0.0-beta.20 only.
I guess it might be related to any other code you might have besides GFA. Would you be willing to test this on a clean installation yourself to confirm?
To be honest, I have no idea what you mean. The newer versions of GFA (>= 1.0.0-beta) support Gothic 1 as well as Gothic 2 controls. Any mix between those two across melee and ranged combat makes no sense to me. Maybe I misunderstood, could you rephrase your question?
In melee combat I allways use Gothic1 controls, but with GFA in ranged combat with Gothic1 controls while aiming not allowed move forward, only side strafe and backward. If set Gothic2 controls in ranged combat with GFA while aiming allowed moving in all directions, but melee combat with Gothic2 controls uncomfortable.
Thanks for reporting, but I cannot reproduce this bug on neither a clean Gothic 1 nor a clean Gothic 2 installation with v1.0.0-beta.20 only.
I guess it might be related to any other code you might have besides GFA. Would you be willing to test this on a clean installation yourself to confirm?
Thanks for anwser, I try inspect my other code for a issues.
mud-freak
10.10.2017, 19:32
In melee combat I allways use Gothic1 controls, but with GFA in ranged combat with Gothic1 controls while aiming not allowed move forward, only side strafe and backward. If set Gothic2 controls in ranged combat with GFA while aiming allowed moving in all directions, but melee combat with Gothic2 controls uncomfortable.
Ah, yes. That I can very well understand, I kind of feel the same way. I can look into how complicated that would be. But I can't promise to include that as an option.
mud-freak
16.10.2017, 20:01
In melee combat I allways use Gothic1 controls, but with GFA in ranged combat with Gothic1 controls while aiming not allowed move forward, only side strafe and backward. If set Gothic2 controls in ranged combat with GFA while aiming allowed moving in all directions, but melee combat with Gothic2 controls uncomfortable.
If you are using the scripts from github, you can try the new v1.0.0-beta.21 (https://github.com/szapp/GothicFreeAim/releases/tag/v1.0.0-beta.21) release. There, you can set control scheme overrides for ranged and spell combat independently in the Gothic.ini. The INI-entries will be created automatically, when starting Gothic 2.
I have not tested this new "feature" thoroughly yet.
; 0 = Automatic/default: Follow the general control scheme setting from the menu
; 1 = Override with Gothic 1 controls
; 2 = Override with Gothic 2 controls
[GFA]
; ...
overwriteControlSchemeRanged=2 ; Ranged combat will utilize Gothic 2 controls
overwriteControlSchemeSpells=0 ; Spell combat will utilize the control scheme defined in the game menu
If you are using the scripts from github, you can try the new v1.0.0-beta.21 (https://github.com/szapp/GothicFreeAim/releases/tag/v1.0.0-beta.21) release. There, you can set control scheme overrides for ranged and spell combat independently in the Gothic.ini. The INI-entries will be created automatically, when starting Gothic 2.
I have not tested this new "feature" thoroughly yet.
; 0 = Automatic/default: Follow the general control scheme setting from the menu
; 1 = Override with Gothic 1 controls
; 2 = Override with Gothic 2 controls
[GFA]
; ...
overwriteControlSchemeRanged=2 ; Ranged combat will utilize Gothic 2 controls
overwriteControlSchemeSpells=0 ; Spell combat will utilize the control scheme defined in the game menu
Yes! This is that's what I request, already implemented options in the game menu and checked in the game. Great work! At the same time Melee combat as Gothic1, Ranged - comfortable aiming and shooting with all directions movement!
About get bug with deviations - this is my mistake, I missed mod file with overrided scripts.
mud-freak
17.10.2017, 08:37
Yes! This is that's what I request, already implemented options in the game menu and checked in the game.
Good to hear that it meets your expectations! I implemented the overrides in a way, that you don't need to do anything besides creating the game menu entries (for GFA.overwriteControlSchemeRanged and GFA.overwriteControlSchemeSpells). These settings are already updated automatically every time the player exists the settings menu.
In my opinion it should be enough to keep these two settings in the INI-file only, because players will most likely only change them once, if at all. But that's of course for you to decide.
Hallo Mud, bietest du Freies zielen nicht mehr über Spine an?
:gratz
mud-freak
10.11.2017, 13:07
Hallo Mud, bietest du Freies zielen nicht mehr über Spine an?
Hi neotrx. Bis die neue Version (1.0) herauskommt, habe ich es aus Spine herausnehmen lassen (zwecks Beta-Test). Bis Ende November sollte die neue Version fertig und dann auch in Spine angeboten sein.
Cool- schön, freu mich drauf! Viel Erfolg! :gratz
mud-freak
02.12.2017, 20:46
Version 1.0
Nach einem Jahr der Veröffentlichung kommt nun endlich die 1.0 Version, die sowohl stablier, besser balanciert und mit neuen Features bestückt ist. Wie die Versionsnummer erahnen lässt, ist dieses Skriptpaket nun komplett und kann nach ausgiebigen Tests nun bedenkenlos in Mods verwendet werden.
Eine wichtige Neuerung ist das große Wiki (http://tiny.cc/GothicFreeAim), das die gesamte Dokumentation enthält und auch alle Anpassungsmöglichkeiten erklärt.
Hier eine unvollständige Übersicht über die Neuerungen.
Volle Gothic 1 Unterstützung
Unterstützung der Gothic-2-Steuerung
Bewegen während des Zielens (inkl. neuer Animationen)
Wesentlich performanter
Jede Menge Bugs wurden gefixt
Neue Kollisionserkennung
Ausgiebig getestetes Balancing (Danke! (https://github.com/szapp/GothicFreeAim/wiki/Acknowledgements#wiki-wrapper))
Information zum genauen Modell-Bone (Körperteil), der getroffen wurde, steht nun zur Verfügung.
Hier gibt es den kompletten Changelog (https://github.com/szapp/GothicFreeAim/wiki/Changelog#v100-dec-2-2017).
Ein Blick ins Wiki ist auf jeden Fall sinnvoll.
Mit dem 1.0 Release des Skriptpaketes, habe ich auch Demo Mods (Erweiterungsmods) zu Gothic 1 und Gothic 2 erstellt. Diese sind im Einleitungspost verlinkt und jeweils in deutsch, englisch und polnisch verfügbar.
When i'm trying init GFA 1.0.0 i have this message in zSpy:
"Insufficient LeGo flags for Gothic Free Aim." My init_global is good:
func void init_global()
{
Game_InitGerman();
LeGo_Init(LeGo_All);
CMsg_ReInit();
GFA_Init(GFA_All);
FF_ApplyOnce(CDamage_Attach);
//next functions | hooks...
};
Today i updated a LeGo, and now i have this message + message example: "offset is 71".
Full log in pastebin:
https://pastebin.com/e8313PE6
It's my fault?
mud-freak
03.12.2017, 19:57
When i'm trying init GFA 1.0.0 i have this message in zSpy:
"Insufficient LeGo flags for Gothic Free Aim."
[...]
It's my fault?
GFA Wiki - Required LeGo packages (https://github.com/szapp/GothicFreeAim/wiki/Features-and-Configuration#required-lego-packages)
GFA requires you to initialize the package Draw3D. It is only used for debug purposes, so it's probably an oversight by mud-freak. It is currently marked as experimental, so you will have to initialize it explicitly:
LeGo_Init(LeGo_All | LeGo_Draw3D)
Edit: It is probably better if you do what the wiki suggests: Add all GFA-flags to your LeGo_Init, even if it says LeGo_All already.
Ok. Big thanks, i didn't read wiki. But in my opinion, this init should be in GFA_INIT. But it's only my opinion.
About GFA: Good Work! :D
Ok. Big thanks, i didn't read wiki. But in my opinion, this init should be in GFA_INIT. But it's only my opinion.
It is. You can't/shouldn't initialize LeGo more than once, though (the latter call returns immediately and does nothing), so if LeGo is already initialized, GFA can't do anything.
Kellendil
09.12.2017, 19:05
Wie hast du das Architektur-Diagramm (https://rawgit.com/wiki/szapp/GothicFreeAim/media/architecture.svg) erstellt? Das sieht richtig gut aus!
mud-freak
09.12.2017, 19:29
Wie hast du das Architektur-Diagramm (https://rawgit.com/wiki/szapp/GothicFreeAim/media/architecture.svg) erstellt? Das sieht richtig gut aus!
Danke. Das habe ich mit Inkscape erstellt. Etwas widerspenstig, aber es lässt sich bändigen.
Kellendil
09.12.2017, 19:43
Danke. Das habe ich mit Inkscape erstellt. Etwas widerspenstig, aber es lässt sich bändigen.
Hmm ok, das ist also manuell gezeichnet? Hast du die PFeile irgendwie mit den Boxen verankert, sodass du die Boxen verschieben kannst? Mit Inkscape hab ich bisher nur Button-Icons für Webanwendungen gebastelt.
mud-freak
09.12.2017, 19:52
Hmm ok, das ist also manuell gezeichnet? Hast du die PFeile irgendwie mit den Boxen verankert, sodass du die Boxen verschieben kannst? Mit Inkscape hab ich bisher nur Button-Icons für Webanwendungen gebastelt.
Nein, die vorgefertigte Pfeil- und Verankerungsmechanik ist grauenhaft und verbuggt. Ich habe die Formen selbst eingefügt und dupliziert wenn ich eine weitere Komponente hinzufügen wollte. Verankert sind die Pfeile nicht, aber die Endpunkte der Pfade lassen sich selektieren, sodass man sie mit den Boxen mit verschieben kann (läuft aufs selbe hinaus).
Ich kann nicht sagen, dass ich ein Fan von Inkscape bin. Eigentlich würde ich so etwas lieber mit TikZ erstellen, aber dazu war das etwas zu gross.
Schreib dir doch ein kleines Programm was den nötigen TikZ-Code generiert $§p4
Lässt sich erhöhter Kopfschussschaden in Gothic 3 auch umsetzen?
Ich brems dich ja nur ungern aus, aber das Modding für G1+G2 hat leider gar nichts mit Gothic 3 zu tun. Wenn, dann weiß das also jemand anderes - am ehesten im G3-Modifikationen Forum (https://forum.worldofplayers.de/forum/forumdisplay.php?f=404).
Ey brems mich nicht aus du Sau!
Danke für die Info :D
I do not understand points 6 &7 steps for install in G1.
In _work\data\Anims\Humans.mds add the lines as indicated in _work\data\Anims\Humans.mds.additions.
Do the same analogous for _work\data\Anims\MDS_Overlay
\Humans_BowT2.mds.additions and _work\data\Anims\MDS_Overlay\Humans_CBowT2.mds.additions.
those 2 files are not exist in standard Gothic package .I have copied them to mdsoverlay and cancel ".additions" in the name of file.
Backup and delete the following files
_work\data\Anims\_compiled\HUMANS.MDH
_work\data\Anims\_compiled\HUMANS_BOWT2.MDH
_work\data\Anims\_compiled\HUMANS_CBOWT2.MDH
Do Ineed to copy them o gothic/_work/anims/_compiled/ ??
I do not have them after parsing scripts.
mud-freak
14.12.2017, 20:52
those 2 files are not exist in standard Gothic package .
All these files are packed in [Gothic]/Data/anims.VDF and need to be unpacked with the Gothic VDFS-Tool. If you do not have the tool in [Gothic]/_work/Tools/VDFS-Tools you can download it here (http://www.bendlins.de/nico/gothic/).
Once you have those files, proceed as in the instructions (add the lines from the ".additions" files and so on).
I forgot that the files don't ship with the mod kit in unarchived form. I will add these instructions to the installation instructions.
EDIT: Also for the new animations to work, you need to remove or rename the anims.VDF file.
"you need to remove or rename the anims.VDF file."
u mean file in gothic/data/anims.vdf.??
well I have checked.
with rename of the file nothing happened, with delete it , the game crashes every time after choosing "new game".
maybe i am doing something wrong while parsing the scriptsa. I have enabled windows "VDFs phisicial first" and "reparse scripts".
step 6 solved - also I have copied those files from gothic 1 freeaim.exe package.
mud-freak
15.12.2017, 11:10
step 6 solved - also I have copied those files from gothic 1 freeaim.exe package.
Wait. What is this freeaim.exe? I have never provided such a file. Be careful with third-party files (especially exe-files) and possibly malicious content. I can't offer support for that.
First off: What you are concerned with right now are only the animations. Without them (steps 6 and 7) GFA should already fully work, just without the possibility to move while aiming. In the LeGo thread you said
Well there is no crash but free zeilung still does not works. there is no aim trigger on the screen.Is this fixed by now? If not, the animations won't fix that. If the problem still persists, post some more details of what you mean by "aim trigger" and we can figure that out.
Now about the animations. I forgot about the "VDFS phyiscal first"-option that Gothic 1 provides. With it, it's a lot easier: From the get-go Gothic 1 does not have the directory Gothic/_work/DATA/Anims. However, it should have been added with the files of GFA, with a directory called "GFA" inside, containing a bunch of ASC-files.
Run the VDFS-tool (shipped with the mod development kit or found here (http://www.bendlins.de/nico/gothic/)) and open the file Gothic/Data/anims.VDF (by pressing the "..."-Button next to "Filename"). You will see the directory tree of all included files. Extract the following three files into your Gothic installation:
_work/DATA/Anims/HUMANS.MDS
_work/DATA/Anims/MDS_OVERLAY/HUMANS_BOWT2.MDS
_work/DATA/Anims/MDS_OVERLAY/HUMANS_CBOWT2.MDSIt should look like this now:
Gothic/_work/DATA/Anims/
¦
¦-> GFA/
¦ ¦
¦ '-> 37 .ASC files
¦
¦-> MDS_OVERLAY/
¦ ¦
¦ ¦-> HUMANS_BOWT2.MDS
¦ '-> HUMANS_CBOWT2.MDS
¦
'-> HUMANS.MDS
Now add the lines of text from the ".addition" files into respective files above. Make sure you add the lines before the two closing brackets "} }" at the end of each file, like so:
// ...
[new lines]
}
}
Run your mod with the "VDFS phyical first" option ticked. This, of course, won't be necessary when you pack everything into a mod-file in your final mod. (Do not remove/rename the file Gothic/Data/anims.VDF, that information was wrong, my bad.)
Sorry for all the confusion. I forgot that animation files in Gothic 1 are maintained a bit different from Gothic 2. I revised the wiki entry accordingly.
Hi, again me.
I think I did everything OK,but seems to be not working . I am little bit tired checking every time this and loosing time.
I upload my scripts package. Maybe u will find an error. Anyway thanks.
The file I have mentioned is Gothic Wolne Celowanie 1.0.0.exe and surely is from you.
https://www.sendspace.com/file/7plios
mud-freak
16.12.2017, 10:55
So I checked your scripts. They are mostly fine. However, you didn't even fix the error like NicoDE told you. How are we supposed to help you, if you do not read the advice?
If you manually initialize LeGo you have to add the flags that are required for GFA.
See: Features and Configuration / Required LeGo Packages (https://github.com/szapp/GothicFreeAim/wiki/Features-and-Configuration#required-lego-packages)
You also accidentally switched the YES/NO choices in the menu-setting, such that free aiming would be disabled when you enabled it and vice versa.
Here is the changes you have to make to your code (marked in green and red).
Gothic\_work\DATA\scripts\Content\Story\Startup.d (Lines 1-6)
func void Init_Global() {
//LeGo_Init(LeGo_All & ~LeGo_Interface);
LeGo_Init(LeGo_All | GFA_LEGO_FLAGS) ;
//InitDamage();//edycja obrażeń !
GFA_Init(GFA_ALL & ~GFA_REUSE_PROJECTILES);
};
// ...
Gothic\_work\DATA\scripts\system\MENU\Menu_Opt_Game_GFA.d (Lines 34-37)
// ...
const int MENU_ID_GFA = 7; // Next available Y-spot in the game menu
const string MENU_GFA_LABEL = "Wolne celowanie"; // "Free aiming"
const string MENU_GFA_CHOICES = "tak|nie" "nie|tak"; // "off|on"
const string MENU_GFA_DESCR = "Wymaga sterowania myszkč"; // "Requires mouse controls"
// ...
With these changes it will work (I ran your scripts myself).
I can only say like in Gothic 3 " we owe so much!"
mega thanks - it works perfectly now!
will u implement other your work like "blink zauber" to gothic 1?
also thanks for new Lego 2.5.0.
mud-freak
16.12.2017, 16:26
I can only say like in Gothic 3 " we owe so much!"
mega thanks - it works perfectly now!
will u implement other your work like "blink zauber" to gothic 1?
also thanks for new Lego 2.5.0.
Nice, good to hear that it works now! Thank you for finding and reporting the incorrect information in the installation instructions. Now it should be easier for anyone to use GFA in Gothic 1.
In theory the blink spell can be ported to Gothic 1 with ease. The visual effects of the spell, however, have some properties that are specific to Gothic 2 and do not exist in Gothic 1, nor can they be emulated. Moving the target effect through the world with the mouse just wouldn't work nicely enough without these properties. This discourages me (= too much work, if even remotely possible) from doing it.
Okay, alles gut, lag tatsächlich nur daran, dass der Übersetzer da Sachen verändert hat, die er nicht verändern darf. Also alles gut :)
mud-freak
01.01.2018, 13:59
Das Team um ukur hat ein neues Video von StrongHand veröffentlicht, das GFA sehr gut darstellt. Dort werden nicht nur alle Sub-Features gezeigt (Wiederaufsammelbare Pfeile, variierendes Kollisionsverhalten und kritische Treffer), sondern man kann auch sehen wie guter Gebrauch von der Konfiguration gemacht wurde. Ausserdem zeigt es auch das Bewegen während des Zielens, was ich bisher noch nicht in Videoform gezeigt hatte.
Danke für das Video!
Ab ca. 1:18 wird GFA gezeigt.
dvRB1ibzOtg
mud-freak
02.01.2018, 14:41
Version 1.0.1
Kleiner Patch, der die Treffsicherheit mit niedrigeren Bogen-/Armbrusttalenten (G2), bzw. Geschick (G1) auf mittlere bis grosse Distanzen verbessert.
Improve scattering for ranged combat
Decrease impact of accuracy modulators (draw force, steady aim, movement)
Hier gibt es den kompletten Changelog (https://github.com/szapp/GothicFreeAim/wiki/Changelog#v101-jan-2-2018).
Ein "Upgrade" von v1.0.0 zu v1.0.1 ist ziemlich simpel, wie in den Releasenotes auf Github beschrieben.
Hey mud-freak.
Ich hätte zwei Fragen bzw. Vorschläge:
Hier (https://forum.worldofplayers.de/forum/threads/1501590-Ank%C3%BCndigung-Gothic-Nyx-2/page9?p=25723941&viewfull=1#post25723941) hat grade jemand darauf hingewiesen, dass er unsere Mod lieber mit Maus und ohne freies Zielen spielen würde. Ich weiß zwar nicht warum er freies Zielen nicht mag und ich würde sicher damit spielen, wenn ich die Maus benutzen würde, aber ich denke es wäre allgemein eine sauberere Lösung, mit der dann noch mehr Leute zufrieden wären, wenn es in den Optionen eine extra Einstellung gäbe, mit der man das Freie Zielen unabhängig von der Maussteuerung einstellen könnte.
Ich stelle es mir so vor, dass die Maussteuerung, insofern sie aktiviert ist, ein aktivieren des Freien Zielens ermöglicht; wenn das Freie Zielen aktiviert ist und man deaktiviert die Maussteuerung, deaktiviert sich auch das Freie Zielen automatisch. Was denkst du?
Zudem noch eine Frage wegen den aufsammelbaren Pfeilen. Kann man die Pfeile auch wieder aufsammeln, wenn die Maussteuerung deaktiviert ist? Oder ließe sich das einbauen?
Danke an der Stelle nochmal für die ganze tolle Arbeit, die du hier in letzter Zeit leistest.
mud-freak
30.01.2018, 15:09
Hier (https://forum.worldofplayers.de/forum/threads/1501590-Ank%C3%BCndigung-Gothic-Nyx-2/page9?p=25723941&viewfull=1#post25723941) hat grade jemand darauf hingewiesen, dass er unsere Mod lieber mit Maus und ohne freies Zielen spielen würde. Ich weiß zwar nicht warum er freies Zielen nicht mag und ich würde sicher damit spielen, wenn ich die Maus benutzen würde, aber ich denke es wäre allgemein eine sauberere Lösung, mit der dann noch mehr Leute zufrieden wären, wenn es in den Optionen eine extra Einstellung gäbe, mit der man das Freie Zielen unabhängig von der Maussteuerung einstellen könnte.
Ich stelle es mir so vor, dass die Maussteuerung, insofern sie aktiviert ist, ein aktivieren des Freien Zielens ermöglicht; wenn das Freie Zielen aktiviert ist und man deaktiviert die Maussteuerung, deaktiviert sich auch das Freie Zielen automatisch. Was denkst du?
Das ist bereits so eingebaut. Im Spielmenü gibt es eine extra Option für das freie Zielen. Im Endeffekt erlaubt das drei Möglichkeiten: Maus deaktiviert (freies Zielen automatisch deaktiviert)
Maus aktiviert + freies Zielen aktiviert
Maus aktiviert + freies Zielen deaktiviertDamit soll kein Spieler gezwungen werden das freie Zielen zu benutzen.
Zudem noch eine Frage wegen den aufsammelbaren Pfeilen. Kann man die Pfeile auch wieder aufsammeln, wenn die Maussteuerung deaktiviert ist? Oder ließe sich das einbauen?
Die aufsammelbaren Pfeile sind ein unabhängiges Feature. Der Mod-Ersteller entscheidet, ob sie aufsammelbar sind oder nicht (das lässt sich in den Skripten konfigurieren). Im Spiel hängt es dann nicht davon ab, ob man das freie Zielen nutzt oder nicht. Die Einstellung im Menü entscheidet wirklich nur über das freie Zielen selbst.
Wenn es soweit ist, dass du GFA einbaust, empfehle ich dann ein bisschen die Konfiguration im GFA Wiki (http://tiny.cc/GFA) zu durchstöbern. Da lässt sich viel an-/ausstellen und beliebig konfigurieren. Man muss nichts so "nehmen" wie es standardmässig konfiguriert ist.
Danke an der Stelle nochmal für die ganze tolle Arbeit, die du hier in letzter Zeit leistest.
Gern. Schön zu sehen, dass es in der ein oder anderen Mod Anklang findet!
Dann ist ja alles schon erledigt und perfekt gelöst. Danke. §wink
Milky-Way
02.02.2018, 05:27
Wäre es dir möglich, die Texturen (und die einzelnen Animationen, natürlich nicht die HumanS.msb) auch kompiliert bereitzustellen? Momentan sind sie nur als .tga im Archiv, was bedeutet, dass ich zuerst noch das Spiel dazu bringen muss, alle Texturen einmal zu verwenden bevor ich sie in eine .mod packen kann. Dabei kann es recht leicht passieren, dass ich eine Datei verpasse o.ä.
Zusätzlich wäre noch eine Übersicht im Wiki schön, welche Dateien alle in eine fertige .mod gehören, wenn GFA verwendet wurde. Ich könnte mir vorstellen, dass das nicht direkt jedem Modder klar ist.
Im Wiki sollte bei der Installation auch erwähnt werden, dass bei LeGo etwas an der Initialisierung geändert werden muss. Das hatte ich jetzt nur bei den FAQ gefunden, nachdem der Fehler beim Spielstart kam.
mud-freak
12.02.2018, 10:44
Wäre es dir möglich, die Texturen (und die einzelnen Animationen, natürlich nicht die HumanS.msb) auch kompiliert bereitzustellen? Momentan sind sie nur als .tga im Archiv, was bedeutet, dass ich zuerst noch das Spiel dazu bringen muss, alle Texturen einmal zu verwenden bevor ich sie in eine .mod packen kann. Dabei kann es recht leicht passieren, dass ich eine Datei verpasse o.ä.
Dass die nicht sofort dabei sind hat zwei Gründe.
Zum einen möchte ich auf Github nur die "Source"-Dateien zum Download breit stellen.
Zum anderen sollen sich Modder mindestens darum selbst kümmern. Zwar soll das Einbinden von GFA möglichst leicht von statten gehen, wenn ich aber zu viel bereitstelle, befasst sich niemand mehr mit dem ganzen Paket und "übersieht" möglicherweise die Konfigurationsmöglichkeiten. Dem entsprechend würde GFA dann viel zu schnell zur Seite geworfen, weil "Pfeile wiedereinsammelbar sind und wir wollen das in unserer Mod nicht, deshalb haben wir uns gegen GFA entschieden" (dabei kann man das in der Konfiguration ausstellen) - so etwas ist schade.
Da dein Post schon eine Woche alt ist, gehe ich mal davon aus, dass du die benötigten Daten schon selbst generiert hast. Wenn nicht, sind hier zwei Links - sie ins GFA Wiki stellen möchte ich aber aus den oben genannten Gründen ungern.
GFA_Textures_compiled.zip (https://upload.worldofplayers.de/files11/GFA_Textures_compiled.zip)
GFA_Animations_compiled.zip (https://upload.worldofplayers.de/files11/GFA_Animations_compiled.zip)
Zusätzlich wäre noch eine Übersicht im Wiki schön, welche Dateien alle in eine fertige .mod gehören, wenn GFA verwendet wurde. Ich könnte mir vorstellen, dass das nicht direkt jedem Modder klar ist.
Gute Idee, das habe ich hier hinzugefügt: GFA Wiki: Creating a Mod File (https://github.com/szapp/GothicFreeAim/wiki/Creating-a-Mod-File#wiki-wrapper).
Im Wiki sollte bei der Installation auch erwähnt werden, dass bei LeGo etwas an der Initialisierung geändert werden muss. Das hatte ich jetzt nur bei den FAQ gefunden, nachdem der Fehler beim Spielstart kam.
Das habe ich nun auch mit in die Installationsanleitung aufgenommen.
Soweit mir bekannt ist das hin und her konvertieren von .tex in .tga mit Verlusten verbunden, auch wenn das in diesem Fall bei so simplen Texturen vermutlich keinen Unterschied machen dürfte, aber das könnte man vllt. auch als Grund anführen, warum es sinnvoll sein kann, auch die originalen .tga anzubieten.
Ich hab gesehen, dass es im Repo ein paar Änderungen gab. Gibt es dann auch eine offizielle neue Version demnächst oder sind die nicht so wichtig?
mud-freak
10.10.2018, 09:51
Ich hab gesehen, dass es im Repo ein paar Änderungen gab. Gibt es dann auch eine offizielle neue Version demnächst oder sind die nicht so wichtig?
Ich bin derzeit für eine Weile unterwegs, deshalb nur eine kurze Antwort darauf.
Es handelt sich größtenteils um einige Optimierungen (bspw. das Entfernen von allen Abhängigkeiten von PermMem). Dabei wird auf eine unnötige Verwendung von Handles komplett verzichtet; vorher wurden einige Handles kurzzeitig benutzt, was den Handlecounter langsam aber stetig hoch getrieben hat. Nichts gravierendes, aber was bei großen Mods vielleicht irgendwann zu einer Handleknappheit führen könnte. Auch das Draw3D Paket von LeGo soll nur noch optional sein und nicht zwingend mitinitialisiert werden, weil es in der finalen Mod nicht von Nöten ist (wird als Debugging-Feature benutzt). Dann wird noch ein vermeintlicher Crash gefixt, der aber nie voll bestätigt wurde und auch nur bei einem Spieler in einer Mod auftrat, wobei die Ursache nicht klar ist.
Das ganze soll nach Abschluss (folge Issue Tracker auf GitHub), in einer kleinen, neuen Version herauskommen. Das wird noch ein paar Wochen dauern, weil ich vorher noch eine neue Version von Ninja fertig machen will.
mud-freak
09.12.2018, 19:44
Version 1.1.0
Seltsamerweise alle Jahre wieder um die gleiche Zeit und in Anbetracht kommender Mod-Erscheinungen: eine neue Version. Diese behebt ein paar kleine Bugs, entfernt Abhängigkeiten von PermMem und lagert einige Einstellung in die Gothic.ini (https://github.com/szapp/GothicFreeAim/wiki/Free-Aiming#ini-settings) aus, um Spielern mehr Freiheit zu geben. Auf diese INI-Einstellungen kann in den Mod-Release-Threads gerne aufmerksam gemacht werden.
Add INI setting for reticle size in pixels to better account for high resolutions, see wiki (https://github.com/szapp/GothicFreeAim/wiki/Free-Aiming#ini-settings)
Add INI setting for displaying the focus also when not aiming, see wiki (https://github.com/szapp/GothicFreeAim/wiki/Free-Aiming#ini-settings)
Fix focus collection on loading when a weapon was drawn
Fix crossbow aiming animation (master stance) with low FPS (no longer interrupted)
Implement timed fade-out of projectiles in Gothic 1 as found in Gothic 2
Simplify initialization by setting debug visualization (Draw3D) to optional
Remove all dependencies on PermMem (View, FrameFunctions) and Interface (Print_S)
Remove all entries in SCRPTSAVE.SAV
Determine reticle textures by spell ID by default, removing the need for separate G1/G2 files
Fix override of memory protection when initialization spells only
Hier gibt es den kompletten Changelog (https://github.com/szapp/GothicFreeAim/wiki/Changelog#v110-dec-9-2018). Wie immer habe ich die Änderungen recht knapp beschreiben. Für Erklärungen stehe ich gern zur Verfügung.
Ein "Upgrade" von v1.0.1 zu v1.1.0 ist sehr einfach, wie in den Releasenotes (https://github.com/szapp/GothicFreeAim/releases/tag/v1.1.0) auf Github beschrieben.
Die Patches zum Freien Zielen werden erst demnächst mit dieser neuen Version aktualisiert. Da bitte ich um etwas Geduld.
Ich nutze mal die Gelegenheit, um völlig allgemein an den Creditseintrag zu erinnern. Den hinzuzufügen ist wirklich kein großer Aufwand, anders als das Erstellen dieses Pakets :)
Milky-Way
09.12.2018, 23:07
Die GFA_G2.src muss ebenfalls angepasst werden, nachdem die reticleBySpellID_G2.d gelöscht wurde. Gleiches gilt vermutlich auf für G1.
Ansonsten scheint es geklappt zu haben bei mir. Ich hatte noch ein paar redefined identifier (durch sizeof_zVEC3 und Wld_StopEffect_Ext-zusammenhängende Funktionen), aber da kannst du ja nichts für.
mud-freak
09.12.2018, 23:09
Die GFA_G2.src muss ebenfalls angepasst werden, nachdem die reticleBySpellID_G2.d gelöscht wurde. Gleiches gilt vermutlich auf für G1.
Danke für den Hinweis! Das werde ich noch in der Beschreibung hinzufügen.
nice to have this update in Ninja GFA Paket.
mud-freak
11.12.2018, 09:59
nice to have this update in Ninja GFA Paket.
That'll have to wait a bit, as I'm currently working on a new version of Ninja. I'll try to have it done by Christmas, but that'll be tricky.
piootrek86
20.12.2018, 16:27
Hi.
Just downloaded and installed free aiming on my gothic. It is working fine ... I think... The only issue I have is that when I click and hold left mouse button npc is targeting but to shot I have to press up arrow on keyboard as in normal game. when I let left mouse button go nothing is happening (npc does not make a shot). It is same for all kind of weapons (magic, bowl). Do u know how to change it to when I let left mouse button go npc wil make a shot?
Thanks
mud-freak
20.12.2018, 16:35
Hi.
Just downloaded and installed free aiming on my gothic. It is working fine ... I think... The only issue I have is that when I click and hold left mouse button npc is targeting but to shot I have to press up arrow on keyboard as in normal game. when I let left mouse button go nothing is happening (npc does not make a shot). It is same for all kind of weapons (magic, bowl). Do u know how to change it to when I let left mouse button go npc wil make a shot?
Thanks
Are you using Gothic 1 or Gothic 2? Gothic 2 has the option for "Gothic 2 controls" in the game menu. In Gothic 1 this is the normal behavior.
piootrek86
20.12.2018, 17:00
Gothic 2.
In the control menu I have action on left ctrl and LMB but still to shoot I have to ether have left mouse button pressed or left ctrl and while one of them is on I have to press up arrow.
mud-freak
20.12.2018, 17:11
Gothic 2.
In the control menu I have action on left ctrl and LMB but still to shoot I have to ether have left mouse button pressed or left ctrl and while one of them is on I have to press up arrow.
I am talking about the control scheme. You can find it in the "Game" settings, called "Gothic 1 Controls". You want it turned off. Since these settings are called differently depending on your language, here some screenshots.
47617 => 47616 => 47615
piootrek86
20.12.2018, 17:18
Hmmm I just checked it and I don't have this option :D
mud-freak
20.12.2018, 17:21
Oh okay, alternatively, in your Gothic installation directory (e.g. C:\Program Files (x86)\Jowood\Gothic 2\) find the file \System\Gothic.ini and change useGothic1Controls to 0.
piootrek86
20.12.2018, 17:24
Brilliant. Thank you. It works fine now.
mud-freak
20.12.2018, 17:24
Great, good to hear. Have fun playing!
TheEternal
30.12.2018, 13:26
Ansich ist GFA ne gute Idee und wir haben es in LoA eingebaut. Leider ist es nicht erfüllend in der Realität, man hat keine Vorteile durch skillbasiertes Zielen, aber alle Nachteile im Kampf mit Gegnern, die dir schon zu Nahe gekommen sind. Aus persönlicher Erfahrung ist GFA ohne zusätzliches Balancing einfach nur frustrierend.
Deswegen ist es nur ein Spaß für paar minuten, bis zur Ernüchterung, dass es mit der Gothic Balancing nicht sinnvoll funktioniert.
Die Streuung auf lange entfernungen ist einfach zu gewaltig um irgendetwas verlässlich zu treffen.
Realistisch wäre so ein Bogensystem wie bei Kingdom Come Deliverance. Das würde sich fair anfühlen.
mud-freak
30.12.2018, 20:44
Ich will nicht abstreiten, dass es mit der Balance problematisch werden kann. Der Punkt ist aber, dass das mit der Konfiguration in der Verantwortung der Mod-Ersteller liegt. Im Skriptpaket sind standardmäßig alle, von Mitlesern gewünschten, (noch so irrelevanten) Mechaniken aktiviert, damit sie nicht hinten runter fallen oder von Mod-Entwicklern vermisst werden. (Es ist einfacher Dinge in der Konfiguration auszuschalten, die einem nicht gefallen, als Dinge anzuschalten, von denen man gar nichts weiß.) Diese Mechaniken beeinflussen in verschiedenem Maße die Balance. Dass sie standardmäßig aktiviert sind heißt aber nicht, dass das die optimale Konfiguration des Pakets ist. Wer GFA in seine Mod einfügen will, sollte sich etwas mit den optionalen Features und Mechaniken und der Konfiguration auseinandersetzen (siehe Wiki). Vieles hat mit Geschmack zu tun, anderes mit Balance. [1] Ich kann nicht alles vorkauen.
Um es direkt auszudrücken: Lest das Wiki. Wer das Paket so nimmt wie es kommt und sich nach Veröffentlichung seiner Mod über schlechte Balance hier plump beschwert, ist mindestens zur falschen Zeit am falschen Ort. Bei all den Konfigurationsmöglichkeiten die Verantwortung für schlechtes Balancing einfach an das Skriptpaket abzutreten ohne selbst die Konfiguration abzustimmen (oder gar anzuschauen?) finde ich frech.
Insgesamt verstehe ich leider nicht genau was du willst. Du sprichst von fehlenden Vorteilen beim freien Zielen, im nächsten Satz bemängelst du die Balance (ist das nicht widersprüchlich?) und dann ziehst du einen Vergleich mit Kingdom Come Deliverance, wo es meines Verständnisses nach vorrangig um Realismus geht. Dort ist z.B. die Spannzeit noch länger und spielt eine größere Rolle, was deinen Punkt mit den nahe kommenden Gegnern noch schlimmer machen würde und die Balance zum automatischen Zielen verzerrt. Welche Aspekte aus Kingdom Come meinst du genau?
Bzgl. deiner beschriebenen Probleme: Man kann sich beim freien Zielen rückwärts Bewegen, um die Distanz zu den Gegnern länger größer zu halten. Die lange Spannzeit kann aber auch in der Konfiguration verkürzt oder ganz ausgeschaltet werden. Und Grund für deine Erfahrung mit der großen Streuung auf weite Entfernungen könnte die Verringerung der Trefferwahrscheinlichkeit sein (durch Bewegen beim Schießen, zu kurze Spannzeit, ruhiges Zielen, usw.), was sich auch in der Konfiguration anpassen oder ausstellen lässt.
[1] Ich selbst würde z.B. Waffenrückstoß, Spannzeit und andere sekundäre Modulatoren der Trefferwahrscheinlichkeit komplett ausstellen. Entfernt man diese aus seiner Mod, fliegt ein Pfeil bei 100% Bogentalent (bzw. 100 Geschicklichkeit in G1) auch immer schnurgerade; und bei 50% immer so, dass auch nur 50% der Pfeile einen 15m entfernten NPC treffen - genau wie im originalen Gothic 2. Wem die Trefferwahrscheinlichkeit durch Winkel trotzdem nicht gefällt, kann sie in seiner Mod auch einfach ganz ausstellen und erhält freies Zielen ohne Streuung mit schnurgeraden Schüssen und Trefferquoten basierend auf Wahrscheinlichkeiten (wie ohne freies Zielen). Balance hängt also von der Konfiguration ab und diese ist Verantwortung der Mod-Entwickler.
mud-freak right, each modder self must customize the project.
For my mod, I remake some constants into variables and linked them to four levels of learning.
With each level, the aiming time and the likely scatter is reduced.
if(Npc_GetTalentSkill(hero,NPC_TALENT_REAL_BOW) == 0)
{
FREEAIM_DRAWTIME_MAX = 3000;
GFA_SCATTER_HIT = 1.5;
GFA_SCATTER_MISS = 2;
GFA_SCATTER_MAX = 2.5;
};
if(Npc_GetTalentSkill(hero,NPC_TALENT_REAL_BOW) == 1)
{
FREEAIM_DRAWTIME_MAX = 2000;
GFA_SCATTER_HIT = 1;
GFA_SCATTER_MISS = 1.5;
GFA_SCATTER_MAX = 2;
};
if(Npc_GetTalentSkill(hero,NPC_TALENT_REAL_BOW) == 2)
{
FREEAIM_DRAWTIME_MAX = 1500;
GFA_SCATTER_HIT = 0.7;
GFA_SCATTER_MISS = 1;
GFA_SCATTER_MAX = 1.3;
};
if(Npc_GetTalentSkill(hero,NPC_TALENT_REAL_BOW) == 3)
{
FREEAIM_DRAWTIME_MAX = 1000;
GFA_SCATTER_HIT = 0.3;
GFA_SCATTER_MISS = 0.5;
GFA_SCATTER_MAX = 0.7;
};
Video in this topic (few pages back (https://forum.worldofplayers.de/forum/threads/1473223-Skriptpaket-Gothic-Free-Aim-(GFA)-ehemals-Freies-Zielen/page11?p=25691329&viewfull=1#post25691329)) with bow level 1 displays the shooting level.
mud-freak
30.12.2018, 22:28
For my mod, I remake some constants into variables and linked them to four levels of learning.
With each level, the aiming time and the likely scatter is reduced.
Nice idea! The decreasing draw time is a nice touch.
I wouldn't recommend changing the scattering angles, however, since they are carefully tuned to reproduce the hit chance that you get with auto aiming (to balance between free aiming on/off). With smaller scattering angles you'll never miss an NPC at a distance of 15 meters. Instead, modifying the accuracy (0% - 100%) in the configuration function GFA_GetAccuracy preserves reliable hit chances. (But if you have carefully tested it to suit your preferences, to each their own.)
TheEternal
03.01.2019, 09:33
Ich will nicht abstreiten, dass es mit der Balance problematisch werden kann. Der Punkt ist aber, dass das mit der Konfiguration in der Verantwortung der Mod-Ersteller liegt. Im Skriptpaket sind standardmäßig alle, von Mitlesern gewünschten, (noch so irrelevanten) Mechaniken aktiviert, damit sie nicht hinten runter fallen oder von Mod-Entwicklern vermisst werden. (Es ist einfacher Dinge in der Konfiguration auszuschalten, die einem nicht gefallen, als Dinge anzuschalten, von denen man gar nichts weiß.) Diese Mechaniken beeinflussen in verschiedenem Maße die Balance. Dass sie standardmäßig aktiviert sind heißt aber nicht, dass das die optimale Konfiguration des Pakets ist. Wer GFA in seine Mod einfügen will, sollte sich etwas mit den optionalen Features und Mechaniken und der Konfiguration auseinandersetzen (siehe Wiki). Vieles hat mit Geschmack zu tun, anderes mit Balance. [1] Ich kann nicht alles vorkauen.
Um es direkt auszudrücken: Lest das Wiki. Wer das Paket so nimmt wie es kommt und sich nach Veröffentlichung seiner Mod über schlechte Balance hier plump beschwert, ist mindestens zur falschen Zeit am falschen Ort. Bei all den Konfigurationsmöglichkeiten die Verantwortung für schlechtes Balancing einfach an das Skriptpaket abzutreten ohne selbst die Konfiguration abzustimmen (oder gar anzuschauen?) finde ich frech.
Insgesamt verstehe ich leider nicht genau was du willst. Du sprichst von fehlenden Vorteilen beim freien Zielen, im nächsten Satz bemängelst du die Balance (ist das nicht widersprüchlich?) und dann ziehst du einen Vergleich mit Kingdom Come Deliverance, wo es meines Verständnisses nach vorrangig um Realismus geht. Dort ist z.B. die Spannzeit noch länger und spielt eine größere Rolle, was deinen Punkt mit den nahe kommenden Gegnern noch schlimmer machen würde und die Balance zum automatischen Zielen verzerrt. Welche Aspekte aus Kingdom Come meinst du genau?
Bzgl. deiner beschriebenen Probleme: Man kann sich beim freien Zielen rückwärts Bewegen, um die Distanz zu den Gegnern länger größer zu halten. Die lange Spannzeit kann aber auch in der Konfiguration verkürzt oder ganz ausgeschaltet werden. Und Grund für deine Erfahrung mit der großen Streuung auf weite Entfernungen könnte die Verringerung der Trefferwahrscheinlichkeit sein (durch Bewegen beim Schießen, zu kurze Spannzeit, ruhiges Zielen, usw.), was sich auch in der Konfiguration anpassen oder ausstellen lässt.
[1] Ich selbst würde z.B. Waffenrückstoß, Spannzeit und andere sekundäre Modulatoren der Trefferwahrscheinlichkeit komplett ausstellen. Entfernt man diese aus seiner Mod, fliegt ein Pfeil bei 100% Bogentalent (bzw. 100 Geschicklichkeit in G1) auch immer schnurgerade; und bei 50% immer so, dass auch nur 50% der Pfeile einen 15m entfernten NPC treffen - genau wie im originalen Gothic 2. Wem die Trefferwahrscheinlichkeit durch Winkel trotzdem nicht gefällt, kann sie in seiner Mod auch einfach ganz ausstellen und erhält freies Zielen ohne Streuung mit schnurgeraden Schüssen und Trefferquoten basierend auf Wahrscheinlichkeiten (wie ohne freies Zielen). Balance hängt also von der Konfiguration ab und diese ist Verantwortung der Mod-Entwickler.
Gut das war mir ehrlich gesagt nicht klar, dass man da was einstellen kann, zumal ich das Paket nicht eingebaut habe oder eine Doku gelesen habe.
Dann ist das eher bei uns ein internes Diskussionsthema.
Wegen Kingdom Come Deliverance. Was ich damit ausdrücken wollte war: In Kingdom come schießt man dahin wo man hinzielt, lediglich die Spannstärke und dauer beeinflusst die Flugweite und Treffergenauigkeit.
Bei meinem ausgiebigen Versuch GFA zu nutzen hatte ich keinerlei realistischen Erfahrungen. Sowohl auf Entfernung verfehlt man alles und kann mit Glück einen Treffer landen und aus der Nähe trifft man erst recht nix, weil die Gegner einem vor dem Visier rumhüpfen, also ist man doppelt am Loosen. Beim autoaim, hatte man wenigstens bei näherkommenden Gegnern eine relativ hohe Trefferchance.
mud-freak
03.01.2019, 11:27
Gut das war mir ehrlich gesagt nicht klar, dass man da was einstellen kann, zumal ich das Paket nicht eingebaut habe oder eine Doku gelesen habe.
Dann ist das eher bei uns ein internes Diskussionsthema.
Da war ich etwas zu vorschnell in der Annahme, dein vorheriger Post sei die kollektive Meinung vom LoA-Team, entschuldige.
In Kingdom come schießt man dahin wo man hinzielt, lediglich die Spannstärke und dauer beeinflusst die Flugweite und Treffergenauigkeit.
Ah, verstehe. So könnte man sich GFA auch konfigurieren. Da ist dann nur die Frage was mit dem Bogenskill passiert. Man muss abwägen, ob der Skill innerhalb des Spiels (Lernpunkte) oder vor dem Bildschirm (motorisch) erforderlich ist. Tatsächlich benötigt man in der Standardeinstellung von GFA beides, wodurch es zugegeben ungleich schwerer wird - bis man die Mechanik etwas raus hat.
Ein paar Details dazu (bei Interesse):
Bei meinem ausgiebigen Versuch GFA zu nutzen hatte ich keinerlei realistischen Erfahrungen. Sowohl auf Entfernung verfehlt man alles und kann mit Glück einen Treffer landen und aus der Nähe trifft man erst recht nix, weil die Gegner einem vor dem Visier rumhüpfen, also ist man doppelt am Loosen. Beim autoaim, hatte man wenigstens bei näherkommenden Gegnern eine relativ hohe Trefferchance.
Vielleicht kann man sagen, die Standardkonfiguration ist etwas "zu" realistisch. Denn sowohl die motorische Fertigkeit als auch das Bogentalent spielt eine Rolle. Erst wenn mechanisch alles perfekt sitzt (Bogen komplett gespannt, nicht laufen während des Zielens, keinen Schaden nehmen, ruhiges Zielen, usw.), kommt man auf die Trefferwahrscheinlichkeit aus dem Bogentalent.
D.h. bei 10% Bogentalent erreicht man nur eine Trefferwahrscheinlichkeit von 10% wenn man es mechanisch alles drauf hat. Stimmt dabei etwas nicht, verringert sich die Trefferwahrscheinlichkeit (zu z.B. 7% o.ä.). Aufgewogen werden soll das durch die Fähigkeit beim Zielen rückwärts zu laufen.
Das allein macht das freie Zielen (in der Standardkonfiguration) schon ungleich schwerer, da stimme ich zu.
Abgesehen von diesen mechanischen Anforderungen, ist die Trefferwahrscheinlichkeit allerdings gleich-frustrierend wie beim automatischen Zielen. Der Unterschied ist nur, dass die Pfeile sichtbar streuen und man denkt "Mensch jetzt treff doch mal endlich!" In Wirklichkeit streuen die Pfeile aber nämlich nicht nach Winkelwahrscheinlichkeiten, sondern es wird mit der gleichen Wahrscheinlichkeit vom automatischen Zielen bestimmt ob ein Pfeil konzentriert streut (random < skill), oder extrem streut (random > skill). Die Größe des Streuungswinkles beim Danebenschießen ist das frustrierende: Damit die Trefferwahrscheinlichkeiten auch aufgehen muss wahnsinnig weit gestreut werden, sonst treffen ab 75% Skill schon alle Pfeile. Im Endeffekt kommt man mit dieser Implementierung rechnerisch und empirisch auf die gleichen Trefferquoten wie mit dem automatischen Zielen - vorausgesetzt man lässt die genannten Modulatoren außen vor.
Sekundäre Modulatoren der Trefferwahrscheinlichkeit in der Standardkonfiguration
BogenArmbrust
Flugweite skaliert mit...SpannzeitZeit seit ruhigem Zielen
Schaden skaliert mit...SpannzeitZeit seit ruhigem Zielen
Trefferwahrscheinlichkeit skaliert mit...SpannzeitZeit seit ruhigem Zielen
Trefferwahrscheinlichkeit verringert wenn...Laufen beim Schießen
Waffenrückstoß skaliert invers mit... - Stärke
Was ich machen könnte wäre die Standardkonfiguration so zu ändern, dass diese Trefferwahrscheinlichkeits-Modulatoren (sie Spoiler oben) komplett raus sind. So sind zwar die ganzen netten Features standardmäßig nicht dabei, aber GFA würde sich leichter nach Plug-and-Play-Manier einbauen lassen - ABER: Warum sollte man es dann überhaupt einbauen? Für balanciertes, "vanilla" GFA gibt es ja den Patch (im Moment stimmt das nicht ganz, da kommt aber bald ein Update). GFA einzubauen, macht seit es den Patch gibt nur wirklich dann Sinn, wenn man Ideen für eigene Konfiguration hat. Wenn ich mich recht entsinne, hat Bonne für XR z.B. eingebaut, dass man Tiere nur ausweiden kann, wenn man sie nicht im Torso getroffen hat.
Wenn ihr solche Features nicht habt und auch nicht in anderer Weise von GFA abhängig seid, z.B. durch Spine Achievements, könnt ihr in einem ggf. kommenden Update von LoA auch theoretisch GFA einfach rausschmeißen. Spieler könnten sich das freie Zielen dann mit dem Patch aktivieren und ihr braucht euch um die Balancingfrage keine Sorge machen und auch für Rückmeldungn von Spielern nicht geradestehen. Das erscheint mir recht sinnvoll und ich würde euch das nicht irgendwie übel nehmen. (Dann den Inkompatibilitätseintrag in der INI nicht vergessen herauszunehmen.)
Andernfalls helfe ich euch da gern eine passende Konfiguration zu finden. Wenn ihr ein paar Vorstellungen habt, meldet euch ruhig per PN.
That'll have to wait a bit, as I'm currently working on a new version of Ninja. I'll try to have it done by Christmas, but that'll be tricky.
mud-freak are u still working on this update?
mud-freak
21.01.2019, 21:03
mud-freak are u still working on this update?
Yes, should be done in a few weeks.
I'm fairly new to Gothic 2, so I apologize if I'm a bit clueless. The free aim installation mentions to "make sure Ikarus (http://forum.worldofplayers.de/forum/threads/1299679) and LeGo (http://lego.worldofplayers.de) are installed and parsed in _work\data\Scripts\Content\Gothic.src." I have both the Ikarus 1.2.1 and LeGo 2.5.1 files, but I am unware of how to install and parse them. Can anyone explain the process?
I'm fairly new to Gothic 2, so I apologize if I'm a bit clueless. The free aim installation mentions to "make sure Ikarus (http://forum.worldofplayers.de/forum/threads/1299679) and LeGo (http://lego.worldofplayers.de) are installed and parsed in _work\data\Scripts\Content\Gothic.src." I have both the Ikarus 1.2.1 and LeGo 2.5.1 files, but I am unware of how to install and parse them. Can anyone explain the process?
The respective .src-files (Ikarus_G2.src from Ikarus and Header.src from LeGo) need to be added to the Gothic.src (just open it with a text editor). You can add them after the first few lines (e.g. after CLASSES.D).
Powered by vBulletin® Version 4.2.2 Copyright ©2025 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.