[FIX20130711] Bug im Minorrace-Editor

Bugs aus der Alpha7 Version von BotE können uns in diesem Bereich mitgeteilt werden
Steffen
Unteroffizier
Unteroffizier
Beiträge: 72
Registriert: Mittwoch 13. März 2013, 17:25

[FIX20130711] Bug im Minorrace-Editor

Beitrag von Steffen » Dienstag 9. Juli 2013, 16:46

Vergleicht man die Zahlenwerte in der 'MinorRaces.data' (nach einer Änderungen der 'own properties' im 'BotE-MinorRaceEditorV1.5.exe') so ist lediglich die 4 (industrial) mit den Angaben in der Wiki identisch. Alle anderen Zahlen stimmen nicht überein.
Ich nehme an die Feldzuordnung im Editor ist durcheinandergeraten. Die von mir überprüften Rassen passen zum Wiki, aber ein paar Merkwürdigkeiten im Verhalten einiger Minors könnten bereits dadurch verursacht sein. Ich habe die Angaben im Spiel bei einem Minor überprüft. Der Fehler liegt erstmal im Editor, nicht in der Wiki.

Nr. __ Editor __ Wiki
_1 _ warlike ___ financial
_2 _ hostile____ warlike
_3 _ financial __ farmer
_4 _ industrial __ industrial
_5 _ sneaky ___ secret
_6 _ pacifist ___ reasearcher(scientific)
_7 _ scientific___ produccer
_8 _ secret ____ pacifist
_9 _ soloing ___ sneaky
10_ producer___ soloing
11_ agrarian ___ hostile

1. Mit dieser Tabelle kann man sich als Workaround erst mal behelfen.

2. Der Fehler im Editor, sollte sich recht rasch korrigieren lassen. Da braucht man keine großen C-Kenntnisse, Es müssen wahrscheinlich nur ein paar Reihenfolgen vertauscht werden. Das läßt sich ebenfalls mit der obigen Tabelle erledigen.
Am aller einfachsten geht es, wenn man nur die Reihenfolge Texte(/Bezeichnung der Felder in die die Häkchen gesetzt werden) abändert, so dass sie zu den Nummer der 'MinorRaces.data' passen. (Von oben nach unten wäre die richtige Reihenfolge der Texte/Feldbezeichnungen im Editor: farmer, financial, hostile, industrial, pacifist, producer, soloing, scientific, secret, sneaky, warlike)
Das Neucompilieren ist da das schwierigste. Neues Editorrelease bitte hier mit ranhängen, nicht nur in der Wiki. Danke.
Zuletzt geändert von Steffen am Mittwoch 10. Juli 2013, 11:57, insgesamt 4-mal geändert.

Benutzeravatar
master130686
Kommodore
Kommodore
Beiträge: 1905
Registriert: Montag 21. August 2006, 16:01
Kontaktdaten:

Re: Mutmaßlicher Bug im Minorrace-Editor

Beitrag von master130686 » Dienstag 9. Juli 2013, 18:46

Ja, das ist leider nicht neu. Diesen Fehler gibt es schon seit der Einführung von mehreren Rasseneigenschaften und der damit einhergegangenen Anpassung des MinorRaceEditors. Leider hatte die Anpassung bisher keine sehr hohe Priorität (bzw. ist vermutlich auch irgendwann vergessen worden).
Verfallen wir nicht in den Fehler, bei jedem Andersmeinenden entweder an seinem Verstand oder an seinem guten Willen zu zweifeln. (Otto Fürst von Bismarck)

Steffen
Unteroffizier
Unteroffizier
Beiträge: 72
Registriert: Mittwoch 13. März 2013, 17:25

Re: Bug im Minorrace-Editor

Beitrag von Steffen » Mittwoch 10. Juli 2013, 12:07

