chromium

Confirmed, weather panel.

Pensa che sta cosa la dissi diversi mesi fa, come mio personale parere... un canone annuale, anche relativamente basso, per tenere aggiornato DCS World e per l'aggiornamento della sua struttura ed i bugfix. Cosa che fanno cmq... ma inclusa nei costi di vendita, rendendo il tutto fottutamente complicato.

Well, I'm not going to restart DAWS as a project itself but it's free to be updated by anyone. Given that... I'm slowly working on a side things that might work in a similar way in the long term. In the meantime, if you exactly point to the current bugs with tracks, logs & attached miz file as an example I will try to debug as much as possibile the current release (no promise on the date, anyway)

Negativo. E' dichiarato EA nello shop ED (ed è quello che conta, salvo errori di aggiornamento della pagina) https://www.digitalcombatsimulator.com/en/shop/modules/viggen/

+1. E di parecchio, aggiungendo l'NS430 è anche relativamente modernizzato. Ovvio, devi essere più interessato alla logistica o agli scenari low-intensity: non che non possa tirare (Razzi) su obiettivi corazzati... ma è più adeguato in uno scenario COIN.

infatti ho detto imperfetto, non sbagliato.

Esatto. Che poi è esattamente quello che, limitatamente ai moduli che mi interessano, capita a me. EDIT: visto che sono in vena di rompere il razzo oggi... credo siano tre le principali distinzioni da fare: - Stato di sviluppo del modulo (EA/Release) - Versione del simulatore in uso (OB/"Stable") - (con minore peso) Sviluppatore del modulo (ED/3rdParty) Credo sia corretto aspettarsi di non avere sòle rilevanti (ovvero solo minor bugs noti normali come in ogni software consumer) esclusivamente nell'abbinamento Release+"Stable"+ED. Riguardo al resto... in genere la vedo personalmente così: - un modulo EA può avere bugs/feature mancanti sia in OB che in "Stable", e potrebbe diventare parzialmente inutilizzabile tra un update e l'altro vista la frequenza di aggiornamento. Lo accetto come tale e come tale ragiono quando lo acquisto; - La versione del sim "Stable" è lì per evitare di tradurre bug importanti relativi agli scenari ed i moduli Release venuti fuori con la OB della settimana prima. Quindi se volo stable almeno i "blocking bugs" su una serie di moduli assodati da tempo dovrei evitarli; - Le 3rd Party tendenzialmente devono arrangiarsi: la ED verifica il proprio. Quindi può capitare che un modulo Release sia buggato anche nella "Stable" per un periodo di tempo superiore a quanto capita ai moduli ED. Ed è per questo che mi "incristo" quando vedo il Ka-50, che è proprio un modulo ED, Rilasciato da anni e con problematiche evidenti anche in stable (illuminazione cpk su tante) venute fuori da quando è stato rilasciato il deferred shading... che è poi diventato da opzionale a obbligatorio, disattendendo proprio la salvaguardia di un prodotto assodato nel tempo. Ovvio che non ci sono abbastanza risorse per fare tutto e quindi qualcosa va sacrificato, e se si vota tra "sistemare il Ka-50" o "dare priorità all' F-18" l'utenza risponderebbe probabilmente con un 1/10000 come voti... eppure... trovo ci sia qualcosa di imperfetto in questo.

Questo è pienamente condivisibile. Infatti non ho messo in grassetto a caso le cose nel post sopra. Il punto sta proprio nell'andare a rompere le balle... sulle cose in cui non possono risponderti a ragion veduta (e con il dovuto tasso di ironia) "suka". ;)

