:rocket: Weapon Component Resource Costs
bmgolley opened this issue · comments
The costs to build weapon components, like the Ambassador parts, are missing. There are resource costs to build the Necramech components as well as Necraloid's arch-guns, but all other weapon components have no separate entry.
There's an itemCount property on components. not sure what you're missing.
https://api.warframestat.us/weapons/search/ambassador?only=name,components
[
{
"components": [
{
"uniqueName": "/Lotus/Types/Recipes/Weapons/WeaponParts/CrpArSniperBarrel",
"name": "Barrel",
"description": "A weapon-crafting component.",
"itemCount": 1,
"imageName": "barrel.png",
"tradable": false,
"drops": [
{
"chance": 0.05,
"location": "Aurax Atloc Raknoid",
"rarity": "Common",
"type": "Ambassador Barrel Blueprint"
}
]
},
{
"uniqueName": "/Lotus/Types/Recipes/Weapons/CrpArSniperBlueprint",
"name": "Blueprint",
"description": "Bring negotiations to an instant conclusion with this Corpus assault rifle. Switch effortlessly between charged explosive sniper shots and rapid-fire electrical assault mode.",
"itemCount": 1,
"imageName": "blueprint.png",
"tradable": false,
"drops": [
{
"chance": 0.0833,
"location": "Neptune/Enkidu Ice Drifts (Skirmish), Rotation C",
"rarity": "Rare",
"type": "Ambassador Blueprint"
},
{
"chance": 0.0833,
"location": "Pluto/Fenton's Field (Skirmish), Rotation C",
"rarity": "Rare",
"type": "Ambassador Blueprint"
},
{
"chance": 0.0833,
"location": "Venus/Luckless Expanse (Skirmish), Rotation C",
"rarity": "Rare",
"type": "Ambassador Blueprint"
},
{
"chance": 0.1667,
"location": "Veil/Lu-Yan (Skirmish), Rotation C",
"rarity": "Uncommon",
"type": "Ambassador Blueprint"
}
]
},
{
"uniqueName": "/Lotus/Types/Recipes/Weapons/WeaponParts/CrpArSniperReceiver",
"name": "Receiver",
"description": "A weapon-crafting component.",
"itemCount": 1,
"imageName": "receiver.png",
"tradable": false,
"drops": [
{
"chance": 0.05,
"location": "Aurax Atloc Raknoid",
"rarity": "Common",
"type": "Ambassador Receiver Blueprint"
}
]
},
{
"uniqueName": "/Lotus/Types/Recipes/Weapons/WeaponParts/CrpArSniperStock",
"name": "Stock",
"description": "A weapon-crafting component.",
"itemCount": 1,
"imageName": "stock.png",
"tradable": false,
"drops": [
{
"chance": 0.05,
"location": "Aurax Atloc Raknoid",
"rarity": "Common",
"type": "Ambassador Stock Blueprint"
}
]
}
],
"name": "Ambassador"
}
]The barrel, stock, and receiver are all only blueprints. They have their own resource costs to craft. For example, the Ambassador receiver takes 200 Carbides, 5 Gallos Rods, 1 Morphics, 600 Cryotic, and 15,000 credits. I couldn't find that info anywhere in the data files.
We have an existing closed issue about nested components
We have an existing closed issue about nested components
Could you link the issue?
The barrel, stock, and receiver are all only blueprints. They have their own resource costs to craft. For example, the Ambassador receiver takes 200 Carbides, 5 Gallos Rods, 1 Morphics, 600 Cryotic, and 15,000 credits. I couldn't find that info anywhere in the data files.
In the case of the ambassador, and possibly a good amount of other weapons, doesn't have their components in one level, so it's missing data which would come from recipes, then we have 2 solutions duplication or reference:
- Reference, the weapon component would include only vital information like uniqueName, name, category and type, then we would add another category for recipes possibly called blueprints.
- Duplication would in specific cases, like ambassador, include it's component recipe data.
That would be a hassle but in the long term i think it would be worth it, because in these situations you would have to scrap the wiki or search in the warframe api, both options, that in my opinion, are not optimal.
Could you link the issue?
I stand corrected, I was thinking of a code comment, not an issue.
- Duplication would in specific cases, like ambassador, include it's component recipe data.
The stated reason for not doing so at present is that it would cause a significant amount of duplication, possibly overflowing the allowed amount of raw json data we can store. At a minimum, it would be prohibitive to duplicate all of them across the individual categories and All.json
| Build | Size |
|---|---|
| Current Unpacked | 103MB |
| w/ components | 159MB |
| All.json stripped w/ components | 100MB |
| All.json stripped | 72MB |
Notes:
- Sizes generated by running
npm pack --dry-run, and turning on the commented lines ifw/ components - Stripping All.json is a viable but breaking change, as it would include requirement of manual data entry, i.e. keeping a list of Categories that are actually available, which is not done at present.
I'm open to alternatives, but I'm not sure how else we'd be able to make this work. I can definitely test some ways to build a comprehensive list of data JSON files at runtime, but I don't like the idea of the extra startup overhead of reading the current folder on init.
Time loading from npm
| Type | Avg Time | | | Type | Avg Time |
|---|---|---|---|---|
| No-All 1 | 405 | | | All 1 | 445 |
| No-Alll 2 | 404 | | | All 2 | 411 |
| No-Alll 3 | 429 | | | All 3 | 411 |
| No-Alll 4 | 420 | | | All 4 | 406 |
| No-Alll 5 | 408 | | | All 5 | 412 |
| No-Alll 6 | 419 | | | All 6 | 420 |
| No-Alll 7 | 416 | | | All 7 | 418 |
| No-Alll 8 | 414 | | | All 8 | 406 |
| No-Alll 9 | 407 | | | All 9 | 409 |
| No-Alll 10 | 402 | | | All 10 | 407 |
| No-All avg | 413 | | | All avg | 414 |
Sooooo difference is basically negligible?
Well, hmmm, i need more numbers, I was just doing the load into npm time, not full construct. lemme do some more crunching
Construction Time
| Type | Avg Time | | | Type | Avg Time |
|---|---|---|---|---|
| No-All 1 | 97 | | | All 1 | 99 |
| No-Alll 2 | 96 | | | All 2 | 92 |
| No-Alll 3 | 93 | | | All 3 | 94 |
| No-Alll 4 | 96 | | All 4 | 93 | |
| No-Alll 5 | 104 | | | All 5 | 95 |
| No-Alll 6 | 97 | | | All 6 | 97 |
| No-Alll 7 | 102 | | | All 7 | 102 |
| No-Alll 8 | 95 | | | All 8 | 98 |
| No-Alll 9 | 103 | | | All 9 | 98 |
| No-Alll 10 | 97 | | | All 10 | 91 |
| No-All avg | 98 | | | All avg | 96 |
soooo, looks like not much difference there either
I guess I'll pr this part and we can look at the rest after we make sure it doesn't break all the things to do this
If we also minify the json we can get around 20% of size reduction.
part of that would require rewriting the serialization, but i think we could make it work. i'll try that on the same pr
i can't remember what else you wanted out of it than resources on components... was it that you wanted second level digging for resources on prime stuffs?
Rethinking about this issue, i had some ideas, if you find it useful i could expand on them.
We could probably include a method to populate specific items using references and being smart about it, but it may get over engineered if we're not looking to reduce size of the data.
Instead of populating we could just add some nice methods to return items from references.
In the size front, we could use mongo bson to make a serialized version which reduces the disk usage by around 20%. The data would be handled in bson format and then de-serialized when it needs the data, bson is very fast so no worries in that front. I think it would be possible to handle data as needed reducing the ram usage, but that would get complicated very quickly.
Bson would only help to traverse the data more efficiently, not what we're looking for.
Or like you suggested we could just have second level deepness and be done with it.
bson underneath might be something to think about with that major break discussion we wanted to have, but i'd rather not do anything like that on the current version
sooo....
we could try adding references like the uniqueName of the component but sincerely i have 0 motivation to do that now
Yeah, this doesn't feel necessary