Ich habe meinen obigen Beitrag gerade noch mal überarbeitet. Wenn man nur die Feldbeschreibungen in der Anzeige abändert, ist das in fünf Minuten erledigt. Also: niedrige Priorität kann bei diesem geringen Zeitaufwand als Entschuldigung nicht mehr gelten.

Benutzeravatar
master130686
Kommodore
Kommodore
Beiträge: 1905
Registriert: Montag 21. August 2006, 16:01
Kontaktdaten:

Re: Bug im Minorrace-Editor

Beitrag von master130686 » Mittwoch 10. Juli 2013, 19:59

So ziemlich gleich hab ich das damals auch schon gesagt...
Verfallen wir nicht in den Fehler, bei jedem Andersmeinenden entweder an seinem Verstand oder an seinem guten Willen zu zweifeln. (Otto Fürst von Bismarck)

Benutzeravatar
rainer
Vizeadmiral
Vizeadmiral
Beiträge: 2897
Registriert: Mittwoch 12. September 2007, 10:57

Re: Bug im Minorrace-Editor

Beitrag von rainer » Donnerstag 11. Juli 2013, 14:42

also ich hab nicht 5 min gebraucht, eher 3 Std (ein anderer hätte wohl 5 min. gebraucht :wink: )

.... bitte mal den ausprobieren (übernehme keine Garantie) http://birth-of-the-empires.de/wiki_fil ... orV1.6.zip

ich bin mir nicht sicher, ob 10 = soloing oder 11 = hostile überhaupt von BotE.exe verwendet werden (oder nur für Majors) - darum habe ich es mal aus dem Editor rausgenommen...es hat eh kein Minor 10 oder 11)


das habe ich noch ins Wiki geschrieben, so als Hintergrund-Info:
Last version is V1.6 of RaceEditor. This "race editor" is planned to get a second sheet "Majorraces" but it isn't there yet.

At the moment "race editor" is just a GUI getting Minorraces-Sheet from "MinorRaceEditorDlg.cpp" which is used by "MinorRaceEditor" (not updated to V0.90).

Benutzeravatar
master130686
Kommodore
Kommodore
Beiträge: 1905
Registriert: Montag 21. August 2006, 16:01
Kontaktdaten:

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von master130686 » Donnerstag 11. Juli 2013, 14:56

Bei mir geht der nicht, da kommt immer eine Fehlermeldung (siehe Bild).
ich bin mir nicht sicher, ob 10 = soloing oder 11 = hostile überhaupt von BotE.exe verwendet werden (oder nur für Majors) - darum habe ich es mal aus dem Editor rausgenommen...es hat eh kein Minor 10 oder 11)
Zumindest HOSTILE wird definitiv verwendet, und auch bei SOLOING bin ich mir ziemlich sicher. Als damals die Mehrfacheigenschaften eingeführt worden hatte ich selbst nicht nur die Merhfacheigenschaften "vergeben", sondern diese auch im Editor eingetragen (und etwas später auch nochmal angepasst). Wenn jetzt Fehler drin sind, dann hat irgendwer vor dem Release der aktuellen MinorRaces.data was verklickt (vermutlich durch o.g. Fehler in der Bezeichnung).


EDIT:
Im Anhang mal meine damals erstellte Excel-Tabelle. Alle Minors sollten ihre Eigenschaften entsprechend dieser Liste haben.
Dateianhänge
MinorRace-Mehrfacheigenschaften.rar
(6.7 KiB) 112-mal heruntergeladen
Fehlermeldung.jpg
Fehlermeldung.jpg (16.96 KiB) 5755 mal betrachtet
Verfallen wir nicht in den Fehler, bei jedem Andersmeinenden entweder an seinem Verstand oder an seinem guten Willen zu zweifeln. (Otto Fürst von Bismarck)

Steffen
Unteroffizier
Unteroffizier
Beiträge: 72
Registriert: Mittwoch 13. März 2013, 17:25

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von Steffen » Donnerstag 11. Juli 2013, 18:00

