Closed Aldriana closed 13 years ago
Edit: the to_json methods aren't that useful, as we mostly want to get data in, not out. The important method is obviously from_json.
Not thought about it in detail yet, but we could simply add a to_json
method (can't think of a better name right now) that turns an object into a primitive python type, either a list or dictionary in most cases, possibly just a string for race.
A buffs object would just turn into a list of the buff names, same for glyphs. Stats a dictionary like {"agi": 123, "str": 456, ...}
.
A calculator object can then just be another dictionary containing all these with additionally maybe a type like assassination
, or even a fully qualified class name calcs.rogue.Aldriana.AldrianasRogueDamageCalculator
{"type": "calcs.rogue.Aldriana.AldrianasRogueDamageCalculator",
"stats": self.stats.to_json(), ... }
Each object gets a corresponding method (probably classmethod) to deserialize.
Finally, a function get_dps
takes one such calcs dictionary and returns a result dictionary
{"dps": 22123,
"ep": {"agi": 2.6, "str",: 1.05 ... } }
These dictionaries can then easily be read from or written to json with the built-in json library.
Recreating everything like this from scratch will make the mini-server ShadowCraft-UI will talk to pretty simple as it will be stateless. I don't think having a more complex solution where you only transmit the changes from the UI to the engine will be worth it.
Edit: just realized, does ShadowCraft UI already have a specific json format?
Edit2: somehow I missed the import/export tab the UI has ... the current format isn't that useful to us, it lists gear as item ids {"slot":"0","item_id":50713,"gem0":"41398","gem1":"40150","gem2":"0","enchant":3817}
I assume this was just a quick demo of the intended functionality. Since the UI already has access to all the items, IMO it should provide summed stats, and possibly enchant names.
So, couple of points.
1) The demo of shadowcraft-ui (see http://roguething.mmo-mumble.com/) does have an export feature. I can't comment on whether that's how they're going to call our stuff or not. I don't know if they know how they're going to call our stuff right now. It is something that needs to be thought about though, so I figured I'd make an issue for us to start thinking about it.
2) Whether or not they're going to call our stuff with that specific json format, it seems like a useful exercise to figure out how to decode that blob and load it into our objects. Maybe we need some new constructors to handle it smoothly. Maybe we need more information from them to do a calculation. Basically, this is partly a "try to hook things up somewhat manually and see what's missing" exercise. Plus, I'm willing to bet that sooner or later someone will want to call us through json even if its not that exact format, so it probably makes sense to develop some expertise in that area.
3) That said, I don't think I'd build the decoding into the objects. Some people will be calling us through json... but some people won't, so shouldn't have to load all the logic for doing that. I'd probably create a new subdirectory that holds tools for converting input and output data between various formats, with to and from json being a reasonable place to start.
3) Is probably a better approach, especially if we want multiple formats.
An example in a format that's pretty straightforward and has everything the way constructors expect (except professions, which we don't handle anywhere yet)
{"race": "undead",
"level": 85,
"settings": { ... },
"stats": {
"str": 20, "agi": 4756, "str": 190 ...,
"mh" : { "damage": 939.5, "speed": 1.8, "type": "dagger", "enchant": "landslide" },
"oh" : { "damage": 730.5, "speed": 1.4, "type": "dagger", "enchant": "landslide" },
"ranged": {"damage": 1381.5, "speed": 2.2, "type": "thrown"}
"procs": ["heroic_prestors_talisman_of_machination", "fluid_death"],
"gear_buffs": ["rogue_t11_2pc", "leather_specialization", "potion_of_the_tolvir"],
"professions": ["leatherworking", "alchemy"],
},
"glyphs": ["backstab", "slice_and_dice", "eviscerate"],
"buffs": ["short_term_haste_buff", "stat_multiplier_buff", ... ],
"talents": ["0230030000000000000", "0020000000000000000", "0332031321310012321"],
}
Proof of concept: https://github.com/julienp/ShadowCraft-Engine/blob/json/core/jsoninput.py
run it like: python -m core.jsoninput
The module jsoninput has a single function from_json
that takes a json string and returns a calculator object. The example in __main__
has all the settings from assassination.py, but provided as a json string and produces the same result.
Currently only works for assassination rogues, but it's a working example of producing results from json input.
A quick experiment, this is really just a sanity check to see if it's possible and not something very useful right now.
I put the calculator on google appengine: http://shadowcraft-test.appspot.com/ It has no configurable input and only shows the dps as a result, but as you can see in http://shadowcraft-test.appspot.com/static/app.js the request is made from javascript by sending the json data to the server, so it wouldn't be too hard build a more functional UI in HTML and JavaScript on top of this. (I'm awful at that though)
Code is at https://github.com/julienp/ShadowCraft-Engine/tree/appengine
It's getting really close to cata release, so I spent some getting my simple web UI into a usable state. I think it's reasonably useful now, but there's probably still some bugs in there ... I think it will be quite useful as something to point people to until shadowcraft-ui is ready. I realize it isn't great that there's 2 web UIs, but I'm completely unfamiliar with the software stack used for Antiarc's UI. That and I had quite some fun playing with Javascript + jQuery :)
Url for the webapp is the same, code moved to https://github.com/julienp/ShadowCraft-Online It's not a fork of ShadowCraft-Engine, the included shadowcraft package is the packaging version (updated with latest fixes).
If by any chance anyone was playing with the save functionality before today, the storage format changed quite a bit, if the save button doesn't show up anymore type "javascript:localStorage.clear();" into your address bar and press enter and reload the page.
Its worth noting that having multiple UIs with the same backend is exactly the point of ShadowCraft - its so that if I write a good backend, lots of frontends can use it, and if someone writes a good frontend, lots of backends can use it. That said, it is clear (if you don't mind me saying so) that your UI isn't really intended to be a long term solution for the class - but even so I think it can't possibly be bad to have different authors experimenting with different approaches and ideas from both the UI and engine perspectives.
Agreed, the UI isn't very nice, worse than a spreadsheet since you lack instant updates to DPS as you change things around, can't add or modify items, etc. On top of that it's really ugly ... It's not meant to be anything more than a really simple frontend that works now. ShadowCraft-UI is certainly the way forward and this will be obsolete the moment S-UI is hooked up to S-Engine.
Right. Well, I'll leave it up to you when and if you want to tell people on EJ about it - just post something in the ShadowCraft thread if you want people to start hammering on it.
Well, we're clearly hooked up to ShadowCraft-Engine at this point, so I'm going to assume we've done what needs to be done on this. Closing.
In particular: figure out how shadowcraft-ui is exporting data (I think its cjson at this point), and write something that will parse it out and build the objects we're expecting.