Seite 1 von 1

[FIXED] Overflow(?) bez. Stell. Lager & zahlreiche Sys

Verfasst: Donnerstag 7. Juni 2012, 21:07
von Andi47
Wenn ich SEHR viele Systeme kolonisiert / erobert habe (ich habe nicht gezählt, wie viele das sind), scheint es bei der Berechnung der maximal aus dem Stellaren Lager entnehmbaren Ressourcen einen Overflow o.ä. zu geben, jedenfalls war das Maximum plötzlich nicht mehr bei 20.000 sondern bei 3.000 Ressourceneinheiten.

Zu den angehängten Spielständen: In Runde 337 hat das Stellare Lager noch normal funktioniert, dann hab ich ein paar Systeme kolonisiert, und in Runde 338 ist das Maximum nur noch bei 3000.

(im aktuellen Spiel nehme ich an, dass sich der Bug in Kürze wieder selbst "behebt", da ich gerade fleißig am kolonisieren bin. Trotzdem ist es unschön, wenn ich größere Mengen an Ress. ins Stellare Lager verschiebe, um sie bei Bedarf schneller ins entsprechende Verteilersystem verschieben zu können, und dann kann ich das Zeug plötzlich nur noch in kleinen Portionen rausholen)

Re: Overflow(?) bez. Stell. Lager & zahlreiche eigene System

Verfasst: Donnerstag 7. Juni 2012, 21:53
von rainer
hast Recht, ist entweder ein Bug oder ein technisches Limit

konnte die sav nur mit 45x30 Mod.exe aufrufen, habe bei 100 aufgehört zu zählen :( ... unter Geheimdienst-Info standen 253 Systeme 8) und bei den ca. 5 neu kolonisierten System ist wohl der Datentyp (hört wohl bei 256 auf) übergelaufen...

...3000 ist dann wohl die Untergrenze für's Systemlager

mal schauen, was die Programmierer sagen, ob der Datentyp leicht umzubauen ist (und ob es das überhaupt ist :wink: ): EDIT: vll. reicht auch, die Abfrage umzubauen...naja, wäre natürlich unsauber...)

..ich persönlich bin ja begeistert, wenn BotE noch läuft, wenn es so "bis zum Rand des möglichen" ausgereizt wird...da ist ein 3000er Limit noch gut, aber sicherlich auch turbo ärgerlich

Re: Overflow(?) bez. Stell. Lager & zahlreiche eigene System

Verfasst: Freitag 8. Juni 2012, 07:13
von Andi47
rainer hat geschrieben:hast Recht, ist entweder ein Bug oder ein technisches Limit

konnte die sav nur mit 45x30 Mod.exe aufrufen, habe bei 100 aufgehört zu zählen :( ... unter Geheimdienst-Info standen 253 Systeme 8) und bei den ca. 5 neu kolonisierten System ist wohl der Datentyp (hört wohl bei 256 auf) übergelaufen...

...3000 ist dann wohl die Untergrenze für's Systemlager

mal schauen, was die Programmierer sagen, ob der Datentyp leicht umzubauen ist (und ob es das überhaupt ist :wink: ): EDIT: vll. reicht auch, die Abfrage umzubauen...naja, wäre natürlich unsauber...)

..ich persönlich bin ja begeistert, wenn BotE noch läuft, wenn es so "bis zum Rand des möglichen" ausgereizt wird...da ist ein 3000er Limit noch gut, aber sicherlich auch turbo ärgerlich
In der darauffolgenden Runde hatte ich dann wieder ein Limit von 6000 (nach 3 neu kolonisierten Systemen). D.h. anscheinend wird 258 (255+3) als "drei" und 261 (255+6) als "6" interpretiert. (Short-Integer (wenn ich den Namen der Variable noch richtig in Erinnerung habe; ist eine Weile her, dass ich selbst Programme gestrickt habe) kann 256 Werte annehmen, nämlich von 0 (null) bis 255) Da ich derzeit zahlreiche Kolonieschiffe am Werken hab, und somit im Moment 3-5 Systeme pro Runde kolonisiere, nehme ich an, dass das Limit bald wieder bei 20.000 liegt.

BTW: Wieso wird der Variablentyp Short-Integer im Zeitalter von "Gigabyte RAM" eigentlich noch verwendet?? (BTW: Civilization 2 hatte denselben Bug (max. 256 Städte), und auch bei diesem Spiel bin ich regelmäßig an diese Grenze gestoßen. Allerdings war RAM damals noch ein knappes Gut, und die Verwendung von Short-Integers daher für mich verständlich)

Re: Overflow(?) bez. Stell. Lager & zahlreiche eigene System

Verfasst: Freitag 8. Juni 2012, 16:09
von Anonymissimus
Dass neue Rechner heute nur so platzen vor RAM ist absolut kein Grund beim Speicheranspruch großzügig zu sein. BotE läuft auf meinem alten Rechner mit 256MB offenbar nicht mehr so richtig gescheit. Ja, ich bin open source Spiele gewohnt, die eben anders sind als die komerziellen, welche im Gegensatz dazu offenbar immer die neueste Grafikkarte etc benötigen. Da steckt wohl auch dahinter, dass der Kunde gezwungen sein soll neue hardware zu kaufen. Selbes Problem mit win 7, das ja schon im idle Zustand direkt nach Hochfahren 500-600MB RAM verbraucht hab ich gelesen. Mein Ubuntu 12.04, zwei Jahre jünger als 7, übrigens nur 350-400MB.

