These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
Previous page12
 

Common Loadout Format (draft specification): feedback wanted!

Author
Indalecia
#21 - 2012-06-15 21:47:13 UTC
Quick update

A git repository has been set up for all CLF-related tools and documents here: https://github.com/Artefact2/common-loadout-format

At the moment, it only contains the source of the draft specification and helper JSON files for database-less parsers (with the scripts to generate them, of course). I plan to add a PHP validator (and converters) soon. If you want to contribute a reference implementation in your favorite language, please do so!

I've also made a couple changes to the draft: the "client-version" key has been added, it's optional though. It is of course highly recommended to use it, but its absence dosen't make the loadout completely unusable, so it's not required. The "charge" key of modules has also been removed; the same functionality can be achieved by specifying a "charges" key with a one-element array (it's just 3 more characters). Finally, the draft is set to expire in a month from today (July 15th) — I think this is enough to give everyone a chance to spot and report potential issues.

https://o.smium.org/ — v0.13.5 — A browser-based fitting tool and loadout sharing platform

Desmont McCallock
#22 - 2012-06-16 05:56:49 UTC  |  Edited by: Desmont McCallock
Regarding the use of 'chargepresets', what's the purpose of using them this way? After all the name can be determined through the typeid with a lookup in SDE.
And in case it's just for loadout readability then why don't you add a 'modulepresets' for the same purpose?

Edit: Obviously I can't get the meaning of the 'chargepresets' element. Reading the specs again, names of modules and charges can be added optionally by specifying a 'typename' key-value pair. Still trying to wrap my head around it.
Desmont McCallock
#23 - 2012-06-16 06:08:01 UTC
Regarding the Dup & Conf detection, in my case it's easier to code a condition to discard any following dup presets rather all previous ones.
Indalecia
#24 - 2012-06-16 20:49:25 UTC
I've pushed an experimental validator to the repository. Feel free to test it, look at the source and share your insights.

@Desmont McCallock: the repo also contains an example, non-trivial loadout. Maybe looking at it will help you understand how charge presets work, because I couldn't make any sense of your two last posts ;)

https://o.smium.org/ — v0.13.5 — A browser-based fitting tool and loadout sharing platform

Desmont McCallock
#25 - 2012-06-16 20:56:42 UTC  |  Edited by: Desmont McCallock
My last two posts are unrelated between them.

Edit:
I looked at your example and still the feeling I get about the usage of 'chargepresets' is that it is used to show alternative charges to the ones already used in 'charges'.

Edit 2: OK, I think I may have solved the puzzle in my head as 'chargepresets' seem to be used as a generic description of the charge usage, but still I'm failing to understand its usefulness.

About my second post I'm talking about section 3.1 of the spec.
Indalecia
#26 - 2012-06-17 07:25:04 UTC  |  Edited by: Indalecia
Desmont McCallock wrote:
Edit 2: OK, I think I may have solved the puzzle in my head as 'chargepresets' seem to be used as a generic description of the charge usage, but still I'm failing to understand its usefulness.
The chargepresets key is there to store the name and description of the charge preset. Typically an entity could display something like this to allow the user to select a preset: screenie


Desmont McCallock wrote:
About my second post I'm talking about section 3.1 of the spec.
I don't see how it's easier to "code a condition to discard any following duplicate" rather than just storing the presets in the specified order (and possibly overwriting any previous ones). Also, in my opinion, common sense expects the last declaration to always have the precedence.

https://o.smium.org/ — v0.13.5 — A browser-based fitting tool and loadout sharing platform

Desmont McCallock
#27 - 2012-06-17 08:09:19 UTC  |  Edited by: Desmont McCallock
Indalecia wrote:
The chargepresets key is there to store the name and description of the charge preset. Typically an entity could display something like this to allow the user to select a preset: screenie
OK, I see now. As I'm not into fitting tools I couldn't see the use.
Indalecia wrote:
I don't see how it's easier to "code a condition to discard any following duplicate" rather than just storing the presets in the specified order (and possibly overwriting any previous ones). Also, in my opinion, common sense expects the last declaration to always have the precedence.
It just requires less condition checks but whatever.
Indalecia
#28 - 2012-07-15 11:00:50 UTC
As planned, the draft expired today and is now the official specification for CLF version 1.

This means that all non-trivial changes will be for the next version of the format.

To all the interested developers, you can now start supporting the format knowing it can no longer change!

Specification is here: http://artefact2.com/clf/spec-common-loadout-format-01 (and also in the git repository).

Enjoy your Sunday!

https://o.smium.org/ — v0.13.5 — A browser-based fitting tool and loadout sharing platform

StinkRay
The Dirty Rotten Scoundrels
HYDRA RELOADED
#29 - 2012-07-16 21:51:37 UTC  |  Edited by: StinkRay
The idea about having several options for charges is good, however the chargepreset _name_ stuff feels redundant. At least make it optional.

A fitting tool could easily parse that and output something like

"5x scorch M"
"4x radio M, 1x multifrequency M"

to the end user / ui / representation, so I see no need to explicitly name them.

Furthermore, why have the cpid at all? Array index could serve the same purpose.
Maa Ku
Garoun Investment Bank
Gallente Federation
#30 - 2012-09-03 20:05:23 UTC  |  Edited by: Maa Ku
Is this still going forward? (sorry about the necro)

I had a question. In your introduction you mention "The common loadout format is designed to be easy to parse by programs and easy to read by humans.".

Whilst the former of this statement is true and I think the CLF is an excellent concept I do not believe that the later is necessarily true.

My question is; is it your intent by this statement that you expect humans to paste the JSON data into forums discussions and emails? The reason I ask is because the eve forums and email can eat up the tab formatting, rendering the code difficult to read.

Whilst the EFT format suffered the lack of typeid problem amongst others, it can be pasted into the forums and read by people easily.

{
"ship": {"typeid": 24698, "typename": "Drake" },
"presets": [
{
"presetname": "Meta 4 launchers",
"modules": [
{ "typeid": 8105, "charges": [{ "typeid": 209 }] },
{ "typeid": 8105, "charges": [{ "typeid": 209 }] },
{ "typeid": 8105, "charges": [{ "typeid": 209 }] },
{ "typeid": 8105, "charges": [{ "typeid": 209 }] },
{ "typeid": 8105, "charges": [{ "typeid": 209 }] },
{ "typeid": 8105, "charges": [{ "typeid": 209 }] },
{ "typeid": 8105, "charges": [{ "typeid": 209 }] }
],
"chargepresets": [
{ "id": 0, "name": "Scourge missiles" }
]
},
{
"presetname": "Tech II launchers",
"modules": [
{
"typeid": 2410,
"charges": [
{ "typeid": 209 },
{ "typeid": 2629, "cpid": 1 },
{ "typeid": 24513, "cpid": 2 }
]
},
{
"typeid": 2410,
"charges": [
{ "typeid": 209 },
{ "typeid": 2629, "cpid": 1 },
{ "typeid": 24513, "cpid": 2 }
]
},
{
"typeid": 2410,
"charges": [
{ "typeid": 209 },
{ "typeid": 2629, "cpid": 1 },
{ "typeid": 24513, "cpid": 2 }
]
},
{
"typeid": 2410,
"charges": [
{ "typeid": 209 },
{ "typeid": 2629, "cpid": 1 },
{ "typeid": 24513, "cpid": 2 }
]
},
{
"typeid": 2410,
"charges": [
{ "typeid": 209 },
{ "typeid": 2629, "cpid": 1 },
{ "typeid": 24513, "cpid": 2 }
]
},
{
"typeid": 2410,
"charges": [
{ "typeid": 209 },
{ "typeid": 2629, "cpid": 1 },
{ "typeid": 24513, "cpid": 2 }
]
},
{
"typeid": 2410,
"charges": [
{ "typeid": 209 },
{ "typeid": 2629, "cpid": 1 },
{ "typeid": 24513, "cpid": 2 }
]
}
],
"chargepresets": [
{ "id": 0, "name": "Scourge missiles" },
{ "id": 1, "name": "Scourge fury missiles" },
{ "id": 2, "name": "Scourge precision missiles" }
]
}
],
...
}
Indalecia
#31 - 2012-09-03 21:56:15 UTC
Maa Ku wrote:
Is this still going forward?

Yes, this thread has gone a bit quiet, but the format is still very much alive (so far, only used in Osmium, but I keep the CLF git repository updated after every patch).

Maa Ku wrote:
My question is; is it your intent by this statement that you expect humans to paste the JSON data into forums discussions and emails? The reason I ask is because the eve forums and email can eat up the tab formatting, rendering the code difficult to read.

Whilst the EFT format suffered the lack of typeid problem amongst others, it can be pasted into the forums and read by people easily.

That's a valid concern. CLF loadouts aren't as "user-friendly" as EFT-format loadouts, but they're still reasonably human-readable (if you display them correctly).

For use on forums, chats etc., a solution is to base64-encode the CLF text, and include another description of the fit (example here) or you might as well just put it on Osmium and share the link (you can't do shorter than that), and then recipients of the link can export the loadout in any format they want.

https://o.smium.org/ — v0.13.5 — A browser-based fitting tool and loadout sharing platform

Previous page12