Custom-Maps: Größenbegrenzung unter Linux!

hi, also die sharqi final laufen beide versionen nicht auf meinen server. hat das nochjemand bis jetz?? mein server ist von xg1, also linux läuft mit version 1.5 und ace 1.7, wenn da nochjemand probleme hat bitte mal schreiben. ich bin der meinung das es an der dateigröße liegt. die beta 1 war 59mb, bet2 51 und final 53 und 54 mb..




---edit by w@Lly: Original-Beiträge herauskopiert aus: Map Sharqui Peninsula (mp_sharqi) ---

Getestet: Final mit Ace 1.7 Gametype DM und WAR, Linux

Ergebnis: Server crashte sofort beim Mapaufruf. Keine Fehlermeldung im Server-Log zu finden.

Ja das ist glaub ich n allgemeines Problem bei dieser Map, gibt hier schon n Thread dazu im IW Forum. Wäre schade wenn er das nicht hinbekommen würde...

IW-Thread-Sharqi

Zitat:

Original von MikeTNT
Getestet: Final mit Ace 1.7 Gametype DM und WAR

Ergebnis: Server crashte sofort beim Mapaufruf. Keine Fehlermeldung im Server-Log zu finden.

Hab ich gestern auf die schnelle reingestopft, WAR, tut feini. ACE 1.7, allerdings Windows.

Ich teste mal schnell DM...

ToM

Nachtrag: Mit Windows tut se in allen Gametypes. Dürfte wohl ein Linuxproblem sein? Muss mal den Thread im IWN ansehen.

@mike is genau was ih meine server chrasht und geht auf die erste map in der rotation zurück. wie gesagt hab den verdacht es liegt an der größe der map. alles was über 51 mb ist ist nicht machbar. wobei ih das nicht untermauern kann da ich keine map weiter gefunden habe die mehr wie 51mb hat..

Hab sie auch hier mal auf den aktuellen Stand gebracht:
Maptest Sharqui Peninsula

Die beiden Vorgänger hab ich aber trotzdem mal noch nicht vom Server gekickt, scheinen ja mehr Leute Probleme mit zu haben...

also es ist wie ich sagte liegt an der größe, bei dem link von Flashbull wird es beschrieben:

Zitat:

Loading fastfile mp_sharqi_day
Error: Need 294240 more bytes of ram for alloc to succeed
OUT OF MEMORY! ABORTING!!! (universal/physicalmemory.cpp:625)

so scheint die obergrenze bei linux bei 51mb zu liegen alle maps die größer sind werden nicht mit dem linux 1.5 laufen.

"... Need 294240 more bytes of ram for alloc to succeed"

Ähnliches gab es bei CoD1 schon, konnte man umgehen, in dem man die hunkmegs hochgeschraubt hat - nur leider gibt´s diese DVAR bei CoD4 nicht mehr - oder hat schon jemand einen "Ersatz" dafür gefunden?

Die Meldung klingt für mich danach, daß er nicht genug Arbeitsspeicher für die Map zur Verfügung hat...

jup, die letzten 2sätze der console im miniadmin:
entfernen der fastfiles mp:blabla
loading fastfile mp_sharqi_day

und dann ist schluß..

Gibt es da schon was neues was die Server Admins machen können das auch größere Maps laufen auf Linux?

Zumindest nicht von Ryan´s Seite aus...

tjo hab heute beide versionen bei xg1 (linux) getestet --> negativ....

unter linux läuft nur die beta2..

Aus gegebenem Anlass:

Zitat:

48900 files in iwd files
Unloaded fastfile ui_mp
Loading fastfile mp_mashtuurcity
Error: Need 1186368 more bytes of ram for alloc to succeed
OUT OF MEMORY! ABORTING!!! (universal/physicalmemory.cpp:625)

Die betroffene ff-Datei hat eine Größe von 53.347 MB *grummel*

Nachdem ich die Suche hier im Board vergeblich bemüht habe und dann eher zufällig auf die Beiträge hier bei der mp_sharki gestoßen bin, habe ich daraus einen eigenen Beitrag gebastelt.

Fakt ist, dass wohl auch weiterhin keine Maps über 51 MB Größe (nur das ff-File) unter Linux laufen.
Daran wird sich wohl auch kaum was ändern, da die meisten C-Maps ja kaum soviel Gewicht auf die Waage bringen und das "Problem" wohl eher nicht vorrangig von icculus behandelt wird.

Was kann ein Mapper machen, um die ff-Datei seiner Map zu "verschlanken"?
Habt ihr irgendwelche Tipps dazu auf Lager?

spontan gesagt, die map verkleinern
- mehr detail brushes verwenden, vielleicht ?
- portale anders anlegen
- eventuell mehr mit terrain und curve patches arbeiten als mit soliden brusches und diese dann auch als detail definieren

auf jeden fall hab ich schon bemerkt, dass die map schneller compiliert wird, wenn man mit detail brushes arbeitet und irgendwann kommt man an dem punkt an, wo der compiler nich mehr weiter macht, weil zuviel solid-brushes (structurial) drin sind

Hallo zusammen


Das mit den Detail - Brushen ist definitiv die erste Massnahme um eine ff. Datei kleiner zu bekommen. Alles und zwar wirklich alles was man nicht braucht damit die Portale funktionieren detail machen.
Ausserdem ist ein Punkt jede Textur die in einer Map vorkommt auch die die ein Spieler nie zu gesicht bekommt wird voll compiliert. Also Sauber arbeiten.Das heisst nicht sichtbare Brushoberflächen caulken.
Ein weiterer Punkt sind Terrain Patche mit zu vielen Vertices.
Wenn möglich grossmaschiger machen.Auch zu viele Curves bedeuten im vergleich zu normalen Brushen eine grössere Mapdatei. Bsp. eine Leiter aus Curves ist grösser als eine aus Brushen.

Und zuletzt Light entinities, je mehr desto grösser wird die ff. Datei.
Also eine Map mit Worldspawn ausleuchten und dann erst die Lights setzen zum ausleuchten der dunklen Bereiche.
Und wichtig dynamic lights nur gering einsetzen. Höchstens 2mal , schaut euch die Orginalmaps an.

Was ich aber nicht verstehe ist das die neuen Maps mp_caretan (54,3 mb) und mp_creek (53,0 mb) über die Grenze stossen.
Also müsste man mal rauskriegen warum bei Costum maps dieser Fehler auftritt.
Wenn diese sauber gearbeitet sind könnte es an den Effekten liegen.



Ciao

und ich dachte, dass ein curve oder terrain patch weniger speicher beansprucht - werd das in zukunft beachten und auch was die punkte (vertics) betrifft
was das caulken betrifft: brushes markieren und alt+c (autocaulk)
zusätzlich noch z.b. die unterseite oder die seiten bei selbstgebauten prefabs (gebäude usw) nachträglich auch noch mit caulk versehen

Man muss ja einige Maps rauswerfen wenn man nen Cod4 server neu aufsetzt.

Custom-Maps haben nix im zone ordner zu suchen; warum sollte man stock maps rausschmeißen? Hier ging es vor 9 Jahren um die Größenbegrenzung des .ff-files von Custom -Maps unter Linux im Usermaps-Ordner.

witzigerweise, nachdem ich carentan rausgetan habe funktioniert alles wieder