Re: Overflow(?) bez. Stell. Lager & zahlreiche eigene System

Verfasst: Freitag 8. Juni 2012, 16:23
von Malle
ich finds bei den Programmiersprachen auch immer dämlich, dass sie Variablen wie Restklassen behandeln, ich würde mir eine dynamischere Variablentypisierung wünschen. Gibts das mittlerweile eigentlich? Bin da nicht mehr so uptodate bzw. drin im OOP..

Re: Overflow(?) bez. Stell. Lager & zahlreiche eigene System

Verfasst: Freitag 8. Juni 2012, 17:17
von HerrderGezeiten
Ich kann es mir grad etwas schlecht vorstellen, das BotE so einfach zu hohe Leistungsanforderungen zusammen bringen kann. :|

Zumindest im jetzigen Zustand, ohne 3D Kampf ein Ruckeln?
Mit den Ram um sich schmeißen ohne Sinn, muß man wirklich nicht aber das müste bei mir schon die dritte Generation PC sein die es sicher schaffen sollte,....

-> Ich gehe mal von Diablo2 (Jahr 2000) aus, läuft oben bei mir am Urgestein eines PC`s noch, möglich ist vieles aber ich glaub BotE sollte der auch schaffen.
(immerhin mehr als 12 Jahre ist schon ein beachtliches Alter)

Re: Overflow(?) bez. Stell. Lager & zahlreiche eigene System

Verfasst: Freitag 8. Juni 2012, 17:54
von Anonymissimus
Mir scheint dass BotE insbesondere viel RAM braucht, während der Kartengenerierung und der Rundenberechnung. Es hat halt keiner da je viel optimiert nehm ich an. Der Rechner hat 700Mhz, eine normal release BotE läuft schon, aber ich merke dass die Rundenberechung doch recht langsam ist, dauert einige Sekunden. XP schaufelt deutlich sichtbar viel in die Auslagerungsdatei, also 256MB RAM ist derzeit sicher eine Untergrenze, und nicht zu empfehlen. Dabei hab ich die Installation bereits soweit wie möglich optimiert.

Haben wir schon eine Kathegorie Systemanforderungen im wiki oder so ? Das wäre doch was dafür.

Re: Overflow(?) bez. Stell. Lager & zahlreiche eigene System

Verfasst: Samstag 9. Juni 2012, 13:30
von rainer
in der readme.txt steht:

Code: Alles auswählen

1.2 System requirements
CPU with at least 1 GHz
at least 256 MB RAM
170 MB of free diskspace
Soundcard
WindowsXP(tm), Windows Vista(tm), Windows 7(tm) operating system
or Linux with WINE
(für die 5.1 hatte Puste noch 128 MB RAM angegeben.)

die (RAM-)Anforderungen sind also relativ minimal (dass short integer bei 256 aufhört, ist ja ganz ein andere Sache)

ja - mit steigender Rundenzahl braucht die Rundenberechnung länger - ich als Laie habe das darauf geschoben, dass mehr Systeme/Planeten, Gebäude, Schiffe usw. zu berechnen sind.
Inwiefern hier der Netzwerkcode eine Rolle spielt/bremst...keine Ahnung

habe jetzt mal geschaut (Win7 64 bit):
- BotE-Start Game-Fenster *32: 11.096 k (11) (das *32 heißt wohl, dass BotE in einem 32bit-Task läuft)
- Load Game-Fenster 17.744 k (17)
- Neues Spiel Terraner gestartet (151)...ich glaube ja, dass BotE auch dafür RAM braucht, um die Grafiken (z.B. Gebäude, Schiffe, Skins, Buttons usw.) im Speicher zu halten - das macht schonmal eine ganze Menge aus - die folgenden Zahlen können daher differieren, weil ich nicht alle Fenster aufgeklickt habe

- SaveGame Runde 623 geladen (ca. 169) aus http://birth-of-the-empires.de/wiki/ind ... 8.21.21.29 (344 Systeme, nicht alle bewohnt)

- ok, bei Runde beenden springt der Speicher erstmal auf 190 (20 MB mehr), dann habe ich noch gesehen, dass kurz vor der nächsten Runde es nochmal um 30 MB hochspringt (EDIT: das liegt wohl am LZMA-Packalgorithmus für die auto.sav) und dann wieder knapp oberhalb des Ausgangswertes (169+3) landet

- werden eigentlich die Sounds auch im Speicher gehalten, als ogg komprimiert oder unkomprimiert

naja - wie auch immer....BotE ist sicher kein Spiel, was PC's überfordert (ältere PC's mal ausgenommen). Klar, die Zeiten für "Runde beenden" könnten schneller werden, wobei hier wohl auch nach langer Optimierung nur relativ wenig Zeit rausschauen wird