Aide - Recherche - Membres - Calendrier
Version complète : Nouveauté Export LOFC2
3rd-Wing · Escadre virtuelle DCS > DCS (& LockOn) > 3rd Wing devs' zone > KaTZ-Pit - SIOC & Gauge Composer
edrom
Salut les lockoneux,

Je crée ce post pour centralisé sur le forum, pour ceux qui veulent, les nouvelle capacité trouvé dans les LOfonction de l'export LOFC2. ce serai pas mal que chacun y poste ce qu'il a trouvé.
même si ce n'est pas forcement une nouveauté par rapport a LOFC1


-- Nbre chaff et flare :
_LoGetSnares = LoGetSnares()
envoyerInfo("250",_LoGetSnares.chaff)
envoyerInfo("251",_LoGetSnares.flare)

-- Nombre de munitions canon restantes (Merci Katze)
local _canon = _LoGetPayloadInfo.Cannon.shells
envoyerInfo(211,_canon)

Quelqu'un a t'il réussi a exploité correctement LogetMechInfo() au niveau des gear?
et qu'est ce que le "airintake" et le "noseflap", j'ai beau scruter les valeur prise par IOCP Console. je ne fait pas le lien avec partie mecanique de l'avion (perche de ravito, entrée d'air ....)

Merci

