Recherche>Futur reseau de module nwn2

Répondre
Partager Rechercher
Bonjour j'aimerais savoir si il y a de futurs reseaux de modules nwn2(plusieurs modules relier entre eux partageant le meme vault,les memes regles,univers,etc..)
Parce que je compte faire mon propre mod pour nwn2,et comme il a ete dis par le passé que nwn2 serait gourmand niveau ramm et qu'ils seraient difficile de monter a plus de 100 maps sous windows xp a cause de la limite de 2GB de ramm par prog(frustant quand on peut monter a 8GB avec sa carte mere).

voilà juste savoir si il existe un ou plusieurs reseaux serieux au cas ou obsidian n'arriverais pas regler se prob?
La limite au niveau de la ram ce n'est pas exactement ça.

J'ai un peu la flemme de rechercher les anciens messages que j'ai tapé donc je vais répondre de mémoire.

Une zone d'extérieur 32x32 sous NWN2 devrait nécessiter 25Mo de ram. En 16x16 (ce qui était communément utilisé sous NWN) ça donnerait du 6.25Mo de ram par extérieur. Si tu dédis 1Go de ram rien que pour les zones (vu qu'il faut garder quand même un peu de ram pour tout le reste) ça te ferait un module de 160 extérieurs 16x16.

Par contre, les intérieurs sont beaucoup plus léger et ils ne devrait pas dépasser le 1Mo de ram. Si tu fais 100 extérieurs 16x16 tu utilises 625Mo de ram et il te reste 375Mo pour faire des intérieurs.
Donc tu te retrouverais avec un module de 475 zones (100 extérieurs et 375 intérieurs).

La limite du nombre de zone n'est pas si contraignante à partir du moment où les extérieurs sont optimisés par le concepteur (que ce soit dans leur taille ou dans leur nombre).

Bien entendu les chiffres avancés sont très théoriques et basés sur ce que Obsidian avait pu dire il y a pas mal de temps. Ca a pu fortement évoluer depuis (en bien ou en mal).
Citation :
... cause de la limite de 2GB
Juste pour etre sur, peut-on avoir un server NWN2 qui tournera avec plus de 2GO de RAM exploité ?

Je suis entrain de préparer un server sur la région des Vaux (RO) et le server aura 4 barrettes de 1 GO ... ça serait dommage de ne pouvoir utiliser que la moitié.
Pour ce que je comprends à l'informatique c'est pas un problème provenant de NWN2 mais de Windows. Il semblerait qu'il ne soit pas capable de gérer les processus qui font plus de 2Go... enfin y a un truc comme ça.

Y a un informaticien dans la salle pour confirmer (ou infirmer) ?
Oui sa vient de windows xp qui peut pas gerer au dessus de 2 Giga,pour cela il faudrait un windows 64 bits enfait une version 64 bits de nwserver pour etre plus precis......mais cette question aupres de obsidian n'as jamais eu de reponse.
Obsidian parlais a un moment de vouloir decharger de la memoire les zones non utilisé on ne sait toujours pas se qu'il en ai....
Rhaa pas pouvoir rentabilisé la ddr2 xms2 6400....

Autrement j'ai jamais utilisé Linux,donc je connais pas du tout.
Informaticien présent.
lien de référence linux : http://www.prism.gatech.edu/~gte213x/LinuxMM/rpt.html
lien de référence Windows http://www.microsoft.com/france/msdn...n-memoire.mspx
Les citations sont reprises de ces articles.

Sous Windows XP et 2003, par défaut, nous sommes limité à 4Go de mémoire centrale gérée et, du à l'architecture, taille maximum de processus : 2Go.

On peut dépasser légèrement cette limite sur un serveur dédié à une application en utilisant certaines fonctionnalités dont l'option de démarrage /3GB

Citation :
Windows XP et Windows Server 2003 ont introduit une nouvelle option de démarrage, /USERVA, qui doit être utilisée avec /3GB et qui permet un niveau de contrôle plus fin que l'option /3GB utilisée seule. /USERVA s'ajoute à votre BOOT.INI de la même façon que /3GB. L'avantage de l'option /USERVA sur l'option /3GB utilisée seule est qu'elle vous permet de spécifier exactement la quantité d'espace d'adressage à réserver pour l'accès au mode utilisateur. Par exemple, /USERVA=2560 configure 2,5 gigaoctet pour l'espace du mode utilisateur et laisse les 1,5 gigaoctet restants pour le noyau. Les inconvénients qui s'appliquent au commutateur /3GB lorsqu'il est utilisé seul s'appliquent également dans ce cas.
Il y a d'autres possibilités, un système nommé AWE, mais je doute qu'Obsidian se soit occupé de cela