Definizione della ED https://forums.eagle.ru/showthread.php?t=222881 Si tratta solo di decidere se fare finta di non aver capito o capire. Poi, non essere d'accordo è più che leggittimo (a me pure fa cacare), ma diciamo che almeno personalmente mi sento decisamente più forte in posizioni antagoniste in cui chi ho davanti non può dirmi semplicemente "rileggi, grazie". E' per questo che puntualizzo quando noto un'errata interpretazione delle cose. L'argomento è partito parlando di "pagare la early access", e già questo è un errore di interpretazione secondo la definizione che ha dato la ED, più volte, a suo tempo. E' un paraculamento della ED? ovvio. Ma far finta di non saperlo non penso che aiuti nell'avanzare quelle che sono obiezioni più che valide. La ED non ha un QA adeguato? mi pare evidente. Ma questo non toglie che loro hanno messo le mani avanti, e noi abbiamo accettato queste condizioni quando abbiamo installato il modulo in EA. A titolo personale penso che sia giustissimo rompere le scatole ma facendolo nel modo in cui loro chiedono, ovvero riempiendoli di bug reports propriamente compilati. E' una rottura di scatole? ovvio pure questo... ma se ci si vuole lamentare, è corretto farlo così... questo è un mio parere, ovviamente.

Su questo mea culpa. Sul resto... è openbeta, se non erro. Non la penso così. Tutto qui ;)

Appunto, sensazioni "di pancia" nostre, per quanto direi maggiormente affidabili delle dichiarazioni ufficiali.

Mi trovi d'accordo, al più con un filo di ottimismo in più. Però la domanda è se dobbiamo attenerci alle info ufficiali o alle nostre sensazioni di pancia (o quelle di altri): se ci atteniamo alle prime ZioSam dice il giusto, ovvero si presume che non saranno aggiunte altre features successivamente al rilascio dell' F-14B ma sarà solamente aggiunto l'F-14A. Se stiamo alla nostra esperienza sino ad oggi, vuoi anche per la natura mutevole di DCS World in sè, sicuro ci saranno bug da risolvere o aspetti da ottimizzare... e difficilmente sarà "completo" al giorno 1. Credo in effetti, ma è un parere strettamente personale, che il concetto di EA sia maggiormente legato a due aspetti: - Features mancanti ma annunciate, dichiarate o programmate - Blocking bugs (tali per cui il modulo è parzialmente non utilizzabile secondo parere del produttore o della ED) Il resto, i "minor bugs" (sempre secondo parere ED o del produttore) ci sono e ci saranno sempre, vuoi anche perchè ogni tanto la ED cambia il supporto (DCS World) e questo può portare a problemi seri.

Forse mi sbaglio, ma non state facendo un po' di confusione? questo modulo JF-17 (cui si riferiva CapableJet nel post quotato) non è fatto dalla ED, quindi non credo che interferisca nè l'F-18 nè il futuro F-16. Il Mi-24P è un bel dubbio invece... in teoria è un progetto sviluppato da BSK (che però ora si presenta come ED), quindi non saprei come interpretarlo.

Non paghi l'Early Access. Preacquisti il modulo, con uno sconto. E come "bonus" hai l'early access. Le loro definizioni sono chiare, siamo noi che le interpretiamo male (o come ci viene comodo). Per questo tutti continuano a consigliare di non prendere in early access nulla se non si è convinti di poter accettare anche dei blocking bug seri fino alla release. Su Mirage e altro ricordiamo che non è la ED responsabile, incazzarsi con Razbam casomai. Sul fatto di aver tutto disponibile in ogni mappa, compresi velivoli occidentali in stati dell'est e viceversa (i flyable), è sempre stato fatto detto che i responsabili di creare uno scenario realistico NON è la ED, ma i singoli mission designer. Nessuno può entrare in un server e prendere un aereo qualunque: ci sono solo quelli disponibili ed inseriti dal mission designer. Si sta solo dando una possibilità in più, senza togliere nulla a nessuno. Non ti piace l'instant action del Mig-15 in normandia? Non volarla. Io francamente sono più irritato con la ED per i bug presenti nei moduli già released della ED (A-10C, Ka-50), che vengono messi sistematicamente in coda. Es. l'update del cockpit Ka-50 spostato nel 2019, senza un avviso ufficiale ma solo mediante un messaggio messo da chizh nel forum russo e successivamente riportato da silver dragon in un thread della sezione inglese.