edrom
Fonction LoGetSightingSystemInfo() :récupere les infos du systeme radar de notre avion
_LoGetSightingSystemInfo = LoGetSightingSystemInfo()
-- constructeur du radar US/Russe (on s'en fout un peu)
local _ModesManufactrer = { RUS=1, USA=2 }
local _strManufactrer = _LoGetSightingSystemInfo.Manufacturer
envoyerInfo("250",_ModesManufactrer[_strManufactrer])
-- aparition autorisation de tir sur le HUD "LA"
envoyerInfo("251",_LoGetSightingSystemInfo.LaunchAuthorized and 1 or 0); -- Ok
-- radar allumé en BVR
envoyerInfo("252",_LoGetSightingSystemInfo.radar_on and 1 or 0); -- Ok
-- IRST allumé
envoyerInfo("253",_LoGetSightingSystemInfo.optical_system_on and 1 or 0); -- OK
-- ECM alumé
envoyerInfo("254",_LoGetSightingSystemInfo.ECM_on and 1 or 0); -- pas testé
-- laser précision (SU25T?)
envoyerInfo("255",_LTToGetSightingSystemInfo.laser_on and 1 or 0); -- pas testé

Mode PRF fréquence signal radar : Ok
local _ModesCurrent = { MED=1, HI=2 }
local _strPRFcurrent = _LoGetSightingSystemInfo.PRF.current
envoyerInfo("256",_ModesCurrent[_strPRFcurrent])

local _ModesSelect = { MED=3, HI=4, ILV=5 }
local _strPRFselection = _LoGetSightingSystemInfo.PRF.selection
envoyerInfo("257",_ModesSelect[_strPRFselection])

je n'ai pas testé le reste des possibilité de cette fonction (elevation antenne, position de la TDC..)

En tout cas, j'ai quelques bidouille faites avec SIOC sous LOFC1 qui vont pouvoir zappé car l'info devient récupérable depuis LOFC2....
edrom
Suite de la fonction LoGetSightingSystemInfo()

Image IPB

avec récup de toutes les donnée du Hud cowboy.gif

-- position curseur radar
envoyerInfo("258",_LoGetSightingSystemInfo.TDC.x*1000); --ok
envoyerInfo("259",_LoGetSightingSystemInfo.TDC.y*1000); -- ok
le curseur radar se déplace, dans mon cas, dans un rectangle dont les coordonnées varie
-1459<x<+1459 et -614<y<1206

-- echelle de distance
envoyerInfo("260",_LoGetSightingSystemInfo.scale.distance/1000); -- ok

--???
envoyerInfo("261",_LoGetSightingSystemInfo.scale.azimuth*180.0/math.pi) -- la valeur est figé a 29 pour SU33???;

-- couverture du radar
envoyerInfo("262",_LoGetSightingSystemInfo.ScanZone.coverage_H.min); --ok
envoyerInfo("263",_LoGetSightingSystemInfo.ScanZone.coverage_H.max); --ok

-- parametre position radar elevation et azimute
envoyerInfo("264",_LoGetSightingSystemInfo.ScanZone.position.azimuth*180.0/math.pi); --ok
envoyerInfo("265",_LoGetSightingSystemInfo.ScanZone.position.elevation*100); --ok

-- distance suposé de la cible
envoyerInfo("266",_LoGetSightingSystemInfo.ScanZone.position.distance_manual/1000); --ok

-- barre de couverture en altitude
envoyerInfo("267",_LoGetSightingSystemInfo.ScanZone.position.exceeding_manual/1000); --ok

--???
envoyerInfo("268",_LoGetSightingSystemInfo.ScanZone.size.azimuth*180.0/math.pi); -- la valeur est figé a 59 pour SU33
envoyerInfo("269",_LoGetSightingSystemInfo.ScanZone.size.elevation*100);-- la valeur est figé a 17 pour SU33

On peut imaginer un HUd fonctionel dans nos pit wink.gif
gillesdrone
Super wink.gif

ca peut deja faire allumer quelques leds du SPO , je suis a la plage , je ne rentre que lundi , je regarde de plus prés

je ferai les tests pour 25T je mettrai le résultat

par contre dans quel mesure tu veux utiliser un HUD dans un pit ?
a partir du moment où tu l'a dans la vue haute , sauf à vouloir mettre la vue haute sans structure de cockpit virtuel et mettre un vidéoprojecteur , dans ce cas , refaire le HUD facon réelle thumbsup.gif

beau challenge thumbsup.gif

Merci
edrom
CITATION(gillesdrone @ 14 May 2010, 11:37) *

Super wink.gif

ca peut deja faire allumer quelques leds du SPO , je suis a la plage , je ne rentre que lundi , je regarde de plus prés

je ferai les tests pour 25T je mettrai le résultat

par contre dans quel mesure tu veux utiliser un HUD dans un pit ?
a partir du moment où tu l'a dans la vue haute , sauf à vouloir mettre la vue haute sans structure de cockpit virtuel et mettre un vidéoprojecteur , dans ce cas , refaire le HUD facon réelle thumbsup.gif

beau challenge thumbsup.gif

Merci


En fait la fct LoGetSightingSystemInfo() ne sert a rien pour le SPO, c'est LoGetTWSInfo() qui est utile pour le SPO (deja présente dans LOFC1).
Je n'ai pas vu de modif dans l'export lua pour cette fct....
j'espere me tromper, mais je crois qu'on aura pas mieux que LOFC1 pour le SPO.

"Avoir un HUD fonctionnel dans un cockpit"? Disons que c'est a présent possible dans lockon et ca servira surement aux grands malades qui voudrait d'un HUD fonctionnel comme c'est le cas des constructeur de cockpit pour Falcon 4. mais j'avou ne pas savoir comment faire au niveau du hardware...
yoyo_the_reaper
CITATION(edrom @ 14 May 2010, 14:02) *

CITATION(gillesdrone @ 14 May 2010, 11:37) *

Super wink.gif

ca peut deja faire allumer quelques leds du SPO , je suis a la plage , je ne rentre que lundi , je regarde de plus prés

je ferai les tests pour 25T je mettrai le résultat

par contre dans quel mesure tu veux utiliser un HUD dans un pit ?
a partir du moment où tu l'a dans la vue haute , sauf à vouloir mettre la vue haute sans structure de cockpit virtuel et mettre un vidéoprojecteur , dans ce cas , refaire le HUD facon réelle thumbsup.gif

beau challenge thumbsup.gif

Merci


En fait la fct LoGetSightingSystemInfo() ne sert a rien pour le SPO, c'est LoGetTWSInfo() qui est utile pour le SPO (deja présente dans LOFC1).
Je n'ai pas vu de modif dans l'export lua pour cette fct....
j'espere me tromper, mais je crois qu'on aura pas mieux que LOFC1 pour le SPO.

"Avoir un HUD fonctionnel dans un cockpit"? Disons que c'est a présent possible dans lockon et ca servira surement aux grands malades qui voudrait d'un HUD fonctionnel comme c'est le cas des constructeur de cockpit pour Falcon 4. mais j'avou ne pas savoir comment faire au niveau du hardware...

Salut, je confirme pour le LoGetTWSInfo, c'est comme sur FC1 , il me reste a tester les missile actif (la puissance envoyée par lock était trop importante)
par contre avez vous essayé la fonction LoGetTargetInformation ? cela correspond aux cibles vues par le radar en mode LRS (sur le F15) et il semble qu'elle envoie des informations de façon non régulière (même si les cibles sont vues dans le VSD radar sur lock on )
merci par avance
Tarochi
[quote name='edrom' date='14 May 2010, 14:02' post='114576']
[quote name='gillesdrone' post='114573' date='14 May 2010, 11:37']
"Avoir un HUD fonctionnel dans un cockpit"? Disons que c'est a présent possible dans lockon et ca servira surement aux grands malades qui voudrait d'un HUD fonctionnel comme c'est le cas des constructeur de cockpit pour Falcon 4. mais j'avou ne pas savoir comment faire au niveau du hardware...
[/quote]


http://www.simmeters.com/?cat=26

http://www.youtube.com/watch?v=D90eKMOjYlo
http://www.youtube.com/watch?v=GfPfH4k1pG4

saianlol.gif


Salut.

Tarochi
gillesdrone
Salut Tarochi smile.gif

bon je vais finir par avoir besoin du camion du cirque Pinder pour me rendre aux LAN moi wink.gif

yoyo_the_reaper
CITATION(edrom @ 14 May 2010, 10:53) *


envoyerInfo("268",_LoGetSightingSystemInfo.ScanZone.size.azimuth*180.0/math.pi); -- la valeur est figé a 59 pour SU33
envoyerInfo("269",_LoGetSightingSystemInfo.ScanZone.size.elevation*100);-- la valeur est figé a 17 pour SU33

On peut imaginer un HUd fonctionel dans nos pit wink.gif


bonjour
sur le F-15 , LoGetSightingSystemInfo.ScanZone.size.azimuth peut etre 120° ou 60° en fonction des paramètre radar cela donne l'angle total balayé par l'antenne , par contre en elevation c'est fixe comme vous sur le 33
@+
gillesdrone
vous confirmez que vous retrouvez le meme fonctionnement pour le SPO qu'avec FC1 ?
yoyo_the_reaper
CITATION(gillesdrone @ 17 May 2010, 12:09) *

vous confirmez que vous retrouvez le meme fonctionnement pour le SPO qu'avec FC1 ?

bonjour
pour ma part je n'ai pas trouvé de grosse différence, il y'a le même type d'information soit azimut , puissance, priorité et type du signal (complétée de l'ID cible)
après cela dépend des exports lua .....
voila ce que cela donne pour une émulation du TEWS F15 (pour le SPO , je ne crois pas qu'il y'aura de différence hormis graphique)

http://www.youtube.com/watch?v=1gkh4n5Gmbs

il est pas encore terminé

@+
edrom
CITATION(gillesdrone @ 17 May 2010, 12:09) *

vous confirmez que vous retrouvez le meme fonctionnement pour le SPO qu'avec FC1 ?

he oui.
Par contre, en captant mieux le lua, j'ai éssayé la chose suivante :

