Vous n'êtes pas identifié(e).
heu quoi dire?...
y-aura t il les sabots de catapultage sur leurs rails ?valentin
Arrg! Je suis fait!! 
Effectivement les sabots de catapultage ne sont pas encore posés... Cela me soulève d'ailleurs qqs questions car ils varient selon les types d'avions (avec barre ou avec élingue)... De même les sabot de holdback sont placés très différemment selon les cas...Je ne sais pas encore comment faire, je me les mets sous le coude en attendant...
A suivre...
Fro'
Hi,
Tu as raison, au temps pour moi!!
Je pensais que les ETDIVM que la 59S avait passé en gris clair étaient tous sur le modèle du N°34, et ben non., cela aurait été trop simple..O_o
Je crois qu'il ya même des cas où la pointe avant n'est pas noire mais dans la continuité du fuselage...
A+ et bon courage
Fro'
Hello,
Très bonne idée!
Je pense que pour ces livrées 59S il faudrait partir des éléments de la livrée "N°7 dernier vol", car cocardes, inscription "MARINE", triangle "Danger" , etc.. sont similaires.
Bon courage!!
A+
Fro'
...
J'espère juste que les FPS n'en soufreront pas trop...
A ce stade le modèle ne fait "que" 80k polygones... c'est très loin de ce que l'on a avec les Clem et/ou Foch... bien-sûr je n'ai pas encore mis les avions et ponevs...
Je ne pense pas que les FPS soient particulièrement impactés au final car cela reste assez loin des limites de FSX et puis le porte-avions reste de toute façon assez loin des zones chargées en décors... Après cela reste indicatif et parfois il suffit de pas grand chose pour que FSX se prenne les pieds dans les FPS... Un navire qui passe par là mal optimisé et au revoir les FPS...
A+
Fro'
Hello,
Personnellement j'utilise 3Dsmax7 et si il m'arrive d'utiliser Gmax, je serais maintenant incapable de revenir à Gmax pour réaliser un modèle entier.
La question de Richard illustre pas mal comment, même en connaissant une version, on peut être perdu dans les autres versions alors qu'elles sont cousines (les logiques restent assez similaires)...
Personnellement, je ne sais plus travailler autrement qu'en mode "Editable Poly" qui fournit à partir de la version 7 des fonctions dont je ne peux plus me passer : par exemple le "Target Weld" (pour souder un vertice A sur le vertice B, A rejoignant B), ou le Unwrap UVW en mode "Select Face" qui coupler aux fonction de l'éditeur UVW permet de mapper face par face: très puissant pour habiller rapidement des objets complexes.
Et bien-sûr, il y a le "Render to Texture" pour générer des textures d'ombres (par ex) calculées par le moteur de rendu : très pratique pour avoir de textures réaliste rapidement... Quand je dis rapidement, c'est une fois qu'on commence à comprendre cette fonction pleine de pièges... 
Après chaque développeur s'adapte en fonction de son outil pour l'exploiter au mieux et optimiser au mieux son temps : ce qui signifie un gros effort si on doit changer d'outil et donc ses habitudes...
Dernière petite chose, personnellement j'exporte mon modèle en .x pour le compiler directement via un .bat. C'est rapide et cela me permet d'avoir accès directement au log de compilation (il y a régulièrement des petits soucis qui apparaissent à ce moment là...)
A+
Fro'
PS: à la place de LithUnwrap, j'utilise le plugin "Unwrap Object Texture" qui fait des choses similaires directement dans 3DS... Cela doit exister aussi pour des version plus récente de 3DSmax...
Hello à tous,
Légèrement en avance par rapport au calendrier et franchement en retard par rapport à notre feuille de route, voici en quelque sorte les voeux de la RFN pour cette années 2013 qui s'annonce très "aéronavale" :
1) Tout d'abord le CDG qui se termine, et pour lequel il faut compter en semaines (je l'espère):
2) Ensuite pour le très souvent annoncé projet Crusader, qui grâce au "Pierre Noël", est maintenant en marche. Une fois le CDG bien au large, le Crouze devrait bien nous occuper durant cette nouvelle année (bien évidemment aucune date prévisionnelle n'est connue voir même envisagée...)
Bien-sûr nous mettrons régulièrement qqs infos sur le forum pour vous montrer l'avancée des choses...
Meilleurs voeux à tous et à l'année prochaine : 2013 l'année de l'interception pour ne pas dire l'année du Chasseur 
!!
A+
Fro'
Un travail magnifique
Juste une petite remarque avec l'ombre du Rafale de Thors qui semble étrange
David
Ce phénomène est dû à la façon dont FSX gère les ombres: sur le pont des porte-avions ombres des avions se mêlent à celle du navire avec parfois qqs aberrations ...
A+
Fro'
... Sur les photos, le pod DDM/IR+IMF de dérive me parait un peu long sur l'avant? Est-ce un effet de paralaxe?
Point de parallaxe... juste un mauvais placement... 
Je corrige de suite.. merci!
A+
Fro'
Hello à tous et merci!
Effectivement, j'utilise pour l'instant la "brillance" par défaut, ce qui donne un effet plastique pas très heureux... Je dois creuser cela dans les jours qui viennent...
Côté proportion, c'est fort possible qu'il y ait 2-3 choses à reprendre car le travail a été fait un peu au pif parfois (je n'ai pas trouvé énormément de plans 3 vues de Rafale très propres...).
Il faudra faire un test de comparaison en amenant des "vrais" Rafale FSX sur le pont d'envol ... C'est toujours un moment de vérité quand on croise les modèles entre eux...
Côté FPS, je ne m'inquiète pas car cela reste dans des "standards" déjà éprouvés : modèle autour de 2000 à 3000 polygones et 1 texture de 1024px par avion à laquelle s'ajoute celle de la verrière et celle des numéros (non mis encore sur le Rafale). Tout cela reste peu impactant globalement...
Pour info, le CDG fait actuellement moins de 60k polygones et le Foch avec ses avions et personnages moins de 160k, donc j'ai de la marge...=D
A+
Fro'
Arrr... Merci merci!...:D
Après soyons clair, on a beau être patient, minutieux (qui a dit "maniaque"!?), sans de la documentation on n'arrive pas à grand chose... de ce côté là je suis très très chanceux car grâce à Michel rien des modèles sur lesquels je travaille ne garde longtemps des mystères... Et quand j'arrive à coincer Michel sur un sujet, il ne lui faut pas très longtemps pour activer son réseau de copains !! (Je pense notamment aux trappes automatiques des becs de l'ETD 
).
Après la réalisation c'est surtout une question de temps et méthode...
Du modélisme quoi... Un porte-avions c'est globalement comme travailler à l'échelle 1/144e, avec des zones qui titillent du 1/72e. Le modèle extérieur d'un avion, c'est carrément du 1/32e, et pour le cockpit virtuelle, là on est dans du lourd comme du 1/6e : on ne fait pas tout mais on va loin dans le détail...
Donc vous imaginez bien que sans doc ou sans explications du "comment ça marche?/à quoi ça sert?" on fait vite des choses aberrantes...
Et puis le travail d'équipe est de toute façon tellement plus enrichissant! Vivement le Crouze!!
Bon j'y retourne car je dois reprendre le boulevard bâbord qui ne me plait pas trop... (rires)
A+
Fro'
aeronef a écrit :... un éclairage sur le pont...
Bien sur, et on pourra comparer avec cette capture.
Mais on y est pas encore.
Michel
Petite précision, quand on parle d'"éclairage sur le pont", il faut comprendre ajout des feux réglementaires pour l'appontage de nuit, pas un éclairage au sens "projecteurs qui illuminent le pont d'envol"...
Désolé mais l'appontage ce sera en "black out"...
Illustration:
A+
Fro'
Salut Michel et Sylvain, petite question : Quelle Config de pont avez vous prévue ? Rafale /Sem / Hawkeye ? Ou alors Majorité de SEM ou majorité de Rafales sur le pont ? Et niveau Pedro ? Alouette ou Panther ?
A+ Rooster
Hello Rooster,
Concernant le pont, je ne sais pas encore exactement car je n'en suis pas encore à travailler sur les avions. Il faut que je potasse un peu mes docs pour définir les configurations intéressantes mais pour l'instant je n'ai pas encore toutes la collection d'objets 3D nécessaires... Hawkeye?C'est possible, car Pierre (loué soit-il! ) m'a gentiment mis à dispo un modèle mais il faut que je le travaille pour le mettre à la toise "porte-avions AI" (y'a du polygones là dedans!!)
Côté Pedro, pour l'instant c'est Alouette car je l'ai déjà. Après je pourrais regarder pour un Panther, mais je n'y crois pas beaucoup car c'est du boulot... Après Pedro c'est un modèle AI séparé donc rien n'empêchera l'ajout d'un Panther dans un 2ième temps
A+
Fro'
Bonjour micpni,
Quand je pense qu'il y a quelque temps tu nous écrivais:micpni a écrit :...Le hangar demande beaucoup de temps, pour un intérêt limité et un alourdissement du mdl, avec une influence sur les FPS.
Il est donc probable que Fro' ne fera pas les ascenseurs fonctionnels.
En revanche, le CDG devrait comporter une aire pour le carburant.
MichelEt aujourd'hui tu nous annonces la présence d'essuie-glaces!:8
Rassure-nous, ils ne sont pas actifs quand-même...=8Bonne continuation à toute l'équipe!=W
Cordialement,=D
Hello,
En effet, cela peut paraître paradoxale de mettre des essuie-glaces en faisant l'impasse sur un hangar...
Mais, tous mes essuie-glaces vont me coûter au maximum 200 polygones alors que le moindre avion placé dans le hangar m'en prendra 2000!!
De plus, des petits détails aussi insignifiants que les systèmes d'essuie-glaces du CDG sont, au final, autant de détails qui vont contribuer à rendre crédible l’îlot du CDG : sans s'en rendre compte l'oeil va être sensible à cette complexité d'objet sur les flanc de l’îlot...
Ce qui impressionne sur ce genre de navire (dans la vraie vie) c'est la multitude d'objets, la complexité de ce qu'il y a sur un pont d'envol. Donc j'essaie de modéliser un maximum d'objets différents sur le pont (cales, élingues, chaines, tracteurs, chariots, extincteurs, caissons, etc...) et sur l’îlot (rampes, échelles, essuie-glaces, projecteurs, haut-parleurs, antennes, etc...). Aucun des ces objets ne coûtent beaucoup en polygones et le rendu au final est (de mon point de vue) très efficace...
Une fois que ça est en place et qu'en plus, avions et personnages sont aussi là, et bien si il me reste un peu de marge sur une limite de polygones (purement psychologique) alors je regarderai sous le pont, mais a priori arrivé à ce stade du projet j'aurai envie de passer à autre chose...=D
A+
Fro'
Hello,
A ce sujet, comment donner les bonnes coordonnées XYZ du Tacan et de l'ILS pour un bateau ? car j'ai fait un copier/coller à partir du Foch ; cela fonctionne pas trop mal, mais c'est pas forcément parfait.
Ce sont des données liées à chacun des modèles, le plus simple est de demander à l'auteur pour qu'il précise les positions (en mètre) de l'antenne Tacan et de la zone d'appontage... Sinon, il doit toujours être possible de les trouver en positionnant un effet lumineux (après avoir converti le navir en avion et en utilisant les Lights du Aircraft.cfg...)
Pourquoi la couche restitution du HUD n'affiche pas les données alors qu'elle utilise les mêmes variables que la gauge RFN, je ne sais pas ? Je ne suis pas assez fort en programmation "FSX" pour le déterminer.
Justement ce sont les mêmes variables mais la gauge 3.2 et le code du HUD ne leur donne pas les mêmes valeurs donc forcément il y a conflit 18 fois par seconde...
Sinon au final, je note que ta proposition triple les calculs des différentes variables puisque tu mets en parallèle le code du HUD, la gauge RFN v2 et la gauge RFN V3... Cela fait beaucoup...
Encore une fois ma recommandation est de ne garder qu'une gauge RFN (la v3) et d'enlever toute la partie détection du porte-avions (couche basse) et calcul des variables (couche intermédiaire) de la gauge HUD.
C'est plus simple et nettement plus léger pour le système...
A+
Fro'
Hello messieurs,
En lisant les différents débats qu'il peut y avoir autour du "Freeware vs payware", j'ai souvent l'impression qu'il y a un grand malentendu sur ce qui distingue un créateur d'AddOn gratuit d'un autre d'addOn payant...
Personnellement, j'ai eu moi-même pendant longtemps, une image du monde du payware extrêmement caricaturale, imaginant que derrière un Iris ou un Razbam se cachait des plateaux entier d'open space remplis de codeurs, graphistes, avec des piles de docs et plans d'usine partout...
Quelle fut ma surprise de découvrir que beaucoup de ces gens qui travaillaient sur ces projet payware n'étaient en fait que des gens comme n'importe quel développeur de freeware, qui bossaient sur leur modèles en marge de leur journées de boulot et qui parcourent les forums techniques FS afin de comprendre/partager comment le SDK est foutu...
Après pourquoi payant ou gratuit?!?
Certains restent dans le gratuit pour ne pas avoir à gérer la relation commerciale et les "exigences" des clients mécontents ("j'ai payé, j'exige!") ou parce que travaillant en équipe il est plus simple de ne pas introduire de notion de rémunération dans le groupe...
D'autres, au contraire, préfèrent passer dans le payant pour établir une distance avec l'utilisateur et la communauté FS qui peut parfois être très envahissante ("il faut changer ceci, cela, etc..."), ou pour marquer/renforcer la notion de copyright (il est incroyable de voir combien de gens pensent que freeware signifie libre de droit...) ou encore, plus bêtement, parce que il est parfois difficile (voir impossible) de se payer son matériel ou une licence 3DSmax sans un apport d'argent extérieur (l'effet de l'outil est loin d'être neutre : entre le gain de temps et de qualité du rendu, etc...)...
Toutes ces raisons sont louables et il n'y a pas à juger les choix de chacun et de faire 2 catégories distinctes : le bon (bénévole, freeware) et le méchant (cupide, payware)!?!
Après est-ce du partage? Peu importe, la "communauté" FS a besoin des deux aspects pour continuer à se renouveler, en pratique il s'agit d'une seule et même population de créateurs et si vous voulez vous en convaincre, allez sur les forum "techniques" vous y trouverez mélangés tous les acteurs, qui y discutent, échangent, progressent, etc...
Et c'est bien cela qui, au final, fait que FSX est toujours une simu intéressante pour les joueurs après tout ce temps!
Personnellement je remercie autant un Dino Cattaneo pour son T45 gratuit qu'un Lotus pour son Albatros payant : il fallait le même courage et la même passion aux 2 pour me permettre, 2 ans après le début de leur projet, de voler avec leur bébé!!
Enjoy messieurs!!
Fro'
mmm... je ne vois rien qui expliquerait pourquoi maintenant les gauges ne se chargent pas toutes comme il faut dès la 1ière fois et qu'il faut recharger le vol pour obtenir un chargement complet...
Est-ce que cela fonctionne si tu lances ton vol via un avion "neutre" (le Cessna par ex) avant de changer d'avion pour l'ETD?
Autre chose, au début du vol (avant de recharger le vol), est-ce que passer sur le tableau de bord 2D (Maj+2 par ex) règle le problème?
A+
Fro'
Surprenant...
Je ne vois pas de lien entre l'initialisation de la gauge Etendard_FSX.gau et RFN_CarrierGauge.dll....=(
Je te conseille de mapper la fonction "rechargement de l'avion" (fonction FS non nativement mappée sur une touche) : cela est très pratique pour rafraichir avion et gauge sans recharger tout le décors...
Sinon est-ce que cela t'arrive dans tous les cas (vols libres et vols enregistrés) ou juste vols enregistrés?
Dernière possibilité, est-ce que FSUIPC est toujours fonctionnel chez toi?
A+
Fro'
moi avec la nouvelle gauge installer sur le IVM et IVP j'ai un souci je doit redémarrer le vol avant de démarrer l'avion pour que la gauge pour le carburant fonctionne ainsi que le surgonflage de l'amortisseur avant je voulait savoir si d'autre avait se souci mais a par sa tout fonctionne
Hello,
Que veux-tu dire par "Redémarrer le vol avant de démarrer l'avion"?
Le sur-gonflage et la jauge carburant sont gérés par Entendard_FSX.gau qui fournit aussi toutes les gauges du panel 2D, as-tu fais des modifs dans le panel 2D d'origine?
A+
Fro'
Bonjour fro,
comme évoqué dans mon post 2546, j'ai installé la version V3 et c'est une vrai merveille. J'ai remarqué en plus des constatations de mon post, c'est que lorsque à bord du PA, on se présente au break à 800ft, on obtient déjà les indications de l'OA qui nous signifie que l'on est bien sur trop haut...Chose qui n'arrivait pas avec la version 2. L'annonce "contact 1nq5" manque de jour en percée et aussi de nuit. En espérant que vous trouverez mes remarques constructives et surtout continuez car votre travail est remarquable. Merci
Hello,
Des annonces OA alors le train est rentré? ? Pas normal en effet... il faudra que je regarde...
Concernant l'annonce "1NM5", comme tu le précises, il s'agit d'une annonce de l'approche CCA et non de l'approche à vue. Nous avons prévue d'intégrer le circuit CCA un peu plus tard car il demande plus de réflexion/tests donc pour l'instant il faut se contenter du seul circuit "à vue"...
j'ai essayé ! et catastrophe , j'ai été obligé de désinstaller l'avion
Michel te dirait de toujours faire une copie de sauvegarde de son aircraft.cfg avant toute modification...
Après croiser le VC d'un modèle avec l'extérieur d'un autre c'est assez simple au final : je t'invite à jeter un coup d'oeil au contenu des fichiers model.cfg de l'ETD IVM 4pts avec altimètre pour voir comment on peut utiliser des alias (ou chemin) pour mélanger modèle ext et VC...
A+
Fro'
BONJOUR à tous ( je relance ce post noyé par d'autre bien plus techniques )
une petite question simple : ( posée à Géoair mais il doit être occupé .... )
est ce que les livrées " P " vont sans problème sur les avions de type " M " ( Etendard )
mon but est d'avoir un lisse 2 bidons avec une livrée " camouflée .merci d'avance
@+ JAHNA
Hello,
la question est sans vraie réponse : "sans problème"? forcément non car tu auras obligatoirement un problème au niveau du nez!
Pour autant , le reste de l'avion est identique donc c'est question d'appréciation de ta part...
Qu'est-ce qui t'empêche de faire l'essais? Il s'agit juste d'une modif dans le aircraft.cfg pour qu'un IVM utilise les textures d'un IVP....
Après les paintkit sont disponibles donc tu pourras aussi corriger les défauts si tu le souhaites...
En d'autres termes : essaies et dis-nous, car nous n'avons pas essayé!
A+
Fro'
Hello,
Je poursuis la conversation ici car c'est un sujet qui peut intéresser autant des codeur de gauges pure-XML (comme un HUD) que des codeurs de cockpit 3D.
...En fait la nouvelle gauge n'alimente pas les données nécessaires au Tacan et à l'ILS du HUD....
Non, la gauge C++ alimente l'ensemble des variables nécessaires (et même un peu plus...)! Regarde la dernière page de la doc fournie avec la gauge et tu trouveras la liste des variables alimentées par la dll.
Nativement dans FSX il n'y a pas de Tacan et/ou d'ILS sur des porte-avions AI : toutes les fonctions de nav sont calculées par FSX à partir de coordonnées fixes. Donc pour obtenir le même résultat (apparent) à partir d'un navire en mouvement , il est nécessaire de reconstruire totalement les fonctions en dehors.
Synthétiquement il y a 3 couches fonctionnelles:
1) Couche "basse": l'identification et la localisation du porte-avions
2) Couche "intermédiaire" : le calcul et l'alimentation des variables de nav
3) Couche "utilisateur" : la restitution
Dans le package 3.2, la couche basse est réalisée par la multi-gauge (partie du code commune à toutes les gauges de la dll), elle utilise Simconnect pour obtenir de FSX les informations élémentaires nécessaires (position/cap/vitesse, altitude de l'avion, liste des navires AI, position/cap/vitesse du navire désigné, etc...). C'est aussi cette couche qui récupère de Carrier.xml tous les paramètres nécessaires au fonctionnement des gauges.
La couche "intermédiaire" est réalisée dans la multi-gauge et dans la sous-gauge TACAN_Nav1 (ou TACAN_Nav2): le calcul (à base de trigonométrie sphérique etc...) est fait dans la multi-gauge, et les conversions finales et alimentation des variables L: sont faites par la sous-gauge.
Enfin, la partie "utilisateur" est faite par la gauge XML "Tacan_Indicator". Il s'agit de la partie visible du système qu'on a mis dans un gauge 2D générique afin de pouvoir "équiper" n'importe quel avion, mais elle peut réalisée directement dans le VC (comme dans l'ETD) ou dans une autre gauge (comme un HUD par ex). Pour cela il suffit d'utiliser les variables L: mises à dispo par la couche intermédiaires comme on le ferait avec n'importe quelles autres variables FS.
Le HUD de J.Rusev est particulier pour 2 raisons:
1) son code contient les 3 couches fonctionnelles dont j'ai parlé ci-dessus (donc il y a des redondances avec la dll RFN)
2) l'affichage des réticules utilisent les mêmes variables L: que celles de la gauge RFN : je suis en contact avec l'auteur et me suis coordonné avec lui pour utiliser exactement les mêmes variables.
En effet, Jivko travaille sur une version de ses gauges HUD 100% compatibles avec la gauge RFN : le code teste la présence de la gauge RFN et, selon si elle est présente ou non, soit il utilise directement les variables L: (couche utilisateur seule) ou soit il fait appelle à une autre partie du code pour exécuter préalablement les 2 couches fonctionnelles manquantes...
En attendant ces nouvelles moutures, tu peux toujours shunter les parties basse et intermédiaire du code existant du HUD : cela t'éviteras tout parasitage dans les variables L:...C'est relativement simple d'isoler les partie purement affichage du reste du code...
De la même façon, il est assez peu complexe d'enrichir un HUD non équipé (comme celui du F14 d'IRIS) de telles fonctions...
En espérant que tout cela est assez clair,
A+
Fro'
A+
Fro'
Hello Gilles,
Je ne suis pas sûr de comprendre ce que tu as fait...
Il y a dans les HUD de J.Rusev une partie détection de porte-avions et calcul de variable qui est aussi présente dans les V2 et V3 de mes gauges RFN.
Que l'on utilise le radius ou le nom AI cela ne change pas grand chose au calcul des variables L :
La V3 a beau être en C++ elle calcule quand même les variables L: dont tu trouveras la liste dans la doc....
A+
Fro'
Bonjour à tous.
Mes problème avec la mission nounou sont résolus.
Je suis repassé en version 2.1 du Clemenceau au lieu de la version 3.2 et là tous fonctionne correctement.
J'avais pourtant modifié le fichier .xml comme spécifié dans le readme.Merci à vous
Cordialement
Hello,
Les missions ont été faites avant la sortie des Clemenceau/Foch "années 75", donc, de mémoire, je dirais qu'il est normal que la mission "Nounou AI" ai besoin du Clemenceau 2.10 qui correspond à la version "années 90" utilisée par cette dernière...
Après libre à chacun de modifer les fichiers des missions pour utiliser le Clem '75 ou le Foch '75....
D'une manière générale, le package Clemenceau/Foch 3.20 ne remplace pas le Clemenceau 2.10 mais le complète...
A+
Fro'
Bonjour,
Je ne sais pas, si mon post est bien au bon endroit . . !
Juste une question: avec la nouvelle gauge dispo pour le Fouga, il est dit :
Dans le panel du Zéphyr, il faut vérifier que toutes les lignes relatives au compas sont bien en version B :
Fouga_FSX!Gyromagnetic_Compass_BLorsque je verifie cela, je trouve bien dans le panel, des lignes en version B, sauf pour la window 03, où là j'ai :
gauge01=Fouga_FSX!Gyromagnetic_Compass_A.
Est-ce normal ?
Merci de votre réponse
Hello,
Peut-être pas anormal, mais pour s'assurer une meilleure cohérence entre les différentes vues du tableau de bord, il vaut mieux tout passer en _B
A+
Fro'
Bonjour,
je viens de charger et installer RFN TACAN 3.20 !
J'ai bien compris qu'il faut modifier le panel cfg des appareils, MAIS cela concerne t il aussi les dernières version du ZEPHYR et de l'ETENDARD ?
merci et bon courage pour le Crouze !;)
Hello Dutrla,
Oui le Zéphyr et l'Etendard sont à modifer avec l'arrivée de la V3.20.
Michel a mis un nota spécifique à ces 2 panel.cfg dans le read me (Nota2 je crois)
Pour le Zéphyr, Michel a en plus partagé quelques éléments spécifiques dans ce fil de discussion il y a quelques jours.
Si tu as des difficultés n'hésites à revenir vers nous?
A+
Fro'