pyfa-org / pyfa-ng Goto Github PK

c&p from Slack

btw, totally forgot this was a thing

https://github.com/DarkFenX/pyfa-experimental

It probably isn't of much use anymore. This was when we were going to go forward with wxPython and whatnot but I believe Kadesh started integrating eos with other things

He had the concept of EOS data manager and pyfa data manager. He also started to support 'commands' which were actions that could be reversed (so, undo/redo functionality)

I don't know much about it, and don't know if the concepts translate well to a client/server architecture anymore, but it might be beneficial to poke around at it and see if there's anything we can use going forward

Looking at it very quickly, there seems to be a lot that we can do with it potentially. It pretty much ties in EOS data with pyfa-specific data. As we know, EOS only works with numbers. So there isn't any real text. EOS doesn't know what the module name is, or the attribute names. However, Kadesh worked it in to seamlessly integrate a pyfa data model (what we're used to - fit is a Fit object, has a Ship property that points to an EVE Item wrapper and include name, attributes, blah blah blah) with the EOS data model (numbers and calculations and stats)

This is something we're going to have to delve into and see if there's anything in here tat can be salvaged / utilized. It might be extremely helpful to get us off the ground as it already lays out a format for how we integrate EOS stats and calculations with (user-facing) pyfa data models.

This should really be under the Eos repo, but someone didn't enable issues there. :)
(We can move this if/when it is.)

Some features that Eos seems to be missing (some may just need to be confirmed).

• T3D Modes (This is just a module in game, can we do something similar?)
• T3C Subsystems
• Citadels (can we just treat this as ships?)
• Citadel modules (currently none that I know of that would modify fitting stats)
• Projection (Ships and fits)

Potential Bugs/Issues with Eos:

• Need to confirm, but seems Eos only returns an except for each error if the error is the same type. Ideally it returns an exception with all issues with the fit.

Just opening a thread on the JSON/Database design for feedback, comments, and ideas.

Just opening a thread on the JSON/Database design for feedback, comments, and ideas.

This is just in regards to the back end, so setting the UI aside for the moment.

Eos doesn't use a database, it grabs all it's data from JSON files and creates a cache file out of them.

Specifically, these are the ones it cares about:

     def get_evetypes(self):
        return self.__fetch_table('evetypes')

    def get_evegroups(self):
        return self.__fetch_table('evegroups')

    def get_dgmattribs(self):
        return self.__fetch_table('dgmattribs')

    def get_dgmtypeattribs(self):
        return self.__fetch_table('dgmtypeattribs')

    def get_dgmeffects(self):
        return self.__fetch_table('dgmeffects')

    def get_dgmtypeeffects(self):
        return self.__fetch_table('dgmtypeeffects')

    def get_dgmexpressions(self):
        return self.__fetch_table('dgmexpressions')

Since we are already going to be including JSON files for Eos (I'm assuming we're not going to spend the time to rewrite that), what else can we leverage those JSON files for?

Do we just want to just use JSONs for the back end, and skip using SQL for static data entirely?
(This would certainly make updating the data much easier than trying to update an existing SQL database.)

Right now for the back end we have the following modules:

Eos
pyCrest
sqlAlchemy
Flask

Since Flask can read the JSONs directly (and load them into memory), I'm not sure what duplicating that data into SQL would buy us.

Rough thoughts on the design. Follow fairly similar to Pyfa's current design.

Test issue, please ignore.