dans mon idée, il faudrait gerer le SPO dans le lua avant d'envoyer les infos au serveur SIOC. de façon a gerer, par exemple les led menace principale, comme le fait Lecréole avec _MCPState, cad une valeur binaire qui n'a besoin besoin que de la fonction sioc TESTBIT.
quelques avantages :
en tout premier, discerner le signal principal, des signaux secondaire , de façon a n'utiliser que ses paramètres a lui pour le power , et plus tard : le type (pas encore implémenté)...
les leds s'eiteigne quand la menace disparait.
On peut gere autant de menaces secondaires que l'on souhaite
Ben ça marche pas mal.... he, he, he

On va exploiter la fonction lua LoGetTWSInfo()
il y'a tout ce qu'il faut pour allumé notre SPO
cette fonction renvoi 2 objets
1- le mode courant, facile a récupérer
2- une table des menaces contenant paur chaque menace, 6 parametres
ID =, -- world ID
Type = {level1,level2,level3,level4}, -- world database classification of emitter
Power =, -- power of signal
Azimuth =,
Priority =,-- priority of emitter (int)
SignalType =, -- string with vlues: "scan" ,"lock", "missile_radio_guided","track_while_scan";


algo de mon traitement
1- creer une table de 10 lignes et 7 colones
chaque ligne est le détail d'une menace contenat ses 7 parametres

rq : qulqu'un sait combien de signaux peuvent etre capté par le SPO dans la vrai vie?

2- je fait une boucle de lecture de toutes les menaces détecté par le SPO
pour chaque "signal", allimentation de de mon tableau ligne a ligne

3 - déterminer le signal principale:
boucle de lecture de mon tableau pour identifier le signal ayant le Priority le plus élever

apres cette étapes, j'ai :
1-le signal principal avec son Power, azimut, ID et Type :-> gerera les leds azimut orange et power
2-une table de tous les autres signaux avec azimut et Type :-> gerea les leds azimut vertes

a coté de ça, je creé quelques fonction utiles pour tout gere dans le lua
-function SPOledAzim(Azimut) : prend un azimut en entree, et renvoi une table de 10 poste, correspondant aux 10 leds azimut (principale ou secondaire)
-function SPOConversion(t_Led) : prend une table de 10 poste (correspondant aux 10 leds azimut) et renvoi un nombre en binaire qui sera envoyé a SIOC a travers un offset
-function SPOdetermineLedVerte(t_LedVerte) : prend une matrice contenant 10 tables t_Led en entree et renvoi une table de 10 poste t_Led : cette fonction a pour but de combiner les divers signaux vert de facon a envoyé au SIOC une "concaténation" des signaux vert
les leds vertes ne clignoterons pas car a chaque boucle c'est la concaténation qui sera interprété par lua.

j'ai égallement crée 2 autres fonctions pour géré le signal principal
-function SPOdeterminePowerMenacePrincipale(power) : prend un power en entrée, et renvoi une valeur binaire qui sera envoyé a SIOC a trvers un offset
-function SPOledBH(_Alt1,_Alt2) : prend 2 altitude en entre et renvoi un chiffre qui sera envoyé a SIOC a trvers un offset.


code commenté, a ajouter dans la boucle principale apres la fin de LoGetPayloadInfo() par exemple


_LoGetTWSInfo2 = LoGetTWSInfo()
if _LoGetTWSInfo2 then
-- SPO Mode : 0:all, 1:lock only, 2:launch only
envoyerInfo("270",_LoGetTWSInfo2.Mode)
-- nombre de radar détecté par le SPO
local _tableSPO = _LoGetTWSInfo2.Emitters
local _NbreSignaux = table.getn(_tableSPO);
envoyerInfo("271",table.getn(_tableSPO))

-- déclaration table des 10 signaux recu par le SPO
logData("******** Detection SPO **************")
t_menace = {} -- create the matrix
for i=1,10 do
t_menace[i] = {} -- create a new row
for j=1,7 do
t_menace[i][j] = 0
end
end

--t_LedVerte = 10 poste de chcun des azimut
t_LedVerte = {} -- create the matrix
for s=1,10 do
t_LedVerte[s] = {} -- create a new row
for u=1,10 do
t_LedVerte[s][u] = 0
end
end

local _ModesScan ={scan=0,lock=1,missile_radio_guided=2,track_while_scan=3,missile_active_homing=
4}

-- allimentation de mon tableau avec le emmitter_table
for i = 1, _NbreSignaux do
_objet = _tableSPO[i]
t_menace[i][1] = _objet.Power*1000
t_menace[i][2] = _objet.Azimuth*1000
local objEmitters = LoGetObjectById(_objet.ID)
t_menace[i][3] = objEmitters.Name
t_menace[i][4] = tonumber(_objet.Type.level1.._objet.Type.level2.._objet.Type.level3.._objet.Type.level4)
t_menace[i][5] = _objet.Priority
local _strScan = _objet.SignalType
t_menace[i][6] = _ModesScan[_strScan]
--local _Menacedtail = "avion = "..t_menace[i][3].." avec SignalType ****".._objet.SignalType
--logData(_Menacedtail)
t_menace[i][7] = _objet.ID
end
-- déclaration de variable contenant le signal principale
local Pri_pow = 0 -- power de la menace principale
local Prim_Azim = 0 -- azimut de la menace principale
local Prim_Name = 0 -- nom de la menace principale
local Prim_Type = 0 -- type menace principale
local Prim_Priority = 0 -- Priorité signal
local Prim_SignalType = 0 -- signal : scan=0,lock=1,missile_radio_guided=2,track_while_scan=3,missile_active_homing=4
local Prim_ID = 0
k = 0 -- nombre de menace secondaire
logData("tableau des menaces");
for j = 1, table.getn(t_menace) do
-- regle de détermination du plus menacçant : priority le plus élevé
if t_menace[j][5] > 0 then
--** detail radar détecté par SPO
local _Menacedtail = "présence radar : ".. t_menace[j][3].." : Pwr = "..t_menace[j][1].." Azim = "..t_menace[j][2].." Priority = "..t_menace[j][5].." SignalType = "..t_menace[j][6]
logData(_Menacedtail)
if t_menace[j][5] > Prim_Priority then
Pri_pow = t_menace[j][1]
Prim_Azim = t_menace[j][2]
Prim_Name = t_menace[j][3]
Prim_Type = t_menace[j][4]
Prim_Priority = t_menace[j][5]
Prim_SignalType = t_menace[j][6]
Prim_ID = t_menace[j][7]
end
k= k + 1
_LibMenace = " signal menace(s) secondaire = "..t_menace[j][3]..", Azimut="..t_menace[j][2]..", Type="..t_menace[j][4]..", Priority = "..t_menace[j][5]
logData(_LibMenace)
SPOledAzim(t_menace[j][2]) -- prend un azimut , renvoi un t_Led
t_LedVerte[k] = t_Led
end
end