Citation :
la fonctionnalité AWE permet à une application d'accéder à la totalité de la mémoire RAM physique accessible au système d'exploitation, à condition que cette application ait été codée pour utiliser les fonctions API Win32 AWE.
Sous Linux, la balle est encore dans le camp d'Obsidian. On ne sait pas encore ce que livrera Obsidian comme serveur dédié vu qu'ils compilent tout avec la plateforme de développement Microsoft (outils Visual etc)
Ceci dit, le découpage 3Go utilisateur / 1Go système existe sous linux aussi. En utilisant un noyau adapté, gérant au delà de 4Go, la taille des processus restera tout de même limité à 4Go, sauf compilation en linux 64 bits et là encore, ca me surprendrait.

Citation :
However, even though your machine may support greater than 4GB of memory, no user processus can use more than 4GB of memory at a time (again, the 32-bit pointer limit).
Conclusion :
dans l'état de l'art actuel, je dirais 2Go maxi pour ceux qui ne bricolent pas leurs serveurs (je conseille alors de mettre 3 à 4 Go de mémoire centrale)
3Go pour les bricoleurs sous les OS Windows
4Go pour les linuxiens.
Au delà de ces barrières : découpage en multi-module.
Un avertissement : gardez de la marge pour éviter les crashs, la gestion des PJs connectés prend de la ressource.
T'inquiete applefire je sais que la qualité est primordiale,a la base je voulais me renseigner sur les reseaux de modules au cas ou on serait vraiment limité en nombre de zones mais cela a l'air de se presenter dans un ciel moins gris que je ne le pensais en theorie(en plus mon nouveau processeur viens d'arriver,merci monsieur le facteur!).
taille des zones de la campage
C'est cité ici : http://nwn2forums.bioware.com/forums...7276&forum=100

Citation :
Author ATTN: PW people RE: module sizes
J.E. Sawyer
Lead Designer


Joined: 25 Jun 2002
From: Mission Hills, California Posted: Friday, 14 April 2006 07:25PM
Hello, my friends. This is mostly a cautionary message for PW builders based on some questions that were asked in the chat last night. Of specific note was a question asking if we had run a module with 300 areas in it.

The answer is not only "no," but "not even in our dreams". It's true that the average gaming rig is a lot beefier today than it was when the original NWN was released. But the complexity of our areas -- both interior and exterior -- is dramatically greater. One consequence is that a NWN2 area tends to have a hefty memory footprint. This is especially true on exteriors, where super texture-layered height-mapped terrain is stuffed full of trees, bushes, and high-detail buildings. We are still in the process of optimizing our data and beautifying areas intelligently, but we're typically looking at 6-9 megs for a mid-sized NWN2 exterior. On the extreme end, big areas run upwards of 20 megs.

This might not seem like that big of a deal on machines that often have 1 or 2 gigs of RAM, but when you throw in ten of these suckers and a bunch of interiors that are all part of the same module, you are on a highway to the proverbial danger zone. Combined with the game's overhead for doing everything else, it's a lot for a server to deal with.

For people playing our "OC" and building adventure modules, none of this should be a big concern. You can chop up your modules into whatever size you want and people can just deal with lugging the party around. For PW builders this may cause logistical problems for how large your modules can be. If you were planning to have a series of areas running continuously from Baldur's Gate to Lathtarl's Lantern (a personal favorite), you will need to have a server forged by the hand of Bane himself. Or maybe twelve 30th level arcanists. Either way, it's a big deal.

I know this is probably less encouraging news than, "Yeah, we're running 500 areas in a single module!" but I figure that letting everyone know now is better than letting you figure it out through trial and error after the game comes out. Lest this come off as a tepid, eye-roll-inducing "temper your expectations" message, let me end with clarity:

NWN2 areas take up a lot of memory. The exteriors take up even more memory. If you are planning to have huge chains (10+) of large exteriors and interiors linked in a single module, it's not going to run smoothly on current hardware.
J'ai lu aussi sur le forum que l'option /3GB ne servirait pas car il faut une option à la compilation, l'information est sujette à caution.

- Une des questions demandait si nous avions fait tourner un module de 300 zones.
- La réponse n'est pas seulement NON mais "même pas dans nos rêves".
- ... mais nous sommes en train d'optimiser vers 6-9 Mo pour une zone d'extérieur de taille moyenne. A l'extrême les grosses zones tournent autour de 20 Mo.

Juste pour information ça tourne plutôt dans les 4Mo pour les grosses zones actuelles (nwn1, empreinte mémoire sur le serveur) et elles ne sont pas chargées en mémoire au démarrage
Pour l'utilisation de /3GB, j'ai trouvé un article ici http://support.microsoft.com/kb/171793/en-us
et là
http://www.microsoft.com/windows2000...help/vlm_7.htm
Ceci m'a l'air délicat, je me ferais une joie d'essayer sur une machine de test dés que je pourrai.
Méthode : "Imagecfg -l nwserver.exe"
Cela devrait faire tout comme une option de liaison à la compilation : /LARGEADDRESSAWARE.
Après quelques recherches, j'ai fini par trouver les outils plus à jour dans la documentation Visual C++.
Il est possible de modifier un exécutable compilé avec les options standard pour lui permettre d'utiliser jusque 3 Go de mémoire.

C'est faisable avec EDITBIN (cf ici la documentation des option http://msdn2.microsoft.com/en-us/library/xd3shwhf.aspx )

Comment obtenir une version ?
Par le biais de l'assembleur MASM téléchargeable ici http://masm32.online.fr/masm32.htm

les deux binaires utiles sont editbin et dumpbin
Voici la syntaxe :
Citation :
E:\masm32\bin>Microsoft (R) COFF Binary File Editor Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
usage: EDITBIN [options] [files]
options:
/BIND[ : PATH=path]
/HEAP:reserve[,commit]
/LARGEADDRESSAWARE[:NO]
/NOLOGO
/REBASE[:[BASE=address][,BASEFILE][,DOWN]]
/RELEASE
/SECTION:name[=newname][,[[!]{cdeikomprsuw}][a{1248ptsx}]]
/STACK:reserve[,commit]
/SUBSYSTEM:{NATIVE|WINDOWS|CONSOLE|WINDOWSCE|POSIX}[,#[.##]]
/SWAPRUN:{[!]CD|[!]NET}
/VERSION:#[.#]
/WS:[!]AGGRESSIVE
et voici un exemple d'en-tête de fichier exécutable modifié

Citation :
E:\masm32\bin>Microsoft (R) COFF Binary File Dumper Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file e:\sssu.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (i386)
5 number of sections
426D29D2 time date stamp Mon Apr 25 19:33:06 2005
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
12E characteristics
Executable
Line numbers stripped
Symbols stripped
Application can handle large (>2GB) addresses
32 bit word machine
Voilà qui devrait permettre de donner un peut plus d'air, soit 3Go de limite sur Windows XP et 4Go sous Windows XP 64bits

Note : il faudra aussi changer le fichier de démarrage de windows (boot.ini) tel qu'indiqué dans les posts précédents.

50 à 100% de plus pour la taille des modules c'est toujours appréciable.
Une idée comme ça, s'il y'a vraiment beaucoup de RAM inutilisée, ne serait il pas possible sur un serveur bi-proc de couper le module en deux, lancer deux serveurs (régler l'affinité de façon a ce que chacun soit sur un proc) et au final les deux serveurs pourront utiliser jusqu'à 2Go de RAM chacun (ou 3, ou 4, enfin bref), mais au total utiliser le maximum de RAM présente ?
Si, tout a fait, il suffit de jouer avec les paramètres de lancement des exécutables du serveur : n° de port en particulier

J'espère que le serveur nwn2 fonctionnera de la façon suivante :

Le mieux je pense est de jouer sur nwn.ini et de créer deux dossiers différents contenant nwnserver.exe et les fichiers de paramétrages
Tu personnalises nwnplayer.ini dans chacun des dossiers
Tu personnalises chaque nwn.ini pour qu'il pointe vers le bon endroit : si possible économise les doublons de fichiers, ça prend quand même pas mal de place et surtout pointe bien sur le même vault
Citation :
Publié par contenu nwn.ini
[Alias]
HD0=.\
OVERRIDE=.\override
TEMP=.\temp
MODULES=.\modules
LOGS=.\logs
LOCALVAULT=.\localvault
DMVAULT=.\dmvault
SERVERVAULT=.\servervault
TEMPCLIENT=.\tempclient
SAVES=.\saves
CURRENTGAME=.\currentgame
HAK=.\hak
PATCH=.\patch
NWMFiles=.\nwm
DATABASE=.\database
Enfin tu règles l'affinité de chaque exécutable nwnserver.ini en dur avec imagecfg.exe (http://www.robpol86.com/Pages/imagecfg.php)
Seul problème potentiel dans ce cas (que j'avoue n'avoir jamais réussi à régler avec Nwn1), lors de la transition entre serveurs (sur un même pc) par un portail, il m'est arrivé d'avoir un message d'erreur et donc impossibilité de passer d'un module à l'autre.
Apparement, c'était lié au fait qu'un des deux serveur essaie de lire le personnage sur le servervault pendant que l'autre y écrit, mais cela dépendait également du PC (peut être de l'OS), et je ne sais pas si ça sera réglé avec Nwn2.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés