Vous n'êtes pas identifié(e).
Hello,
Une petite image pour illustrer mes récentes soirées de travail... et faire remonter un peu le fil de discussion...
A+
Fro'
Uploaded with ImageShack.us
Bonjour Gilles,
Michel a raison, le code de la V3 présuppose l'unicité des fréquence déclarée : si plusieurs navires ont la même fréquence, la gauge ne cherchera que le 1er qu'elle aura trouvé dans Carrier.xml...
Après, une petite précision, la v2 utilise effectivement le "Radius" mais aussi l’existence d'une catapulte pour identifier le porte-avions désiré. Ainsi, il est impossible à la gauge V2 de trouver des navires comme les porte-aéronefs ou porte-hélicoptères...
Avec la v3, plus de limitation, tout ce qui est définit comme navire AI (en clair tout ce qui est mis dans FSX/SimObjects/Boats) peut-être détecté.
Pour utiliser le "title"? Parce que beaucoup de simmer utilisent des bgl de trafic pour disposer de navires en route dans FSX, et qu'ainsi avec un Nimitz version "Empty deck" au nord de Pensacola et un Ike version "Qualif T45" au sud aucun pb pour trouver sans conflit (...ils ont tous le même radius...).
Après, c'est vrai que cela nécessite de faire quelque choix parmi les nombreuses variantes faite par Javier, mais entre nous en utilises-tu tant que ça? 
A+
Fro'
Hello hello, ya t'il des news du CDG qui m'a fait bien bavé?
hello,
pas grand chose à montrer dans la mesure où depuis la rentrée, on a surtout travaillé sur la gauge RFN....
Maintenant les choses vont reprendre un cours plus normal...
A+
Fro'
...Le plan de charge est tel que ce n'est pas pour tout de suite.
Il vaudra mieux reprendre ce sujet au moment opportun, ce qui sera bien plus profitable....
Ben oui, re-ouvrir l'ETD maintenant c'est facilement 3-4 mois de boulot tellement en 1 1/2ans on n'a changer dans notre approche des choses...
Et 3 mois de retard sur le Crouze ça Michel ne le permettrait pas ! 
A+
Fro'
Hello,
Non JardY ce n'est pas comme cela que cela se passe ...
Mettons que les aérofreins soient à 100% train rentrés
Tu sors le train, la gauge détecte la condition "Train100%" ET "Spoiler 100%" alors il place les spoiler à 57% exactement.
Si tu manoeuvres envore les spoilers (via le clavier, le VC etc.....) alors cela se passe aisi:
1) FSX exécute l'ordre "Spoiler Full" => les spoilers passent à 100%
2) la gauge détecte la condition précédente (train100% ET"Spoiler>57%") et déclenche l'ordre Spoiler à 57%
Il n'y a aucune boucle car FSX reste sur la dernière commande et la condition n'est plus remplie => SET SPOILER n'est déclenchée qu'une fois sauf si le pilote s'acharne à vouloir sortir les AF sans arrêt mais là ce n'est pas du flood ...
Tu penses bien que nous avons un peu pensé aux impacts de ce genre de système et pour info l'ETD a été développé/testé systématiquement en réseau avec tous nos petits camarade s RFN et Restauravia....
A+
Sylvain
Petit message à l'attention de Fro ou des concepteurs de l'Etendard IV.
Comme vous le savez j'avais ouvert une discussion à propos des floods d'évents sur le multi d'FSX, discussion dont voici le lien : http://www.pilote-virtuel.com/viewtopic.php?id=36074
Notre application serveur a détecté quelques floods sur la nouvelle version, puisque cet appareil est un superbe freeware, j'aimerais beaucoup m'entretenir de vive voix avec les concepteurs de la RFN pour essayer d'expliquer et surtout de corriger ça !
Les évènements concernés sont :
SPOILERS_SET
TOGGLE_LOGO_LIGHTS
TOGGLE_WING_LIGHTS
TOGGLE_TAXI_LIGHTS
SMOKE_ON
STROBES_OFFComme, je le disais, je serais extrêmement ravi de pouvoir en discuter sur notre Mumble ou par Skype (voici mon compte "jardysoft"). Je sais que des éditeurs de freewares sont bien plus ouverts d'esprit que certains éditeurs de paywares qui ne nous écoutent jamais :)
Hello,
J'ai fait une rapide recherche dans le code de l'ETD afin de regarder ce que tu as pu voir.
Voilà ce qu'il en est:
SPOILERS_SET => Il est utilisé dans la gestion des aérofreins pour une réduction auto de l'aérofrein à la sortie du train. Le code est protégé contre toute boucle intempestive
TOGGLE_LOGO_LIGHTS => Affichage de l'ambre (BIP)
TOGGLE_WING_LIGHTS => Affichage du vert (BIP)
TOGGLE_TAXI_LIGHTS => Affichage du rouge (BIP)
=> Ces 3 feux sont régulièrement sollicités, c'est normal et cela doit être vu en MP (répétiteur sur le bouclier de la jambe avant...
SMOKE_ON => Masquage de la verrière arrachée
STROBES_OFF => pas d'appel à STROBE_OFF, n'est-ce pas plutôt SMOKE_OFF? cf précédent
=> oui l'arrachage de la verrière utilise un effet smoke pour qu'il soit visible en MP, mais je doute qu'il y ait des appels régulier à cet effet, sinon la verrière disparaitrait...
En conclusion, l'ETD par l'usage de certaines variables transmises en MP, a peut-être un volume d'Event plus important que d'autre avions, mais ceci me semble "normal" au sens où je n'y vois pas de flood...
Enfin, l'ETD est maintenant loin derrière nous (plus d'un an) et aucune version corrective n'est prévue avant un moment... l'heure est CDG pour passer rapidement au Crouze...
En espérant que cela répond à tes interrogations?
A+
Fro'
suite essai gauge RFN
ET pourtant .... (air connu ! ) j'ai réussi à configurer et donc choisir le Nimitz de Javier dans le Tacpac , il est reconnu avec les fréquences du tableau ..... ça devrait le faire !!!
Attention, il n'y a pas UN Nimitz de Javier mais plus d'1 dizaine (empty deck, crowded deck 1, Carrier qual, etc...): chaque variante est un Nimitz différent pour FSX!
Par défaut dans le fichier Carrier.xml, seul la varainte "Crowded Deck 1" est déclarée. Si tu utilise une aute dans ton TacPack cela ne marchera pas..
MAis avant toute chose comme l'a dit Michel, vérifie quand même que la gauge RFN fonctionne...
A+
Fro'
Hello,
Il me semble que le porte-avions inséré par le TacPack est le "Nimitz" par défaut de FSX/Acceleration...
Il n'y a t'il moyen de modifier ce choix pour mettre un des modèles du Nimitz de J.Fernandez (par ex), car nous n'avons pas déclaré le PA de FSA dans le fichier Carrier.xml, utilisé par la gauge RFN_Carrier.
Ensuite, Michel faisait allusion aux dossiers inclus dans FSX/SimObjects/Boats qui contiennent tous les navires AI que FSX est susceptible d'insérer. Dans chacun de ses dossiers, il y a un fichier Sim.cfg, qui un peu comme le Aircraft.cfg, contient des informations utilisées par FSX.
La plus importante de ces infos, et celle qui sert à la gauge pour repérer les porte-avions, c'est "Title" : c'est le nom unique par modèle qui est utilisé par FSX.
C'est ce nom qui doit être reporté dans le fichier Carrier.xml.
Dit autrement, si le porte-avions inséré par TacPack n'est pas défini et associé à une fréquence dans le fichier Carrier.xml, la gauge RFN ne risque pas de donner la moindre indication...
Je ne sais pas comment est organisé TacPack, mais visiblement il associe une fréquence à un porte-avions avant de l'insérer dans le décor. La gauge RFN faisant quasiment la même chose mais via Carrier.xml, si les 2 systèmes ne sont pas un minimum synchronisés (même porte-avions pour la même fréquence) alors tu auras du mal à utiliser les 2 en même temps...
A+
Fro'
Hello,
...Pour info
je suis resté sur la version 2 de la gauge et d'ailleurs serait il possible d'avoir encore la possibilité de trouver
la dernière version avant la 3 car je n'ai plus le fonctionnement du waveoff. Je suis resté sur la version 2 car
j'ai beaucoup d'avions navalisés (trop de changements) et surtout les retours de topics ne m'encouragent pas
à changer pour le moment....
Je ne comprend pas la question du Waveoff, sa gestion n'a pas spécialement changée enter la V2 et la V3?
Ensuite, je ne trouve pas qu'il y ait particulièrement de retours négatifs concernant la V3. Certe il y a eu ici beaucoup d'échanges avec Geran mais cela reste un cas parmi d'autre...Globalement une fois que la gauge fonctionne (affichage des textes à l'écran lors d'un changement de fréquence) il n'y a plus de soucis, je dirais même que la V3 est nettement plus simple à installer que la V2 car elle nécessite moins de manipulation...
... je trouve dommage que les indications de l'OA soient assujetties à la sortie de la crosse. Comment faire les entrainement et même les qualifs puisqu'il faut un certain nombre de présentations crosse rentrée avant d'être autorisé à sortir la crosse...
C'est vrai, mais on utilise la crosse sortie pour identifier spécifiquement une présentation Appontage/ASSP... Pas facile d'avoir autrement un critère simple et fiable même si, comme tu le dis, cela conduit à qqs compromis...
... je rève d'un SEM de la même qualité que le magnifique Etendard...
Là aussi il faut faire des choix, pour l'instant notre "to-do-list" est concentrée sur le CDG puis viendra le Crusader...
Malheureusement les projets FSX ne permettent pas des cadences importantes, on est les 1ers à le regretter car plus un projet dure plus il est compliqué à mener au bout... les exemples ne manquent pas hélas ...
A+
Fro'
Hello
Le son du Seaking est généré par l'effet fx_CVN65_seaking.fx qui est dans FSX/effects
En l'editant tu verras en début de fichier une ligne dédiée à un fichier son : supprime la ligne et/ou le bloc...
Autre possibilité tu utilises l'effect "fx_dummy.fx" qui est un effet "vide" en le copiant sous le nom du fx_CVN65_seaking.fx
A+
Fro'
hello Dutrla,
merci pour ton message!
concernant ta question sur le son du Seaking, tu peux y remédier en jouant sur l'effet lié au Seaking (je ne sais plus son nom...)
C'est lui qui gère le bruitage de Pedro...
D'une manière générale, la gauge RFN V3 (qu'on essaye de packager par ailleurs avec Michel) propose beaucoup de paramétrage : jetez un coup d'oeil au nouveau Carrier.xml, vous constaterez alors le nombre de paramètres disponibles...
A+
Fro'
Fro' a écrit :Cela plusieurs mois maintenant que je suis sur des porte-avions, il y en a un qui va sortir prochainement mais sous un autre label que RFN (disons plus américain comme PA... )
A+
Fro'Un autre label ?
Quelqu'un a t il une idée ? Sim-outhouse ?
Hello,
Oui, Dans les tout prochains jours, Team SDB va sortir un CVN-65 Enterprise sur lequel j'ai travaillé... Il s'agit d'une profonde refonte visant à mettre au niveau des porte-avions mobiles FSX actuels du vénérable BigE FS9 d'ex-Alphasim...
Pour ceux qui aiment les ambiances US NAvy années 80, avec Tomcat, CorsairII et Seaking, vous devriez apprécier... 
Il y a une discussion sur SOH qui en parle => ICI
A+
Fro'
Hello,
Merci pour ces encouragements!
Le SEM? Ce serait bien effectivement, mais notre programme est un peu plus complexe que ça...hélas...
Cela plusieurs mois maintenant que je suis sur des porte-avions, il y en a un qui va sortir prochainement mais sous un autre label que RFN (disons plus américain comme PA... ) et maintenant le CDG qui démarre et pour lequel j'ai pas mal de petites choses à faire car cela un moment que j'y cogite...
En parallèle, on va sortir une nouvelle version de la gauge "RFN-Tacan" dont la partie calcul des variables a été complètement de refaite en C++ (cela commence à ressembler à quelque chose ...=D), ce qui amènera ensuite un travail de mise à jour des aménagements ASSP.
Une fois ces projets passés, on repassera aux avions, mais pour l'instant notre volonté est toujours d'attaquer par le Crusader...La doc s'accumule, la motivation aussi, il ne reste plus qu'à trouver du temps... 
Mais ce n'est pas Bruno qui me dira le contraire, un avion FSX c'est vraiment 2 projets complets assez différents à mener : 1 pour le modèle extérieur et un autre pour le VC...donc il ne faut pas se perdre en chemin..
A suivre...
A+
Fro'
Steph-80 a écrit :... Génial, un poly de gagné... Multiplié par toute une scène remplie d'arbres ça commence à devenir intéressant.
Malheureusement c'est pas tout à fait vrai. 1 poly de gagné pour toi qui crée ton objet. Mais dès qu'il est exporté en mdl
les cases cochées sont transformées en polys orientés. Au final ca ne change en rien le nb de polys.
Hello,
Le gains n'est effectivement pas si évident, surtout que FSX gère différemment les ressources graphiques que FS9, le nb de poly est nettement moins déterminant...
Par ailleurs je n'aime pas trop le "double side" car il génère des aberrations d'éclairage : il applique aux 2 faces le même effet d’éclairage (à l'ombre ou à la lumière)... Cela donne parfois des choses bizarres....
A+
Fro'
Bonjour,
Cela fait longtemps que je n'ai pas posté par ici, voici donc une nouvelle discussion sur un projet RFN qui débute...
Dès maintenant un grand "Merci" à Pierre qui m'a confié ce très beau modèle!!
Les travaux d'adaptation au SDK de FSX ont débuté (mapping, création des texture, etc...), c'est la partie la plus longue, suivra ensuite l’enrichissement du navire des divers objets, personnages, avions et fonctionnalités que nous avons dans nos magasins "RFN" ...=D
Deux petites captures de 3DS pour mettre en valeur le travail du "fournisseur officiel de la RFN"..
A+
Fro'
PS : Comm' d'hab' pas de date car on ne les connait pas...
Salut messieurs,
Riki est parti du principe qu'étant donné qu'il y a déjà des Alphajets de petite qualité sur FSX, il s'est lancé dans la réalisation d'un Alphajet haut de gamme, sans trop se soucier des petites configs.
De plus, cet Alphajet sera (théoriquement) Freeware, donc pas de soucis de "Si je paye pas 35€ (soit dit en passant le prix de FSX) je n'aurai pas de jolies textures".Préparez vous messieurs à accueillir un freeware de qualité, plein d'humilité sur FSX.
Tout ça grâce a ce cher Riki, qui fournit un travail énorme pour cet appareil, avec passion et rigueur.
Hello Messieurs,
Surtout pas de malentendu concernant mes propos: ce ne sont que des remarques et non des critiques.
De plus, sous FSX,"gros modèle" ne signifie pas systématiquement "gros mangeur de FPS", les exemples payware sont là pour nous montrer qu'un MFD fait parfois beaucoup plus de dégâts qu'une floppée de vis en 3D!!
Personnellement, j'attends avec impatience la suite des travaux de riki33 pas tant pour le modèle 3D (qui est supperbe) que pour la façon dont il va nous exploiter les fonctionnalités de 3DSmax comme Mental Ray, pour nous "baker" des textures incroyables j'en suis sûr!! (pour moi les textures d'un VC font 50% du résultat si ce n'est plus)
A+
Fro'
Puisque vous êtes sage voici l’état d'avancement des gauges 3d....=8
En ce qui concerne les craintes a propos des vertex des polygones et autres FPS dans fsx, il est bon de savoir et comme le dit mon cher documentaliste gudule l'apareil est soumit a des tests régulier.(si l'on constate des pertes significatives alors retour en arrière).
Hello,
C'est superbe! comme d'habitude (j'ai envie de dire....)
Concernant les FPS, il ne faut pas s'attendre à ce l'ajout d'un objet 3D ou d'une texture ait un impact significatif sur les performances. Une rupture serait plus générée par l'ajout d'un code qui bouclerait que par un supplément de quelques milliers de polygones...
Ma remarque est plutôt une remarque sur le volume que l'on peut attendre avoir au final avec un début comme celui-ci , et crois-moi, il est toujours très pénible de devoir reprendre son cockpit et réorganiser ses textures une fois que celui-ci est animé et peint...
Après, il n'y a pas de vérité clairement établie sous FSX... ce serait trop simple ....=(
a+
Fro'
Bonjour messieurs, petite devinette si quelqu'un trouve il aura toute mon estime....=D
A votre avis que représente le cercle orange+symbole sur l’altimètre de l'alphatjet
????!!!(un voyant, une pastille..??).
il faut savoir que sur l'alpha français en mode vol il y a un cache noir a la place.
Merci d'avance.Next.....
Hello,
Sur l'ETD, dont l'alti codeur ressemble beaucoup à celui-ci, il s'agit de l'indicateur "DPS" lié au bouton "DPS" présent en bas à droite (en forme de triangle). Comme le DPS correspond à la correction de l'écart de statique (liée au nombre de Mach), il est fort possible que l'Alphajet n'ai pas été équipé...
A+
Sylvain
PS: quand je vois tes interrupteurs aussi détaillés, je me demande si tu n'y pas allé un peu fort... Ce n'est pas tous les jours que l'on zoom autant sur le tableau de bord pour admirer les détails des switchs, non?
Hello,
Comme ça , je dirais que le plus gros risque sur l'Alphajet vient du fait que tu vas quasi doubler le nombre de poly (ou vertices) lorsque tu réaliseras la place arrière.
Sinon, je pense que ce genre de cockpit est modélisable sans risque avec un grand nombre d'objets 3D...
Comme je le disais , il faut juste conserver à l'esprit l'impact de l'objet en cours sur l'ensemble du modèle: 1 poignée à 2k vertice est certainenement sans impact, mais 1 inter à 300 vertices peut lui devenir problématique si il y en a 30 dans la cabine!!
Dernier point, je suis arrivé à la conclusion qu'avec FSX, l'impact sur les FPS est moins lié au modèle 3D qu'à la façon dont il est mappé et animé...
Tu constateras que le poids du mdl fait un bond dès que tu va mapper tes objets sur des textures et un 2nd saut, quand tu animeras tes objets. En même temps, tes FPS peuvent en prendre un coup à ce moment là car la façon dont FSX utilise les ressources graphiques est très dépendante de la façon dont les objets à afficher sont organisés en terme de "material" (vu de Gmax)...
Je te recommande d'avoir une approche très rationnelle concernant la gestion des materials et donc des textures, car c'est un peu le coeur de beaucoup de problèmes : FPS, rendu/effets visuels, mais aussi (et surtout) immersion/réalisme...
Personnellement, j'ai passé beaucoup de temps à analyser comment les textures du cockpit du L19 de Lotus étaient organisées (nombre, taille des fichiers, définition des images, etc...) : encore maintenant cela reste pour moi une référence en matière de réalisation/optimisation!!
A+
Fro'
Voici des news...Je suis en ce moment sur les commandes du HUD....De beaucoup auraient choisit le modèle le plus simple, je me suis dis quitte a faire du polygones et bien donnent leur du polygones...
Next....
Hello,
C'est très joli tout ça!
Par contre, même si FSX est nettement plus tolérant que FS9 côté polygones (pas de limitation du modèle à 64k), fais tout de même attention à ne pas basculer dans le "haute déf" où il te sera ensuite difficile/pénible d'alléger ton cockpit.
Il n'y a pas de règle clairement établie, mais personnellement je me fixe une limite max (120 ou 150k par exemple), puis je surveille l'avancée de mes travaux en extrapolant "grosse maille" à chaque fois, histoire de ne pas être trop à côté...
Par exemple: je compte le nombre d'instruments de bord et boitiers à faire, et au vu de la taille des 1er réalisés je regarde ce que cela donne en extrapolant. Il est inutile d'avoir des cadran qui mangent 400 vertices chacun, si avec 200 le rendu est déjà bon...
Ceci je l'applique à toutes les pièces qui sont en grand nombre dans le cockpit : cadran, inter, bouton, vis, etc...
Dis autrement, les capacités de FSX, je préfère, globalement, les utiliser à ajouter des objets 3D qu'a avoir des objets lourds... ceci avec tous les compromis et exceptions qu'il convient de faire bien entendu ...=D
En tout cas bon courage,
Fro'
Merci pour vos encouragements
Pour ECV: oui,il est prévu avec place instructeur...
Pour FRO: j'utilise toutes les fonctions 3sdmax y compris le unwrap, mais si tu peut me dire comment tu fait de 3dsmax en .x et .MDL je suis preneur
. Dans l'attente de vous lire...
A+
Hello,
Il faut avoir installé le plugin du SDK de FSX (ou celui là SDK Prepare3D)
Cela te permet de pouvoir exporter en format .X
Là tu récupères le fichier .x et .Xanim (si tu as des animations) pour le compiler en .mdl via XToMdl.exe (qui est fourni par le SDK que tu utilises.
Personnellement je me suis faire des fichiers .bat pour exécuter les commandes DOS kivonbien et notamment avoir les logs de compilation...
Cela donne cela:
XtoMdl /KEEP /XANIM /DICT:..\..\bin\modeldef.xml MonModele.X >> resultat_MonModele.txt
[Remarque: un .bat, c'est juste un fichier .txt, dans lequel tu mets la ligne de commande que tu sauvegardes en .bat ]
Tu mets les les fichiers .x, .xanim et .bat dans le même dossier que ton XtoMdl.exe et tu double-cliques sur le .bat...
L'intérêt de passer par le .x par rapport à Gmax c'est de pouvoir conserver les logs de compilation...
Tu trouveras d'autre éléments de compilation ici :
Doc XToMDL
De même tout le paramétrage du plugin est expliqué ici (pour 3DSmax7 à 9):
Set up de 3DSmax
A+
Fro'
Il serait quand même dommage d'avoir 3DSmax et de devoir mapper les textures avec les fonctionnalités de Gmax seulement...
Carrément. J'ai hurlé quand j'ai vu tout ce qu'ils avaient enlever à Unwrap UVW.
..et quand Thor hurle cela doit faire du bruit...=8
Par contre si j'ai bien compris, gmax est l'équivalent de 3dsmax4 (avant un rachat et un changement dans leur marketing... exit la version gratuite...)
Donc toutes les fonctionnalités autour du Unwrap dont parle Thor's sont des ameliorations apportées au fil des années...
Personnellement je ne pourrais pas abandonner pas 3dsmax pour revenir à gmax , je suis maintent trop dependant de plein de petites fonctionnalités...
A+
Fro'
pepe-pompero a écrit :Bonjour
Vite des textures ....
Mais tuas fait coment pour finir, ton transfert 3dsmax vers fsx? car cela m'intéresse vraiment..pépé
Salut pépé, je prend la passerelle .3ds pour transférer mon fichier de 3dsmax vers Gmax.
Une fois dans Gmax je travail les liens d'animations et plus tard je réassignerai les textures, voili voilou...
Cordialement.
Bonjour,
Je ne sais pas quelle version de 3DSmax tu as mais dans tous les cas il y a un plugin qui permet l'export en .x pour ensuite une compilation en mdl: aucun besoin de passer par Gmax!!
Si ta version est antèrieure (ou égale) à 3DSmax9 =>utiliser le plugin du SDK de FSX (celui d'Acceleration de préférence)
Sinon utiliser le plugin du SDK de Prepare3D qui se trouve gratuitement sur leur site et qui est compatible avec FSX...
Il serait quand même dommage d'avoir 3DSmax et de devoir mapper les textures avec les fonctionnalités de Gmax seulement...
A+
FRO'