-- a ce stade, nous avons la menace principale avec les var PRi_xxx et un tableau contenant 10 tables pour 10 potentiel menaces secondaire.
remarque : les leds vertes s'allume pour les menaces secondaires et egalement la principale, c'est ce que j'en comprend.


-- ********************************************************************************
**************************
--******************************* MENACE PRINCIPALE ************************************************
local _LibMenace = " signal menace Principal = "..Prim_Name.."-"..Prim_Type..", Priority = "..Prim_Priority..", Power = "..Pri_pow
logData(_LibMenace)

if _NbreSignaux == 0 then
envoyerInfo("272", 0) -- azimut
envoyerInfo("276", 0) -- power
envoyerInfo("278", 0) -- B/H
envoyerInfo("274", 0) -- type
envoyerInfo("277", 0) -- Signal
else
--1_AZIMUT
-- appel fonction determination azimut -> led
SPOledAzim(Prim_Azim)
-- conversion en base binaire
SPOConversion(t_Led)
-- envoi AZIMUT offset qui sert a SIOC : 2 72
envoyerInfo("272", _Traduc);
--2_Power
SPOdeterminePowerMenacePrincipale(Pri_pow)
envoyerInfo("276",_ValPower);

--3_Type
envoyerInfo("275",Prim_Type);
-- pour l'instant, je ne l'exploite qu'a travers le SIOC avec les fonction de Lecreole/Gillesdrone (offset 175)

--4_Signal {scan=0,lock=1,missile_radio_guided=2,track_while_scan=3,missile_active_homing=4
}
-- pas compris pour l'instant, j'utilise _LoGetTWSInfo de Lecreole.

--5_Position relative signal principale (au dessus, en dessous)
--5a altitude menace principale
local _objEmitterP = LoGetObjectById(Prim_ID);
local _AltiMenacePrincipal = _objEmitterP.LatLongAlt.Alt;
--5b- mon altitude
local _objMoi = LoGetSelfData();
local _AltimonAvion = _objMoi.LatLongAlt.Alt;

SPOledBH(_AltiMenacePrincipal,_AltimonAvion)
envoyerInfo("278",_ValBH);

end
-- ********************************************************************************
**************************
--******************************* MENACE SECONDAIRE *************************************************
if _NbreSignaux == 0 then
envoyerInfo("273", 0) -- azimut
envoyerInfo("275", 0) -- type
else
-- appel fonction determination azimut -> led
SPOdetermineLedVerte(t_LedVerte);
-- conversion en base binaire
SPOConversion(t_Led)
-- envoi AZIMUT offset qui sert a SIOC : 273
envoyerInfo("273",_Traduc)
end

end
-- ci dessous les fonction lua a ajouter a la fin du fichier principal, apres la fonction function logData(message)

function SPOledAzim(Azimut)
L0 = math.ceil(Azimut * 5.729578)
t_Led = {0,0,0,0,0,0,0,0,0,0} -- table contenant les dix led Azimut '0'(eteint) ou '1' (allumé)

--********************************
if L0 < -11000 then
t_Led[1]= 1
end
--********************************

if L0 > -11000 and L0 <= -6000 then --LED - 90
t_Led[2]= 1
end
--********************************
if L0 >= -8000 and L0 <= -3500 then --LED -50
t_Led[3]= 1
end
--********************************
if L0 >= -4500 and L0 <= -1500 then --LED -30
t_Led[4]= 1
end
--********************************
if L0 >= -2500 and L0 <= 500 then
t_Led[5]= 1
end
--********************************
if L0 >= -500 and L0 <= 2500 then
t_Led[6]= 1
end
--********************************
if L0 >= 1500 and L0 <= 4400 then
t_Led[7]= 1
end
--********************************
if L0 >= 3500 and L0 <= 8000 then
t_Led[8]= 1
end
--********************************
if L0 >= 6000 and L0 <= 11000 then
t_Led[9]= 1
end
--********************************
if L0 > 11000 then --LED ARRIERE DROITE
t_Led[10]= 1
end

return t_Led
end




function SPOConversion(t_Led)
_Traduc = 0
if t_Led[1] ==1 then
_Traduc = _Traduc + 1
end
if t_Led[2] ==1 then
_Traduc = _Traduc + 256
end
if t_Led[3] ==1 then
_Traduc = _Traduc + 128
end
if t_Led[4] ==1 then
_Traduc = _Traduc + 64
end
if t_Led[5] ==1 then
_Traduc = _Traduc + 32
end
if t_Led[6] ==1 then
_Traduc = _Traduc + 16
end
if t_Led[7] ==1 then
_Traduc = _Traduc + 8
end
if t_Led[8] ==1 then
_Traduc = _Traduc + 4
end
if t_Led[9] ==1 then
_Traduc = _Traduc + 2
end
if t_Led[10] ==1 then
_Traduc = _Traduc + 512
end
return _Traduc

end