Can you suggest me how? I looked into that files, but wpn are defined this way: { NatoName = "(AA-6)", CLSID = "{4EDBA993-2E34-444C-95FB-549300BF7CAF}", Picture = "R40R.png", displayName = _("R-40R"), Weight = 475, attribute = {4, 4, 7, 7}, Elements = { [1] = { DrawArgs = { [1] = {1, 1}, [2] = {2, 1}, }, -- end of DrawArgs Position = {0, 0, 0}, ShapeName = "R-40R", }, }, -- end of Elements }, while, instead, into the warehouse file are this way (don't bother the different visualization type, I highlight in red the id I need): ["warehouses"][8]["weapons"][[b][color="Red"]373[/color][/b]] = table: 000000055B879D28 { ["warehouses"][8]["weapons"][373]["wsType"] = table: 000000055B879E08 { ["warehouses"][8]["weapons"][373]["wsType"][1] = 4, ["warehouses"][8]["weapons"][373]["wsType"][2] = 5, ["warehouses"][8]["weapons"][373]["wsType"][4] = 70, ["warehouses"][8]["weapons"][373]["wsType"][3] = 9, }, ["warehouses"][8]["weapons"][373]["initialAmount"] = 0, }, I can't find the file that couple a particoular weapon to that code. And it's needed to ensure warehouse update from a mission to another (that I already got working) this is my personal "manual" built simple table (for Mi-8 ), which has the display name (from wpn desc table) and warehouse id number: local validWeaponsCode = { ["S-8OFP2"] = 392, ["S-8KOM"] = 407, ["S-8OM"] = 393, ["S-8TsM"] = 401, ["S-5"] = 405, ["S-5M"] = 402, ["S-13"] = 408, ["KORD 12.7 Gun"] = 87, ["7.62mm"] = 88, ["23mm HE"] = 89, ["30mm HE"] = 81, ["12.7mm"] = 80, ["FAB-100"] = 369, ["FAB-250"] = 370, ["FAB-500"] = 372, ["SAB-100"] = 322, }

:) don't worry, I believe you're welcome here, and phant is one of the most reliable user for official info available

Not this year. https://forums.eagle.ru/showpost.php?p=3675277&postcount=1380

You know that this is an italian forum, written mostly in italian, do you? :D Inviato dal mio SM-G920F utilizzando Tapatalk

Well at the moment I'm using a "manual entry table" so it's a very preliminary thing. If someone has any other suggestion, it's welcome :)

Hi, I'm trying to track weapons usage in some way and relate it to the resource manager. I noticed that if I dump the warehouse table I get something like this for any kind of weapons: ["warehouses"][8]["weapons"][393] = table: 00000005A053AD30 { ["warehouses"][8]["weapons"][393]["wsType"] = table: 00000005A053AE10 { ["warehouses"][8]["weapons"][393]["wsType"][1] = 4, ["warehouses"][8]["weapons"][393]["wsType"][2] = 7, ["warehouses"][8]["weapons"][393]["wsType"][4] = 158, ["warehouses"][8]["weapons"][393]["wsType"][3] = 33, }, ["warehouses"][8]["weapons"][393]["initialAmount"] = 120, }, this is, for example, for a S-8 rockets (OFP2 or KOM, don't remember). Does anyone knows where I can find corrispondence between the "393" id and the fact that relates to S-8 rockets? thanks

found a solution, ugly but it's ok.... serialize a table into string in the mission environment, print it as a text message and then in the hooks environment set an "onTriggerMessage" code that parse that text message back into a table. Ugly mostly because it's a workaround.

F-14 is made by Heatblur, not ED. Heatblur has released only Viggen, which is one of the most complete and good module we have. ED has nothing to do with F-14 development or viggen bugs, that is because is pointless talking about F-14 while complaining about World or other ED's modules bugs. It'l like complaining about Willams being slower than Ferrari with Mercedes or Red Bull engineers. If you don't want to be wrong since the start, you need to be aware about what is right to ask to ED and what with others third parties.

I usually hate those kidn of posts... and F-14 doens't belong to ED... but... +1, this time.

No, salvo accordi diversi tra le parti. Se cerchi nel forum e nella pagina FB trovi qualcosa, anche credo di abbastanza recente.

Violerebbe un accordo che hanno con il DoD per l'utilizzo del simulatore A-10C.