In der aktuellen MinorRaces.data sind tatsächlich keine Einträge bei hostile (agrarian) und soloing (producer) vorhanden. Beide Begiffe können entweder nur bei Majors oder nur bei Minors sinnvoll eingesetzt werden. Denn aus hostile + hostile werden keine Freunde und aus soloing + soloing keine Partner. Allerdings machen beide Begriffe bei den derzeitigen Majors keinen Sinn, bei den Minors schon.
Sollte nicht bereits an spätere Mediors und aller Rassen Feind KI-Majors gedacht werden, sollten sollten sie bei den Minors wieder rein. Wenn sie im Programmcode nicht verwendet werden, ist das ein Mangel. Die Hanuhnr kaufen sich die Fieslinge schneller ein als man gucken kann. Die Fieslinge sollten bei den Hanuhr aber deutlich wiederspenstig sein, egal wieviel geboten wird. Unter V6.3 war das noch der Fall.
Ich hatte vorgestern mit Original Race-Datas als Terraner in Runde 88 nur 3 Minors eingemeindet [Trotz 6 Stufe-3 Kolonieschiffen beim Start, Reichweite 3 (lediglich Geschwindigkeit auf 1) um Minorplaneten zu terraformieren] - die Hanuhr hatten bereits 13 eingemeindet. Ich habe mir in der MajorRace.data noch vier weitere Eigenschaften gegeben und die Zahl der Kolonieschiffe auf 8 erhöht. Und exakt das gleiche Spiel noch einmal gestartet. Jetzt habe ich in Runde 88 : 8 Minors, die Hanuhr 11. Da muß irgend was gegenüber V6.3 ordentlich verrutscht sein. Da gab es so etwas extremes nicht. (Map 40x30, Stardensity 65, Minordensity 30, RANDOMSEED=1371237739)

Benutzeravatar
master130686
Kommodore
Kommodore
Beiträge: 1905
Registriert: Montag 21. August 2006, 16:01
Kontaktdaten:

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von master130686 » Donnerstag 11. Juli 2013, 18:31

Beide Begiffe können entweder nur bei Majors oder nur bei Minors sinnvoll eingesetzt werden. Denn aus hostile + hostile werden keine Freunde und aus soloing + soloing keine Partner. Allerdings machen beide Begriffe bei den derzeitigen Majors keinen Sinn, bei den Minors schon.
Sollte nicht bereits an spätere Mediors und aller Rassen Feind KI-Majors gedacht werden, sollten sollten sie bei den Minors wieder rein.
Die Eigenschaften basieren auf den Rassenbeschreibungen der Minors. Welcher Minor (oder Major oder später Medior) nun aber welche Eigenschaft(en) hat, hat nichts damit zu tun (und sollte es auch nicht) ob die Eigenschaft(en) mit irgendwem/-was kompatibel sind oder ob es "nützlich" ist oder nicht. Es hängt, wie gesagt, nur davon ab wie die Rasse halt "ist".
Die Fieslinge sollten bei den Hanuhr aber deutlich wiederspenstig sein, egal wieviel geboten wird.
Aufgrund ihrer Eigenschaft(en) sollten sie das bei jedem.
Ich hatte vorgestern mit Original Race-Datas als Terraner in Runde 88 nur 3 Minors eingemeindet [Trotz 6 Stufe-3 Kolonieschiffen beim Start, Reichweite 3 (lediglich Geschwindigkeit auf 1) um Minorplaneten zu terraformieren] - die Hanuhr hatten bereits 13 eingemeindet.
Hier hängt es vor allem sehr stark davon ab welche Minors es jeweils sind (primär Meinung ggü dem Major und Bestechlichkeit) und wieviele im jeweiligen Einflussgebiet sind.
Verfallen wir nicht in den Fehler, bei jedem Andersmeinenden entweder an seinem Verstand oder an seinem guten Willen zu zweifeln. (Otto Fürst von Bismarck)

