Hey there, So i want to start a new modding project to help out the community, and I have two options that I can take, I just want to see if anyone is interested in either. 1) A mod to ship messages from the game to 3rd party services, I deally to allow non-c# webservices to interact with the game The basic idea here is that it would be pretty easy to use a message queue to alienate the game events, so that way you could have a website that does everything that EAH does. I have no interest in building the website, but I do have some good ideas on how to build the architecture that supports the website. 2) Config.ecf as JSON right now it's really difficult to explore the options that are available for config.ecf because it is in a *very* custom format. I could write a parser that allows JSON<->ECF encoding, which would make the data in the config files easier to work with/explore.
It is not *that* bad of a custom format In case you do write something like this, you might want to refer to my JS implementation. Might save you a little time atleast. But I think this could potentially be a *great* thing down the line, when we (hopefully eventually) can use it to parse custom stuff aswell as the current behaviour of editing it. I doubt it's too usefull currently tho.. Afaik you can't dynamically reload its data (and honestly, I'm having a hard time thinking of an use-case, where you'd want to real-time update items anyway.. but .. ) Maybe an use-case for 'mods' would be reading the data, to behave differently, depending on the settings (for instance, if the weapon does x damage, do y) Might lead to some cool stuff.. But I think it'd have to be standardized to really be helpfull (perhabs consider, if you do write it, to include it into your mod API?) This could potentially be handy. It shouldn't be too hard to do as-is, but having a shortcut is always nice
Really the idea would be facilitating a GUI-style editor of these properties. Where is your JS implementations?
Mm, that is an option too. It is moreso a one-size fits-all tho. I think perhabs using it for conditionals could be cool aswell. In the hangar bay forum; https://empyriononline.com/threads/script-convert-ecf-files-to-json-v2.36887/ (only ecf => json, as I've no need for json=>ecf in my current projects )
Heh, evidently a bunch of us thought enough about the config file format to either write or think about writing parsers for it; I have a partial one implemented in python for my config file project on consistent item masses. @Exacute, I think I will go borrow your code and translate it into python .
Feel free. The only 'regret' with the current implementation, is that the additionaldata# entries (for when it encounters a dataset that isn't named inside one (for instance Spoiler: in Code: { Item Id: 2055, Name: Sniper PickupToToolbar: true StackSize: 1 Category: Weapons/Items Mass: 5, type: int, display: false, formatter: Kilogram Durability: 500, display: false DegradationProb: 0.625, type: float, display: false { AllowRemote: false ROF: 0.5, type: float, display: true, formatter: ROF Range: 400, display: false Automatic: false BulletSpread: 0.03, display: false Damage: 70, display: true AmmoCapacity: 6, display: true AmmoType: 12.7mmBullet, display: true ReloadDelay: 3.1, display: true Tracer: Weapons/Projectiles/TracerOrange1 TracerPerBullet: 1 DamageMultiplier_1: 6, data: head, display: DmgMultiplierHead DamageMultiplier_2: 0.001, data: wood DamageMultiplier_3: 0.01, data: stone DamageMultiplier_4: 0.01, data: rock DamageMultiplier_5: 0.01, data: dirt DamageMultiplier_6: 0.001, data: hullarmored DamageMultiplier_7: 0.001, data: hullcombat } { } UnlockCost: 7 UnlockLevel: 5 TechTreeParent: AssaultRifle TechTreeNames: Weapons } Spoiler: becomes Code: 2055: { item_id: 2055 name: Sniper pickuptotoolbar: true stacksize: 1 category: Weapons/Items mass: { mass: 5 type: int display: false formatter: Kilogram } durability: { durability: 500 display: false } degradationprob: { degradationprob: 0.625 type: float display: false } additionaldata_0: { allowremote: false rof: { rof: 0.5 type: float display: true formatter: ROF } range: { range: 400 display: false } automatic: false bulletspread: { bulletspread: 0.03 display: false } damage: { damage: 70 display: true } ammocapacity: { ammocapacity: 6 display: true } ammotype: { ammotype: 12.7mmBullet display: true } reloaddelay: { reloaddelay: 3.1 display: true } tracer: Weapons/Projectiles/TracerOrange1 tracerperbullet: 1 damagemultiplier_1: { damagemultiplier_1: 6 data: head display: DmgMultiplierHead } damagemultiplier_2: { damagemultiplier_2: 0.001 data: wood } damagemultiplier_3: { damagemultiplier_3: 0.01 data: stone } damagemultiplier_4: { damagemultiplier_4: 0.01 data: rock } damagemultiplier_5: { damagemultiplier_5: 0.01 data: dirt } damagemultiplier_6: { damagemultiplier_6: 0.001 data: hullarmored } damagemultiplier_7: { damagemultiplier_7: 0.001 data: hullcombat } } additionaldata_1: { } unlockcost: 7 unlocklevel: 5 techtreeparent: AssaultRifle techtreenames: Weapons } ) I would've ideally, when encountering duplicates, instead of _#, make them a subarray, with the shared name.. Consider changing it to this. I believe it will be easier to read-through, if done as such. (like, it would be additionaldata:{ 1:{ }, 2:{ } } rather than additionaldata_1:{}, additionaldata_2:{}, (...)) It might come down to taste in the end, but I'm likely going to be re-writing that eventually Note however, that this is a super edge-case.. And in this instance, the second one doens't even contain data There is however some instances, like the multitool, that have several additionaldata ones
Additionaldata is generated from 'blank' { } sets. (ie. where there's no prefix, like harvester:{}), inside an already-existing one Where it seems that in many cases, the content is *identical* to other occurances. So here I did not find any valid candidate for an unique key. Rather I opted to use the arbitrary 'additionaldata' one. Why it isn't in the format I proposed, was honestly because I didn't think of it initially
Ah, sorry, I was actually asking about the switch from CamelCase to all lowercase for all keywords; is that a JSON requirement?
Ah, no. But you cannot use spaces in naming, so rather than doing both, I opted for underscores. It could be either or both. I personally prefer this, but it is a style-decision in the end You can do either or both.
@geostar1024 If you want an ECF parser in python, I'd be happy to code it up for you. Like I said, I'm looking for a new project, and if you want to describe your need I can probably get through it in a couple of days. I have some immediate ideas on how to do it, and I'm trying to decide on what language I'll write it in
I just revisited this idea in my head, and I think it could actually be rather cool having a 'standardized' approach to API calls (like you can hand out keys to a service, which can then in turn interact with your game). Might open it up for more cool scripts and stuff, when it is considerably easier to approach. If you are looking for a project, of these two, I think this would be the neater
I agree it would be pretty great to have running, but only if server operators actually want to use it, which is why I'm reaching out, to find out if anyone even wants it.