function SPOdetermineLedVerte(t_LedVerte)
t_Led = {0,0,0,0,0,0,0,0,0,0} -- table contenant les dix led Azimut '0'(eteint) ou '1' (allumé)
local _sum = 0
--[[
for p=1,10 do
local _LibMenace = "boucle itérative table t_LedVerte : poste"..p
for toto = 1, 10 do
_LibMenace = _LibMenace..", V"..toto.." = "..t_LedVerte[p][toto]
end
logData(_LibMenace)
end
--]]
for x=1,10 do
_sum = 0
for y=1,10 do
_sum = _sum + t_LedVerte[y][x]
end
if _sum > 0 then
t_Led[x] = 1
end
end
logData(& quot;***************************************************************************
**")
_LibMenace = "*************************resultat du cumul"
for toto = 1, 10 do
_LibMenace = _LibMenace..", V"..toto.." = "..t_Led[toto]
end
logData(_LibMenace)
logData(& quot;***************************************************************************
**")

return t_Led
end

function SPOdeterminePowerMenacePrincipale(power)
_ValPower = 0
if power > 0 then
_ValPower = 1
end
if power > 50 then
_ValPower = _ValPower + 2
end
if power > 100 then
_ValPower = _ValPower + 4
end
if power > 150 then
_ValPower = _ValPower + 8
end
if power > 210 then
_ValPower = _ValPower + 16
end
if power > 280 then
_ValPower = _ValPower + 32
end
if power > 330 then
_ValPower = _ValPower + 64
end
if power > 400 then
_ValPower = _ValPower + 128
end
if power > 520 then
_ValPower = _ValPower + 256
end
if power > 600 then
_ValPower = _ValPower + 512
end
if power > 666 then
_ValPower = _ValPower + 1024
end
if power > 730 then
_ValPower = _ValPower + 2048
end
if power > 800 then
_ValPower = _ValPower + 4096
end
if power > 865 then
_ValPower = _ValPower + 8192
end
if power > 900 then
_ValPower = _ValPower + 16384
end
return _ValPower
end

function SPOledBH(_Alt1,_Alt2)
-- ne connaissant pas les regle exacte pour la gestion des led B et H, je part du principe que :
-- si le signal est a + de 3000 m de moi, c'est la B qui s'allume
-- si le signal est a - de 3000 m de moi, c'est la H qui s'allume
-- si entre -3000 et 3000, B et H allumé

_ValBH= 0
local _delta = _Alt1 - _Alt2
if _delta > 3000 then
-- au dessus
_ValBH = 1
else
if _delta > -3000 then
-- meme niveau
_ValBH = 2
else
-- en dessous.
_ValBH = 3
end
end
_LibMenace = " _AltiMenacePrincipal = ".._Alt1..", _AltimonAvion = ".._Alt2.." : delta = ".._delta.." équivalent a _ValBH = ".._ValBH
logData(_LibMenace)
return _ValBH
end

-- ********************************
-- coté SIOC : beaucoup plus simple
--********************************

........
Var 0270, name Lo2_twsMode
Var 0271, name Lo2_NbrEmiter
Var 0272, name LedSPOPri
{
CALL &Sub_Principal, &LedSPOPri
}
Var 0273, name LedSPOSec
{
CALL &Sub_Second, &LedSPOSec
}
Var 0274, name SPOtypePrin
{
&TypeSPOpri = &SPOtypePrin
CALL &typAWACS
CALL &typAERO
CALL &typLONGP
CALL &typMOYENP
CALL &typSHORTP
CALL &typEWR
}
Var 0275, name SPOtypeSec
Var 0276, name SPO_Pw_Pr
{
CALL &Sub_PowPrin, &SPO_Pw_Pr
}
Var 0277, name signSPO // etat du signal SPO / Scan, Lock etc
Var 0278, name SPOledBH
{
CALL &Sub_SPO_BH, &SPOledBH
}

....



avec


Var 0822, name Sub_Principal, Link SUBRUTINE // Azimuth SPO
{
L0 = &LedSPOPri
&V_SPOARG = TESTBIT L0 ,0 // 1=AG
&V_SPOD90 = TESTBIT L0 ,1 // 2=G90
&V_SPOD50 = TESTBIT L0 ,2 // 4=G50
&V_SPOD30 = TESTBIT L0 ,3 // 8=G30
&V_SPOD10 = TESTBIT L0 ,4 // 16=G10
&V_SPOG10 = TESTBIT L0 ,5 // 32=D10
&V_SPOG30 = TESTBIT L0 ,6 // 64=D30
&V_SPOG50 = TESTBIT L0 ,7 // 128=D50
&V_SPOG90 = TESTBIT L0 ,8 // 256=D90
&V_SPOARD = TESTBIT L0 ,9 // 512=AD
}

Var 0823, name Sub_Second, Link SUBRUTINE // Azimuth SPO
{
L0 = &LedSPOSec
&V_verSPOAG = TESTBIT L0 ,0 // 1=AG
&V_verSPOD90 = TESTBIT L0 ,1 // 2=D90
&V_verSPOD50 = TESTBIT L0 ,2 // 4=D50
&V_verSPOD30 = TESTBIT L0 ,3 // 8=D30
&V_verSPOD10 = TESTBIT L0 ,4 // 16=D10
&V_verSPOG10 = TESTBIT L0 ,5 // 32=G10
&V_verSPOG30 = TESTBIT L0 ,6 // 64=G30
&V_verSPOG50 = TESTBIT L0 ,7 // 128=G50
&V_verSPOG90 = TESTBIT L0 ,8 // 256=G90
&V_verSPOAD = TESTBIT L0 ,9 // 512=AD
}


Var 0801, name Sub_PowPrin , Link SUBRUTINE // Power SPO
{
L0 = &SPO_Pw_Pr
&V_PSPO1 = TESTBIT L0 ,0
&V_PSPO2 = TESTBIT L0 ,1
&V_PSPO3 = TESTBIT L0 ,2
&V_PSPO4 = TESTBIT L0 ,3
&V_PSPO5 = TESTBIT L0 ,4
&V_PSPO6 = TESTBIT L0 ,5
&V_PSPO7 = TESTBIT L0 ,6
&V_PSPO8 = TESTBIT L0 ,7
&V_PSPO9 = TESTBIT L0 ,8
&V_PSPO10 = TESTBIT L0 ,9
&V_PSPO11 = TESTBIT L0 ,10
&V_PSPO12 = TESTBIT L0 ,11
&V_PSPO13 = TESTBIT L0 ,12
&V_PSPO14 = TESTBIT L0 ,13
&V_PSPO15 = TESTBIT L0 ,14

}


Var 0500, name Sub_SPO_BH, Link SUBRUTINE // gestion du B/H SPO
{
IF &SPOledBH = 0
{
&V_lockB = 0
&V_lockH = 0
}
ELSE
{
IF &SPOledBH = 1
{
&V_lockB = 1
&V_lockH = 0
}
IF &SPOledBH = 2
{
&V_lockB = 1
&V_lockH = 1
}
IF &SPOledBH = 3
{
&V_lockB = 0
&V_lockH = 1
}
}
}

-- ca marche bien chez moi, mais ca reste experimental, il y'a surement quelques optimisations a faire ...
-- les prb restants :
1- type de menaces, j'aimerai connaitre la regle pour coder la correspondance Type, led dans le SIOC pour gerer les led comme le reste
2- SignalType : (scan=0,lock=1,missile_radio_guided=2,track_while_scan=3,missile_active_homing=4
) , on en a besoins pour eteindre les led lorsque le SPO ne capte plus de signal (quand on tire fort sur le manche...)
mais je ne comprend pas comment c'est gerer... du coup je garde le code de Lecreole juste pour ça :

_LoGetTWSInfo = LoGetTWSInfo()
local _SignalType ={scan=0,lock=0,missile_radio_guided=0,track_while_scan=0}
local _SignalTypeValeur ={scan=0,lock=1,missile_radio_guided=2,track_while_scan=3}
local _SignalTypeCode = 0;
for k,v in pairs(_LoGetTWSInfo.Emitters) do
local objEmitters = LoGetObjectById(v.ID);
if _SignalType[v.SignalType]==0 then
_SignalType[v.SignalType] = 1;
_SignalTypeCode = _SignalTypeCode + math.pow(2, _SignalTypeValeur[v.SignalType]);
end
end
envoyerInfo("277",_SignalTypeCode);


n'hésiter pas à tester et a améliorer mon code wink.gif
je ne connais pas bien le lua.
KaTZe
Merci Edrom,

C'est exactement le sujet sur lequel je travaillais actuellement.
J'ai les remarque suivantes :

- Valeurs exportées :
Certaines info. me semblent redondantes, par exemple la valeur Priority *1000 semble contenir la puissance (dernier 3 digit) , Les premiers digit représente la menace (160 Scan RR, 260 Lock RR, 360 départ missile FOX1 etc etc ... je suis en train de regarder ces codes pour les classer

- Philosophie d'export :
Il est bien dommage que LO ne numérote pas les emitter en fonction de la priority.
Je ne comprend pas en fonction de quelle valeur les n° d'emitter changent (voir mon log sur le post SPO)
Donc on est obligé d'effectuer le classement nous même.

Ceci dit personellement, je préfère exporter l'azimuth et non la diode à allumer.
Donc pour moi la transformation de l'azimuth en diode pour SPO doit se faire dans SIOC (voir même dans gauge composer si 10<angle<30 then allumer diode.

----------------------------------------------------
Test en cours :
- As tu testé combien d'emitter maxi sont géré par LO
Je vais faire un mission multi avions en début d'après midi et voir l'export (log)

Miaou et encore merci pour les codes, je vais surement piocher dedans wink.gif

Maraudeur
Tant qu'à y être, si vous ne le saviez pas encore: LoVP pour FC 2

Skaiaaaaa wavetowel2.gif
KaTZe
Edrom, je viens de tester une mission avec 48 avions, et LO120 exporte ... 48 emitters (je n'ai donc pas atteins la limite).
Le problème étant que dans ce cas le 48eme était le plus puissant sad.gif

Donc, si l'on veut avoir un SPO correct, il faut donc, dans le code, checker la "priority" de tous les émitter pour les classer et déterminer les (xx?) plus puissant, les exporter.

Autre problème la classification entre RR et SAM pour les Muds
Les menaces RR (160xxx) étant traité avec une priorité supérieure au SAM (140xxx) dans le paramêtre priority, mais je ne sais pas si le SPO le traite ainsi.

Miaou joystick.gif

@Edit : En étudiant ton code, J'ai vu que tu traitais finalement tous les signaux et en sélectionnait 10 pour le SPO. Donc thumbsup.gif ma première remarque est donc réglée.
Il reste le problème que tu pourrais remplir ta table de 10, avec des menaces RR (priority 160xxx) et ignorant les menaces SAM (priority 140xxx)

Miaou smile.gif
KaTZe
CITATION(Maraudeur @ 19 May 2010, 14:01) *

Tant qu'à y être, si vous ne le saviez pas encore: LoVP pour FC 2

Skaiaaaaa wavetowel2.gif


Indeed Marau, le problème de LOVP, c'est :
1- Il est figé et n'évolue plus (impossible d'ajouter de nouveaux instruments)
2- Si on connect LOVP, on ne peut plus connecter SIOC (et donc les pit ne fonctionnent plus).

C'est la raison pour laquelle GillesDrone a finalement décidé (comme moi et Lynx) de refaire les gauges de LOVP en utilisant Gauge Composer.

Il les mettra à dispo, et je compte ensuite produire un KaTZ-Pit "vintage" pour le SU27 et le 29, reproduisant juste le panel tel que dans le jeu (sans ajouter les info. consommation etc etc) ... pour les puristes smile.gif

Miaou
gillesdrone
CITATION(KaTZe @ 19 May 2010, 13:55) *

CITATION(Maraudeur @ 19 May 2010, 14:01) *

Tant qu'à y être, si vous ne le saviez pas encore: LoVP pour FC 2

Skaiaaaaa wavetowel2.gif


Indeed Marau, le problème de LOVP, c'est :
1- Il est figé et n'évolue plus (impossible d'ajouter de nouveaux instruments)
2- Si on connect LOVP, on ne peut plus connecter SIOC (et donc les pit ne fonctionnent plus).

C'est la raison pour laquelle GillesDrone a finalement décidé (comme moi et Lynx) de refaire les gauges de LOVP en utilisant Gauge Composer.

Il les mettra à dispo, et je compte ensuite produire un KaTZ-Pit "vintage" pour le SU27 et le 29, reproduisant juste le panel tel que dans le jeu (sans ajouter les info. consommation etc etc) ... pour les puristes smile.gif

Miaou



oops j'ai mis un post sans avoir vu celui de MArau , mais bon le sien Flood un peu non ?? jesors.gif

blague à part , j'ai eu la meme réflexion que KaTZe au sujet de sa compatibilité avec le Sioc

j'ai bien avancé le tableau de bord russe avec GC . Patience je ferai un pack.
edrom
CITATION(KaTZe @ 19 May 2010, 14:36) *

Edrom, je viens de tester une mission avec 48 avions, et LO120 exporte ... 48 emitters (je n'ai donc pas atteins la limite).
Le problème étant que dans ce cas le 48eme était le plus puissant sad.gif

Donc, si l'on veut avoir un SPO correct, il faut donc, dans le code, checker la "priority" de tous les émitter pour les classer et déterminer les (xx?) plus puissant, les exporter.

Autre problème la classification entre RR et SAM pour les Muds
Les menaces RR (160xxx) étant traité avec une priorité supérieure au SAM (140xxx) dans le paramêtre priority, mais je ne sais pas si le SPO le traite ainsi.

Miaou joystick.gif

@Edit : En étudiant ton code, J'ai vu que tu traitais finalement tous les signaux et en sélectionnait 10 pour le SPO. Donc thumbsup.gif ma première remarque est donc réglée.
Il reste le problème que tu pourrais remplir ta table de 10, avec des menaces RR (priority 160xxx) et ignorant les menaces SAM (priority 140xxx)

Miaou smile.gif

"Il reste le problème que tu pourrais remplir ta table de 10, avec des menaces RR (priority 160xxx) et ignorant les menaces SAM (priority 140xxx)"

pourquoi?,lockon envoi le signal dans LoGetTWSInfo() et gere en interne la priority, non?
on a juste a trier par priority, le jeu augmente la priority pour indiquer passer tel signal en priorité puis envoi la valeur dans LoGetTWSInfo(). mes test m'indique cela... ceci dit je n'ai tester qu'avec des avion et missiles pour l'instant

d'ailleur l'avantage du lua/sioc c'est qu'on peut aller loin dans les décimales : par exemple quand on a deux meme avions, les priority ne sont diffrérent qu'a la 6eme décimale.
d'ou l'interet de gerer les valeurs priority sans les manipuler (* 1000... pas toujours suffisant)

exemple de log que genere mon code
19/05/10 17:10:30 - tableau des menaces
19/05/10 17:10:30 - présence radar : Tornado GR.4 : Pwr = 624.4313120842 Azim = -254.68668341637 Priority = 160.6244354248 SignalType = 0
19/05/10 17:10:30 - présence radar : Tornado GR.4 : Pwr = 624.75252151489 Azim = -253.74826788902 Priority = 160.62475585938 SignalType = 0
19/05/10 17:10:30 - présence radar : f-18c : Pwr = 304.9653172493 Azim = 2315.3312206268 Priority = 160.3049621582 SignalType = 0
19/05/10 17:10:30 - présence radar : f-18c : Pwr = 305.33456802368 Azim = 2315.6979084015 Priority = 160.30532836914 SignalType = 0

on en déduit dans l'ordre,
+ menacant : 160.62475585938 (tornado 1)
puis, en secondaire :
-160.6244354248 (tornado 2)
-160.30532836914 (F18 1)
-160.3049621582 (F18 2)

et c'est vrai que c'est plus facile de gerer les decimale en lua qu'en SIOC....
L'autre avantage du lua sur SIOC, c'est l'utilisation de table (voir de table de table)
dans mon cas, je gere l'affichage de plusieurs signaux secondaire (led verte du SPO) en meme temps, avec une matrice 10 lignes et 10 colones pour gerer 10 signaux (et c'est facile de passer a bien plus...)

avoir le meme resultat en SIOC va etre assez ardu .....

par contre quelqu'un a trouver comment interpréter le SignalType ?
KaTZe
Non, en fait je suis tout à fait en ligne avec toi sur le fait qu'il nous faut trier les priority dans Lua avant d'exporter les valeurs des plus menacantes vers SIOC.

C'est juste que perso je préfère réserver des plages d'offset pour les 10 menaces les plus dangereuses
- 601-605 menace n°1
- 606-610 menace n°2
- 611-615 menace n°3
etc etc

Pour une menace exporter la puissance, et l'azimuth
601 = puissance de la menace 1
602 = azimut de la menace 1
etc etc ...

Après si c'est pour Gauge composer, chaque diode rouge va tester la valeur 602, et ne s'allume que si la valeur d'azimut correspon à la diode.
Si c'est pour un pit, il suffit d'avoir un offset par diode rouge et de mettre les tests de condition sur la 602 pour savoir quelle diode allumer.

Donc jusqu'ici pas beaucoup de différence avec ta méthode

1> Mais mon 1er soucis (ou plutôt question) est que :

Les priorité RR, sont du type
160,xxx en scan ; 260xxx en lock ; 360,xxx en départ missile.
Donc la prioritisation se fait correctement

Mais les SAM sont du type
140,xxx en scan ; 240,xxx en lock ; 340,xxx en départ missile.

Donc potentiellement si on a un environnement avec >10 avions, les 10 premières priorités seront les avions 160,415 > 160,345 > 160,126 .......... > 160,054 > 140,800 !!!

Il faut que je test si le SPO repère toujours les émissions SAM quand il est saturé en aérien.
Sinon on sera éventuellement amené à creer plusieurs tables pour les RR, les SAM etc etc ....

2> As tu trouvé le secteur haut bas de l'emitter pour renseigner le centre du SPO ?

3> En ce qui concerne ta question sur le Signal Type
Pour le SPO "Scan" et "TWS" sont identiques
"Lock" correspond ... au lock
"Missile Radio Guided" correspond au dépar missile.

En fait cette info est redondante avec la priority puisque les scan et tws sont du type 160,xxx
les Lock type 260,xxx et les FOX1 360,xxx , les FOX3 1300,xxx
Idem la puissance correspond au 5 première décimale de priority

Je vais tester ce que donne un environnement lourd aérien + SAM voir si la diode SAM est allumée

Miaou joystick.gif


KaTZe
Bon je viens de faire le test vite fait : Mission avec 48 avions et un Buk


Conclusions

1> Bien que le priority des 48 menace RR soient supérieures au SAM (160,xxx > 140,xxx) la diode SAM est bien allumée (en vert)
Cliquez pour voir le fichier-joint

2> Par contre la menace principale reste aérienne même si on pénètre dans la goodwill du SAM blink.gif sad.gif
C'est logique puisque 140,99999999 sera toujours < à 160.000000000001

3> Le SPO ne classe la SAM en menace principale que lorsqu'il tire le missile devient un émetteur de valeur 340,xxx et donc supérieures aux menace RR

Cliquez pour voir le fichier-joint

Donc deux conséquence pour nous :
> Il faut classer en fonction des "priority"
> Il faut tester les type pour allumer les petites diodes en bas (même si le top 10 est aérien)

> Ben je ne savais pas que le SPO était aveuglé par les signaux RR, qui masquent le danger SAM ... jusqu'à ce qu'il soit trop tard. blushing.gif
Comme quoi çà sert d'essayer de comprendre comment fonctionne ces ptites bêtes wink.gif

Miaou joystick.gif
edrom
CITATION(KaTZe @ 19 May 2010, 19:09) *

Bon je viens de faire le test vite fait : Mission avec 48 avions et un Buk


Conclusions

1> Bien que le priority des 48 menace RR soient supérieures au SAM (160,xxx > 140,xxx) la diode SAM est bien allumée (en vert)
Cliquez pour voir le fichier-joint

2> Par contre la menace principale reste aérienne même si on pénètre dans la goodwill du SAM blink.gif sad.gif
C'est logique puisque 140,99999999 sera toujours < à 160.000000000001

3> Le SPO ne classe la SAM en menace principale que lorsqu'il tire le missile devient un émetteur de valeur 340,xxx et donc supérieures aux menace RR

Cliquez pour voir le fichier-joint

Donc deux conséquence pour nous :
> Il faut classer en fonction des "priority"
> Il faut tester les type pour allumer les petites diodes en bas (même si le top 10 est aérien)

> Ben je ne savais pas que le SPO était aveuglé par les signaux RR, qui masquent le danger SAM ... jusqu'à ce qu'il soit trop tard. blushing.gif
Comme quoi çà sert d'essayer de comprendre comment fonctionne ces ptites bêtes wink.gif

Miaou joystick.gif

Ok katze, c'est plus compliqué que ca n'en a l'air. merci pour l'info.
KaTZe
Je viens de faire un test final, avec saturation RR (48 avions) et un BUK
Voici la map de mission :
Cliquez pour voir le fichier-joint

Voici ce que donne le SPO :
Cliquez pour voir le fichier-joint

On voit donc bien la menace principale RR (à midi) et le BUK en menace secondaire en bas dans les type d'émission, mais aussi sur le cadran dans nos 7h00

Donc effectivement attention si tu tries par "priority" et ne retiens que le top 10, ta menace "Buk" sera en 49eme position, et donc ne sera pas exporté vers le SPO.

Hors on voit ici que dans le jeu, même l'azimut de la 49eme menace est indiqué (en secondaire)

-------------------------------------------------------------------------------------------------

Il me semble que l'on a 2 options :

Option 1
1a> Trier les priority pour extraire uniquement la menace principale (azimut + puissance) Diode Rouge
1b> Créer un tableau 10*2 correspondant au 10 diodes vertes (secteurs de menace)
Et pour chaque emitter tester dans quel secteur il se trouve et allumer le secteur.
Si emitter, alors secteur = On (= diode allumé)

Option 2
2a> Remplir un tableau menace RR
2b> Remplir un tableau menace Sol-R
Allumer les diodes avec le top (x) de ce tableau

-------------------------------------------------------------------------------------
En fait je penserais pour la solution 1 qui me parait très simple et correspond à la réalité (du jeu).
a) Une boucle sur tous les "emmiter" comme dans ton programme (comparaison avec priority max) pour repérer le n°1
b ) Envoi de l'azimut et puissance du n°1
c) Une boucle sur tous les "emitter" pour mettre à jour le tableau des diodes vertes



Voila wink.gif par contre je vais faire un post pour les pilotes, because si l'on vole vers cette 49eme menace, elle ne passe en n°1 que lorsque le départ missile est confirmé 140,xxx devient 340,xxx ce qui est potentiellement trop tard.

Il faut maintenant que je test les autre type d'émitteur pour voir quel ranking ils ont dans le jeu.

Miaou joystick.gif
C'est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquez ici.