Benutzeravatar
rainer
Vizeadmiral
Vizeadmiral
Beiträge: 2897
Registriert: Mittwoch 12. September 2007, 10:57

[FIX20130711] Bug im Minorrace-Editor

Beitrag von rainer » Donnerstag 11. Juli 2013, 18:38

ich habe jetzt nochmal eine V1.6 hochgeladen (Datei-Uhrzeit 19.30) http://birth-of-the-empires.de/wiki_fil ... orV1.6.zip - bitte wieder prüfen, ob die korrekt arbeitet/schreibt -> Danke an Euch :)

jetzt suche ich noch nach den verschwundenen Mehrfach-Eigenschaften und editiere dann hier rein EDIT: habe jetzt auf die Schnelle kein Release gefunden, wo die Mehrfacheigenschaften mit drin waren, laut Changelog wäre es bei Alpha6.1 gewesen). Deine Excel-Datei ist von 2009, habe jetzt noch im Repo geschaut...ich glaube, die Einträge haben es nicht dorthin geschafft....aber jetzt dann :-))

bei mir läuft der Editor - habe aber die Fehlermeldung ergänzt, dass man auf LF achten muß (EDIT: es kann sein, dass das Spiel mit CR LF zurecht kommt, aber der Editor (noch) nicht
- entweder mittels Notepad++ die CR entfernen (Notepad++ > Bearbeiten > Format Zeilenende > Konvertiere zu Unix (LF)
- oder ich habe gerade noch eine/die englische data in den Download gepackt

Bitte auch unterscheiden zwischen dem Spiel (HOSTILE hatte Puste für seine VOIDs verwendet...das ganz sicher :-)) und diesen Thread, wo es um den Editor geht

Steffen
Unteroffizier
Unteroffizier
Beiträge: 72
Registriert: Mittwoch 13. März 2013, 17:25

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von Steffen » Donnerstag 11. Juli 2013, 21:12

@rainer:

Die Original- *.data hat an jedem Zeilenende ein [CR][LF]
0.9[CR][LF]
ADAMAR:[CR][LF]
usw.

Die mit 'BotE-MinorRaceEditorV1.5.exe' gespeicherten Dateien sind anders:
0.9[CR][LF]
ADAMAR[CR]
:[LF]
Adamanen[CR][LF]
Adamanen sind starrköpfige Händler, die ein stattliches Arsenal schlagkräftiger Schiffsklassen ihr Eigen nennen. Sie bilden ihren ehrgeizigen Nachwuchs in allen Fragen des Schiffshandels und des selbständigen Flottenmanagements aus. Ein Adamane, der etwas auf sich hält, besitzt einen vollen Hangar an Schiffen und ebenso volle Auftragsbücher. Dabei geht es nicht nur um Transport, nein, vielmehr um Eskorte und Schutz fremder Transportflotten gegen Bares oder einem Anteil an der beschützten Ware. Die Adamanen sind so etwas wie die Hilfssheriffs des Quadranten, nur mit der Ausnahme, dass man sich für gewöhnlich bis zur Selbstaufopferung auf sie verlassen kann. Ihr guter Ruf eilt ihnen bei vielen Rassen voraus. Die Unterstützung dieser erfolgreichen Ausbildung sollte uns viele Sympathiepunkte bei ihnen einbringen.[CR][LF]
Adamanen.bop[CR][LF]
50[LF]
bei den weiteren Parametern dieser Rasse gleichfalls nur [LF], erst beim nächsten Systemnamen gibt es wieder [CR][LF].
-----------
Der relevante Unterschied, der vermutlich den Fehler hervorruft dürfte:
0.9[CR][LF]
ADAMAR:[CR][LF]
in den originalen *.data
und
0.9[CR][LF]
ADAMAR[CR]
:[LF]
in deiner *.data sein, die du schon mal mit dem alten Editor abgespeichert hast hier steht der Doppelpunkt zwischen [CR] und [LF]. Wenn der neue Editor darauf achtet, kann er mit den Originaldateien nichts mehr anfangen.

EDIT: das war's wohl nicht. Ich habe mit dem 1.5 eine MinorRaces.data erzeugt, die läßt sich mit dem 1.6 Editor auch nicht öffnen. Schau mal mit Notepad++ in die von dir erzeugte Datei ob jetzt wirklich alle [CR] raus sind, sonst geht die Suche weiter. Da der alte Editor aber [CR][LF] in den Originalen lesen konnte sehe ich keinen Grund, warum der Neue es nicht kann. (Es sei denn evtl. dass du einen anderen Compiler verwendest.)

Ach so, noch eine Frage: hattest du die Datenzuordnung zu den Feldern geändert? Bei einer einfachen Änderung der angezeigeten Texte im Maskengenerator (der sollte bei Visual C und Visual Basic oberflächenmäßig identisch sein) wären es wirklich nur 5 Minuten (plus compilieren).

Benutzeravatar
rainer
Vizeadmiral
Vizeadmiral
Beiträge: 2897
Registriert: Mittwoch 12. September 2007, 10:57

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von rainer » Freitag 12. Juli 2013, 18:37

Steffen hat geschrieben:Ach so, noch eine Frage: hattest du die Datenzuordnung zu den Feldern geändert? Bei einer einfachen Änderung der angezeigeten Texte im Maskengenerator (der sollte bei Visual C und Visual Basic oberflächenmäßig identisch sein) wären es wirklich nur 5 Minuten (plus compilieren).
erstmal dazu: nachdem ich nicht so auskenne, hatte ich erstmal das gemacht:
alt:
DDX_Check(pDX, IDC_CHECKAGRARIAN, m_bProperty[2]); -> Reihenfolge "voll durcheinander ..."
DDX_Check(pDX, IDC_CHECKFINANCIAL, m_bProperty[0]);
DDX_Check(pDX,IDC_CHECKHOSTILE, m_bProperty[10]);
DDX_Check(pDX, IDC_CHECKINDUSTRIAL, m_bProperty[3]);
...
DDX_Check(pDX, IDC_CHECKSECRET, m_bProperty[4]);
DDX_Check(pDX, IDC_CHECKSNEAKY, m_bProperty[8]);
DDX_Check(pDX, IDC_CHECKWARLIKE, m_bProperty[1]);
+ */


neu:
+ //Names are not correct
+ DDX_Check(pDX, IDC_CHECKAGRARIAN, m_bProperty[0]); //value 1 = financial -> die Feldnamen habe ich nicht geändert
+ DDX_Check(pDX, IDC_CHECKFINANCIAL, m_bProperty[1]); //value 2 = warlike
+ DDX_Check(pDX,IDC_CHECKHOSTILE, m_bProperty[2]); //value 3 = AGRARIAN
+ DDX_Check(pDX, IDC_CHECKINDUSTRIAL, m_bProperty[3]); //value 4 = INDUSTRIAL
+ DDX_Check(pDX, IDC_CHECPACIFIST, m_bProperty[4]); //value 5 = SECRET
+ DDX_Check(pDX, IDC_CHECKPRODUCTIV, m_bProperty[5]); //value 6 = SCIENTIFIC
+ DDX_Check(pDX, IDC_CHECKSOLOING, m_bProperty[6]); //value 7 = PRODUCER
+ DDX_Check(pDX, IDC_CHECKSCIENTIFIC, m_bProperty[7]); //value 8 = PACIFIST
+ DDX_Check(pDX, IDC_CHECKSECRET, m_bProperty[8]); //value 9 = SNEAKY
+ //DDX_Check(pDX, IDC_CHECKSNEAKY, m_bProperty[9]); //value 10 = SOLOING - not for minors
+ //DDX_Check(pDX, IDC_CHECKWARLIKE, m_bProperty[10]);//value 11 = HOSTILE - not for minors
dass die Vertextungen der Checkboxen in der .rc-Datei sind, habe ich erst ganz am Schluß kapiert bzw. gerade eben (nach Google-Suche), weil BotE selbst nicht mit .rc arbeitet -> ich dachte, die .rc wäre ein Kompilierungsergebnis und keine Quelle...naja, wieder was dazu gelernt

https://github.com/bote-team/bote/commi ... 998c254bde

Benutzeravatar
rainer
Vizeadmiral
Vizeadmiral
Beiträge: 2897
Registriert: Mittwoch 12. September 2007, 10:57

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von rainer » Freitag 12. Juli 2013, 22:30

CR LF .. ich denke, ich weiß es jetzt :idea:

"früher" mußte vor dem Editieren immer erst mühsam die Versionsnummer (1. Zeile) entfernt werden.

"jetzt" ist da eine Prüfung: if(m_strVersion=="0.9")

wenn nur LF, dann 1. Zeile = "0.9" :!: wenn CR LF, dann 1. Zeile = "0.9CR" -> dann (bisher) die Fehlermeldung
-----------------------
so: beim Einlesen werden jetzt alle CR entfernt (war u.a. für die Doppelpunkte nach Heimatwelt nötig) und beim Schreiben nur LF gesetzt (=Standard)

beim Einlesen ist dem Editor jetzt egal, ob nur LF oder CR+LF

...jetzt muß das nur noch funktionieren....ich warte auf die nächste Fehlermeldungen :roll:

achja...hier http://birth-of-the-empires.de/wiki_fil ... orV1.6.zip (Version vom 12.7.13)

Steffen
Unteroffizier
Unteroffizier
Beiträge: 72
Registriert: Mittwoch 13. März 2013, 17:25

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von Steffen » Freitag 12. Juli 2013, 22:35

Hallo Rainer, du hast den formal saubereren Weg gewählt. Wenn du Visual C++ hast, sollte da auch Visual Studio mit einem Maskengenerator/Formulareditor dabei sein. Wenn du das Bild der Maske angezeigt bekommst, machst du einen Doppelklick auf einen der betreffenden Texte. (üblicherweise) Rechts öffnet sich dann ein Fenster mit den Parametern des Objektes. Eine der Positionen nennt sich Text. Daneben steht der Betreffende Text. Den kann man abändern. Alles weitere macht dann Visual C++. (Bzw. Visual Studio, das als Multi-Editor mitgeliefert wird.) An den Quellcode braucht man da gar nicht selber direkt dran.

Ich habe zwar in den guten alten DOS-Zeiten bis tief in die Computereingeweide mit Assembler programmiert, aber nie einen Draht zu C gefunden. Das hatte damals keine automatische Variablenspeicherverwaltung. Da war Basic flexibler und für alles was schnell gehen sollte oder mir in Basic fehlte, habe ich Assemblerunterprogramme geschrieben.

Ich hatte noch keine Zeit zum Basteln um die *.data so abzuändern um deinen Editor ans laufen zu bekommen. Und wie gesagt, ich habe keine Ahnung von C, vom Programmieren aber schon. Wenn ich aber auf die Schnelle die Reihenfolge der Felder im Formular des alten Editor mit deinem Post vergleiche, da passt meinem Bauchgefühl etwas nicht. (Mag sein es hat schon mal jemand da rumgebastelt.) Wir können aber vielleicht auch aneinander vorbeireden. Umgangssprachgebrauch geht da öfter schief. z.B. Feldname: 'IDC_CHECKFINANCIAL' ist ein Feldname --- 'financial' ist eine Feldbezeichnung/Feldtitel, ein Text zur Beschreibung des Feldinhaltes, d.h. dass was neben dem Feld im Formular als Bezeichnung angezeigt wird. (Und steht in einem eigenen Feld der Gattung 'Label') Diese Bezeichnung ist von dem zugehörigen Eingabefeld meist völlig losgelöst.
Hast du die Checkboxen auf dem Formular verschoben? Wenn die Reihenfolge mit der auf dem Formular im alten Editor übereinstimmt, dann sollte 'm_bProperty[1] ' idealerweise die Reihenfolge der Felder und Wert – 1 bedeuten. Da gibt es aber entweder noch die Stelle im Code in der die Checkboxs-Gruppe (Titel im Formular: own properties) ausgewertet wird, um die Werte in die Datei schreiben zu können. (und auch die zum lesen.) Ich vermute ohne C-Kenntnisse dass 'm_bProperty[1] ' der Wert des Feldes ist. Die Reihenfolge der Felder im Code im geposteten Codeausschnitt sollte keine Auswirkung auf die Bildschirmanzeige haben. Die muss woanders hinterlegt sein. Wenn die zwischendrin oder nachträglich geändert wurde passt es nicht. Dein Codeausschnitt gibt leider nicht genügend Informationen für eine Beurteilung. Wenn sonst alles sauber gebaut wäre, müsste es so passen, da aber nicht alles sauber war … habe ich Bedenken.
Übrigens, wenn man einen Editor benutzt, der nicht selber die Schreibweise korrigiert, sollte man die Konventionen einhalten: z.B. nach einem Komma immer eine Leerstelle. Wenn da vorher keine war, heißt das, dass die auch nicht mit dem Visual Studio erstellt wurde. (Es wurde also schon mal rumgebastelt.) Nicht jeder Compiler schluckt jede Abweichung in der Schreibweise, und der Code lässt sich schlechter überfliegen, weil das menschliche Auge an allen Abweichungen hängen bleibt. Wenn du öfter mal 100 Seiten Quellcode durchgehen musstest, wirst du jedem dankbar sein, der sich daran hält. Ist also nicht bös gemeint, nur leidgeprüft. Ich mag Microsofts Monopole ja nicht so sehr und dass die ständig alles anders glauben machen zu müssen nervt, aber wenn man es sich leisten kann, so ein Visual Studio Professional Edition ist schon eine schöne Sache. Leider hat es bei mir zuletzt vor über 10 Jahren dafür gereicht. Die heutigen Express Versionen sind zwar verglichen damit recht umständliche Krücken, aber kostenlos. Und für kleine Sachen wie die Editoren allemal komfortabel genug. Wenn du eine C-Version ohne einen vergleichbares Editorsystem mit integrierten Formulareditor hast, dann bist du dazu verdammt, dir die Augen wundzusuchen.

Benutzeravatar
master130686
Kommodore
Kommodore
Beiträge: 1905
Registriert: Montag 21. August 2006, 16:01
Kontaktdaten:

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von master130686 » Samstag 13. Juli 2013, 02:24

Bei mir geht der neue Editor. Allerdings habe ich gerade festgestellt, dass die MinorRaces.data offenbar eine alte Version sein muss, denn hier haben alle Minors nur maximal eine Eigenschaft. Und ich hatte ja, wie schonmal gesagt, damals selbst die Änderungen mit den mehrfachen Eigenschaften vorgenommen.
Verfallen wir nicht in den Fehler, bei jedem Andersmeinenden entweder an seinem Verstand oder an seinem guten Willen zu zweifeln. (Otto Fürst von Bismarck)

Benutzeravatar
Vuto
Flottenkapitän
Flottenkapitän
Beiträge: 515
Registriert: Donnerstag 15. Juli 2010, 17:04

Re: [FIX20130711] Bug im Minorrace-Editor

Beitrag von Vuto » Samstag 13. Juli 2013, 08:20

Deine MinorRaces.data ist hier(intern), sie hat es nie bis zu Codeplex geschafft.

Ich hoffe es passiert uns nicht zu oft, dass es vergessen wird fertige Sachen zu übernehmen. :twisted:

Antworten

Zurück zu „Alpha7-Bugs“