Das Forum ist read-only und nur noch zu Archivzwecken vorhanden. Neue Benutzer werden nicht mehr freigeschalten.
Benutzt bitte unser aktuelles Forum: http://www.battle-planet.de/pbp/main/forum_neu.php
Ich hak' hier nochmal nach: Daß der erste Teil meiner letzen Antwort keinen interessiert, damit kann ich leben. Aber den zweiten Teil würde ich schon ganz gern dieses Jahr noch geklärt wissen. ;)
Vielleicht hat ValHaris (oder wer auch immer dazu eine verläßliche Aussage treffen kann) es auch einfach nur übersehen, darum nochmal:
Wie sollen die verschieden Sockeltypen den View beeinflussen? Stimmt Theorie und Praxis in ASC überein?
Gut, das war dann wohl mal wieder ein Denkfehler meinerseits. Ich bin davon ausgegangen, sobald einmal ein View-Wert für ein Feld ermittelt ist, brauch man nur noch von dort aus weiterrechnen, um den View fürs Nachbarfeld zu bekommen. Aber natürlich fängt er immer am Ursprung an und hangelt sich zum Zielfeld durch. Dadurch können sich natürlich Abweichungen in der Route und somit den View-Werten ergeben.
Das macht die ganze Angelegenheit aber auch nicht unbedingt einfacher, da man nur schwer rausbekommt, wie die Route nun verläuft (erst "links" oder erst "rechts" lang).
Daher mal die Frage, inwieweit die Code-Struktur darauf vorbereitet wäre, die Funktion >show Visibility Range< auch für den Gegner zu berechnen und anzuzeigen, damit man so schneller erfassen kann, ohne selber rechnen zu müssen, welchen (möglichen) View der Gegner hat?
Also mal etwas konkreter, damit nicht wieder unnötig aneinander vorbeigeredet wird. Was soll passieren, wenn man die Funktion >show Visibility Range< aufruft:
a) Ist auf dem Spielfeld keine Einheit oder eine von meinen eigenen selektiert, tut die Funktion genau das gleiche wie bisher auch.
b) Ist eine Einheit des Gegners selektiert bei Funktionsaufruf, wird nur der View für diesen Spieler berechnet und angezeigt - natürlich nur für die Einheiten, die ich auch in diesem Moment sehe.
Wäre das ohne viel Aufwand umzusetzen? Finde andere hier diese Idee sinnvoll?
Nun nochmal zu dem Problem, daß Einheiten auf Defensivsockeln 5 View weniger und auf high Turret Sockeln 10 View mehr haben sollen - zumindest wenn die Info von Xyphagoroszh korrekt ist. Im Spiel ist davon momentan nichts zu bemerken, definiert (wo auch immer) soll es aber so sein.
Wessen Baustelle ist das? Klärt ihr das intern? Ich hätte dazu ganz gerne mal eine verläßliche Aussage, wie die beiden Sockeltypen nun den View beeinflussen (sollen).
Ich würde vorschlagen, bevor die Beispiele für den Einsteigerguide genommen werden, sollte zuerst nochmal ausdiskutiert werden, ob nun Theorie und Praxis in ASC übereinstimmen. Wenn Xyphagoroszh recht hat, ist dies derzeit nicht der Fall.
Spätestens wenn ValHaris in 2 Wochen wieder von den Bahamas zurück ist, wird er von mir zu dem Thema nochmal ins Kreuzverhör genommen. Ungenauigkeiten haben in einem Taktikspiel nunmal nix verloren, meiner Meinung nach - erst recht nicht in einem so guten wie ASC.
Wenn dann endgültig geklärt ist, WasWannWieWo funktionieren soll, bezüglich View/Radar, kann man sich auch Gedanken machen, wie gute Beispiele zu dem Thema für den Einsteigerguide aussehen könnten.
--- Das Basejamming auf dem Feld auf dem die Einheit steht behindert deren Sicht nicht. --- Das ist richtig, hab's gerade nochmal überprüft.
Allerdings kann ich deine Aussage: --- Einheiten auf Defensivsockeln haben 5 View weniger, auf high Turret Sockeln haben sie 10 View mehr. --- so nicht bestätigen. Ich habe mir dazu mal im Editor einfache Beispiele erstellt - Ergebnis:
Bei Einheiten auf Def-Sockeln bleibt der View unverändert - auf highTurret-Sockeln gibt es +5 View.
Das GRS startet auf Def-Sockel also mit 106, davon kommen 96 auf dem nächsten Feld an. Auf highTurret-Sockel startet es mit 111, davon kommen 101 auf dem nächsten Feld an.
Dann hab' ich mir nochmal mein Szenario von oben im Editor nachgebaut, aber nur aufs wesentliche konzentriert. Hier zeigt sich sehr gut, was ValHaris mit "Der GRS schaut nicht um die Ecke" meinte. Ich bin bisher davon ausgegangen, daß er ähnlich wie bei der Wegsuche, die optimalste Sicht errechnet (der höchste View-Wert gewinnt).
Tatsächlich berechnet ASC aber den "direkten" Weg zum Ziel. "Direkt" deshalb, weil es theoretisch 2 Wege gibt zum Ziel zu kommen. Die Programm-Logik entscheidet sich aber anscheinend immer stur für eine bestimte Route.
Der Bildschirmausschnitt wirft bei mir aber mindestens eine Frage auf:
Warum sind auf Feld (11) nur 67 View? Normalerweise müßten es doch entweder 68 oder eben 71 sein. Wer hat dafür eine Erklärung?
Ich habe versucht durch Berechnung rauszubekommen, ab wann ein gegnerisches GRS meinen VORTEX erst sehen müßte (siehe Bildanhang) - mit der ersten Kalkulation bin ich leider gescheitert. Meine Überlegungen waren wie folgt:
GRS hat einen View von 105 (+1) = 106 VORTEX hat ein Jamming von -39
bei Feld (1) kommen von 106-10 noch 96 an (2) kommen 86 an (3) kommen 76 an (4) kommen 66 an (5) kommen 56 an -39 = 17 View -> VORTEX wäre hier sichtbar (durch Test bestätigt) (6) kommen 46 an -39 = 7 View -> VORTEX müßte auch hier sichtbar sein, da ja 1 View ausreichen soll
Warum sieht er aber meinen VORTEX auf Feld (6) nicht?
Liegt es etwa daran, daß ich auch noch die Base-Jamming-Werte vom GRS-Sockel und dem Schützengraben abziehen muß (siehe rechten Bildausschnitt)?
Sieht die vollständige Berechnung dann so aus:
GRS hat einen View von 105 (+1) - 6 BaseJamming = 100
bei Feld (1) kommen von 100-10 - 4 BaseJamming noch 86 an (2) kommen 76 an (3) kommen 66 an (4) kommen 56 an (5) kommen 46 an -39 = 7 View -> VORTEX wäre hier sichtbar (durch Test bestätigt) (6) kommen 36 an -39 = 0 View -> VORTEX darum hier noch nicht sichtbar
Wenn ich in einer neuen Runde (bin gerade in der Kampagne #8) das RF bei einer COMA II aus der Vorrunde wieder deaktiviere, ist es nicht mehr möglich, mit dieser Einheit anzugreifen. Der Angriffsbutton verschwindet einfach. Wieso?
Ich kann dafür keine Erklärung finden, außer daß es ein Fehler sein muß.
Da es wohl kein anderer mehr weiß, scheinst du mir der einzige zu sein, der noch erklären kann, wieso ein gegnerisches Uboot seine eigenen Minen aufdecken können soll. Für mich ist das ein taktischer Vorteil, den ich unberechtigterweise bekomme.
Mit welcher Begründung wurde das mal eingebaut? Ein kurzer Kommentar von deiner Seite wäre schon.
Woher bekommt man vorab die Info, daß U-Boote im getauchten Zustand 11 Bewegungspunkte pro Feld brauchen? Im Field-Info werden die Movemali ja unkorrektweise auch weiterhin mit 10 angegeben.
Weiterhin deckt ein gegnerischer EEL seine eigenen Minen auf, sofern er sich direkt auf einem solchen Feld befindet (siehe Bildanhang). Ist das programmtechnisch nicht anders zu lösen oder eher als Fehler anzusehen?
Ich habe im Forum, in den Guides und in der Faq gesucht. Nirgends scheint es eine Erklärung für diese Eigenschaft zu geben.
Was genau bedeutet diese Eigenschaft?
Den einzigen Reim, den ich mir bisher darauf machen konnte: Sofern eine Einheit die Eigenschaft hat, nach einer Bewegung nicht mehr schießen zu können (Waffeninfo: "unit can shoot after moving - no") - muß sie bis zur nächsten Runde warten, um wieder aktiv angreifen zu können - eben "Wait for Attack". Trifft das in etwa zu?
@GAMER Danke. So reicht mir das (zumindest optisch).
Aber da kommt gleich der nächste Bug zum Vorschein. Ich gehe davon aus, daß der Eintrag in der as2.ini, dem "Direct Movement" unter Global->Options entspricht. Im Menü läßt er sich aber nicht an- oder abwählen. Er behält immer seinen Status aus der asc2.ini bei.
Es stört mich häufiger, daß ich die Bewegungskosten einer Einheit immer selber vorab umständlich mit der Field-Info (7) abrufen und sogar addieren muß (Kopfrechnen - wie furchtbar ;) ), um z.B. zu ermitteln, ob ich dann noch genügend Reserve habe, um bestimmte Aktionen auszuführen (Minen legen, Straßen bauen etc.). Für sowas wurden doch eigentlich die Rechenknechte erfunden, warum also sollte mir ASC diese Arbeit nicht abnehmen können?
Ich würde es mir so in der Art wünschen, wie es bereits bei den Baufahrzeugen gehandhabt wird. Anzeige der für diese Aktion benötigten Bewegungspunkte in der Statuszeile und auch wieviel BP die Einheit danach noch zur Verfügung hat (<- sonst müßte ich wieder erst nachrechnen ob z.B. 10 BP übrig bleiben fürs Minenlegen).
Die Luxusvariante davon wäre dann, die Route gleich optisch auf dem Spielfeld einzublenden - ähnlich wie man es in Civ3 getan hat (siehe Anhang). Entweder, wie auf dem Bildausschnitt zu sehen, mit einer einfachen Linie oder vielleicht mit optisch markierten Feldern.
Das hätte den Vorteil, das man als Spieler vorab sehen kann, ob die Einheit, wenn sie mit einem Zug eine längere Strecke zurücklegen soll, auch nur über Terrain fährt, welches man selber manuell auch wählen würde. (Oft gibt es Alternativ-Routen, die gleich viel BP kosten würden, da aber ASC die Bewegungen natürlich nach einem fest programmierten System vollzieht, kann es sich schon mal für die "falsche" entscheiden).
Bisher muß man ja blind vertrauen oder unnötig viel testen, wo eine Einheit nun langfährt. Mit der optischen Kennung vorab, kann ich mich gleich umentscheiden, wenn ich z.B. weiß, daß Felder auf dieser (von ASC vorgeschlagenen) Route unter RF-Beschuß liegen oder feindliche Minen enthalten. Dann wähle ich manuell lieber eine andere Route, um meine Einheit nicht unnötig zu gefährden.
Es hat mich einiges an Knobelei gekostet, bis ich den Grund dafür gefunden hatte, warum meine Berechnungen über den Verbrauch meiner Bewegungspunkte, nicht mit denen auf dem Spielfeld übereinstimmen. Der Grund waren meine platzierten Minen, die mir zusätzlich noch 50% an BP abziehen. Davon ist aber in der Field-Info (Taste 7) weit und breit nix zu sehen. Die Info gehört definitiv noch ins nächste Release mit rein. Wenn sich ein Wrackteil auf dem Feld befindet, werden die erhöhten Movemali ja auch angezeigt. Also sollte das bei Minen ebenfalls erfolgen.
Außerdem würde mich mal interessieren, wie ihr es schafft, mitten in einem Schlachtfeld bei regem Gebrauch von Minenfeldern, die eigenen von denen des Feindes zu unterscheiden. Klar man könnte immer die Probe aufs Example machen ;) , aber das kann ja nicht Sinn eines Taktikspiels sein. Minen sind ja nicht wie in BI eigene Einheiten, sondern leider nur Feldobjekte. Also scheidet eine Farbkennung wohl aus. Kann man dann wenigstens eine Info in der Field-Info (7) mit unterbringen, die kenntlich macht, daß diese Mine mal von mir selbst platziert worden ist?
Es finden sich immer wieder Einheiten, bei denen nicht alle Infos zum "terrain access" vollständig aufgeführt sind. Als Beispiele seien hier nur mal genannt:
allen Typen von mir bekannten Troopern fehlt die swamp-Info
Termite, Nova, Coma, Vortex haben keine forest-Info
Änhliches trifft auch häufig auf die Eigenschaften railroad, small rocks usw. zu. Der Bereich scheint noch eine riesen Baustelle zu sein. In einem Taktikspiel machen sich unvollständige Informationen aber alles andere als gut. Hier sollte dringend nochmal eine Inventur stattfinden meiner Meinung nach.
Außerdem wäre zu überlegen, verwandte Terrain-Arten (Wasser) geschlossen nacheinander aufzulisten. Also von river über frozen water bis deep water alles kompakt nacheinander. Vermindert unnötig langes Suchen in der Liste, die ja doch recht umfangreich werden kann, wie ich gesehen habe.
mindestens enthalten seit Version win-asc2rc9 bis asc21a16
Es sind einige Tipp- und ein paar Textplatzierungsfehler in der Waffeninfo (siehe Anhang).
Die Spalte "ammo" könnte sicherlich noch mindestens ca. 10 Pixel mehr an Breite vertragen, damit auch dreistellige Zahlen dort genügend Platz finden.
"strenght" in "strength" korrigieren.
"unit can ahoot after moving" durch "... shoot ..." ersetzen.
Es wäre optisch schöner, wenn die Zeilen "unit can shoot after moving" und "unit can move after shooting" die gleiche Schriftgröße hätten und auch etwas rechtslastiger platziert wären, damit sie richtig in die dafür vorgesehene Textbox passen.
Level 4 Vortex In diesem Level ist es theoretisch möglich, einen Vortex zu bauen (nicht daß man ihn unbedingt bräuchte, aber wenn er schon angezeigt wird im Baumenü, sollte man ihn vielliecht auch bauen können, oder?). Theoretisch deshalb, weil man dafür über 10000 Energie benötigt. Man hat aber nur die Möglichkeit, 9000 Einheiten Energie zu speichern und damit ist es unmöglich ihn zubauen. Vermutlich habt ihr auch hier erst kürzlich den Vortex bei den Baukosten etwas raufgesetzt und dieses Level noch nicht angepasst.
Ich hoffe, Grom kann bei den Sounds eventuell noch etwas experimentieren, denn ich bin kein Soundbastler - sorry. Aber warum kann ASC den Sound auch bei RF nicht immer korrekt stoppen? In anderen Situationen kann ASC den Bewegungssound doch auch mitten drin unterbrechen (bei sehr kurzen Bewegungen z.B.). Warum ist das hier nicht möglich?
zu 6. ein letztes Mal: Mein ursprünglicher Wunsch war doch ganz simpel - so schien mir zumindest. :) Was spricht dagegen (außer eventuell zu viel Programmieraufwand), bei Anwahl eines Gegners das UnitInfo-Panel auch mit den entsprechenden Farbwerten des Gegners anzuzeigen. Spiele ich für Rot und wähle auf dem Spielfeld einen blauen Gegner an - werden bisher leider auch im UnitInfo-Panel z.B. die Hintergründe der "levels of height" immer auch in rot statt in blau des Gegners angezeigt. Mehr wollte ich doch eigentlich gar nicht - nur das sich das eben entsprechend mitändert. Und das scheint mir doch eher deine Baustelle zu sein.
Wenn ich den Rest deiner Aussage richtig deute, muß ich mich dafür mit CVS beschäftigen - und womöglich auch noch programmieren können. Das ist noch 'ne Nummer zu hoch für mich. Ich könnte da höchstens im Rahmen meiner Möglichkeiten meine Unterstützung anbieten.
Kann hier jemand mit CVS umgehen und weiß, was man in der unitinfo.ascgui dort dafür ändern müßte? GAMER kannst du sowas sogar? Schließlich war das mit dem zusätztlichen Spielernamen ja dein Wunsch. ;)
zu den Sekunden auch ein aller letztes Mal:
In Antwort auf:Aber wenn es zu lange ist, dann wird dort halt noch Text zu einer Situation angezeigt, wenn man im Spiel schon wieder ganz woanders ist. Das finde ich auch nicht gut.
Sehe ich ein. Aber... Ich habe es nochmal überprüft und ich kann keine Situation finden, wo der Text zu lange eingeblendet werden könnte. Es gibt doch nur 3 Möglichkeiten, die der Spieler in dieser Situation hat:
1. Er behält den Mausknopf weiterhin gedrückt, bis die Zeit (derzeit 3 sec) abgelaufen ist, danach verschwindet der Text von allein. (Hier will der Spieler aber bewußt die Zeit ausnutzen)
2. Er verläßt den Angriffsbutton (vor Zeitablauf) mit einer Mausbewegung - hier wird der Text in der Stauszeile immer sofort ausgeblendet - egal ob 3 oder mehr Sekunden eingestellt sind.
3. Er läßt den Mausknopf los und aktiviert damit den Angriff. Hier bleibt der Text bis zum Ende der Kampfanimation in jedem Fall in der Stauszeile stehen - egal ob er sofort auf Angriff geht oder erst nach einer Minute.
Wo wäre jetzt eine Situation, wo der Text noch angezeigt werden könnte, der Spieler aber schon ganz woanders ist? Wenn wir uns auf 5 Sekunden einigen könnten, gebe ich mich aber des Friedens wegen geschlagen. :) (Von der Logik her könnten wir aber dort auch 3 Stunden eintragen und es würde keinen stören...)
Hiermit laß ich's dabei bewenden, bevor ich noch als Erbsenzähler verschrien werde. MAnche Dinge möcht ich aber eben gern zu Ende ausdiskutieren - besonders wenn ich das Gefühl habe, daß man bisher aneinander vorbeigeredet hat. Und wenn durch solche Mißverständnisse manche (schönen) Dinge nicht das Licht der Welt erblicken würden - wär's doch schade drum. :)
Oh, der Meister persönlich meldet sich zu Wort - und dann gleich so ausführlich und gründlich - da macht das Testen (und Spielen natürlich) doch gleich noch viel mehr Spaß. Vorab schonmal Danke, daß du gleich so viele Sachen prompt umgesetzt hast. Dann können wir ja bald die Final freigeben.. ;)
Ein wenig Nachhaken und ein paar Kommentare möcht' dann aber doch nochmal loswerden:
zu 1) Okay, kann ich nachvollziehen, wenn du den Fehler nicht reproduzieren kannst, sieht's mit dem korrigieren natürlich schlecht aus - nicht weiter tragisch. Nur Interesse halber: Auf was für einem System hast du getestet?
zu 4) Ein besseren Sound habe ich so spontan nicht parat, werde aber mal Augen und Ohren offen halten...
Ich hatte unter 4. aber auch noch einen kleinen Soundbug angesprochen. Zu dem hast du leider nichts gesagt. Ich habe daher nochmal einen Spielstand (siehe Anhang) generiert, mit dem es reproduzierbar und damit für dich auch nachvollziehbar sein sollte.
Es scheint ein recht häufiges Problem zu sein: Sobald eine Einheit sich bewegt und unter RF-Beschuß kommt, kann es passieren (leider nicht jedes mal - woran auch immer das liegen mag), daß der Bewegungssound 3 mal hintereinander abgespielt wird. Passiert im Spielstand gleich 2 mal mit der gegnerischen TERMITE-Einheit und bei einem Sniper ebenso.
Der TERMITE ist im Spielstand gleich mit dem Cursor fokussiert und im beigefügten Bild mal markiert (das Bild entstand aber nach Rundenende). Du brauchst den Spielstand nur einladen und auf Zugende klicken. Falls es relevant sein sollte: Die Attack-Dialog Zeiten bei mir sind eingestellt auf: PreWait: 200 Animate: 400 PostWait: 30
zu 5) Gut, schau ich mir an. Eine Nachricht in der Statuszeile, wenn kein Wrackteil in der Nähe ist, hälst du nicht für angebracht? Ich ging davon aus - da diese Routine bei anderen Einheiten auch verwendet wird, daß der Aufwand nur minmal wäre, aber letztlich kannst du das besser beurteilen.
zu 6) Grundsätzlich stimme ich dir zu, was die Farbgebung betrifft. Auch weil jetzt wesentlich mehr Farbtöne zur Auswahl stehen, sollte es weit weniger Verwechslungsmöglichkeiten geben.
Das Problem ist für mein Empfinden, daß bei der doch recht geringen Größe der Einheiten, die Farbtöne sehr filigran gezeichneter Einheiten - wie z.B. Kampfhubschrauber oder meinetwegen auch Trooper - auf dem Spielfeld oft kaum noch zu erkennen sind. Da helfen auch die besten Farben manchmal nichts (wenn man die Einheit nicht komplett in Spielerfarben malt, was der Optik/dem Realismus sicher nicht zuträglich ist).
Und genau für diese Fälle eine zusätzliche Orientierung zu haben, wäre eben hilfreich. Was hälst du denn von GAMERs Vorschlag, die beiden senkrechten Farbmarkierungen (rechts neben den Ammo-Slots) etwas breiter zu machen und immer diese bei Anwahl eines Gegners immer mitzuaktualisieren? Diese Anzeige ist ja schon vorhanden, müßte nur etwas breiter gestaltet werden, um auch von Nutzen zu sein. Das dürfte doch ein guter Kompromiß sein.
GAMER schlug außerdem vor, den Spielernamen noch irgendwo mit einzublenden (direkt sichtbar oder meinetwegen auch als Popup). Was hälst du davon?
zu 7) Hier hast du dich anscheinend getäuscht. ;) Jetzt sind es schon 4, die gerne diese Funktion (wieder) hätten. Wenn du noch nicht überzeugt bist, dies in ASC 2.1 einzubauen, vielleicht melden sich ja noch ein paar (<- Hallo, ja ihr seid gemeint!), um dich umzustimmen...
zu 8) Okay, soweit akzeptiert, was den Aufwand angeht. Warum müssen es aber unbedingt nur 3 Sekunden sein - warum nicht 10 z.B.? Warum an der Stelle so knauserig und den Komfort so einschränken? Das kann ich nicht ganz nachvollziehen.
P.S.: Bin neugierig: Was hat es für ein Hintergrund, daß es ValHaris hier zweimal gibt?
Level 4 MG Tower ohne RF Rechts oben - direkt beim Solarkraftwerk - gibt es einen MG Tower des Gegners, beim dem nicht das RF aktiviert ist. Absicht, weil sonst die Eroberung zu schwer wäre, oder doch nur vergessen, RF auch bei diesem MG Tower zu aktivieren?
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
04.07.2008 16:13
