stt-datacore / website

https://datacore.app/
MIT License
24 stars 24 forks source link

Continuum Missions #484

Open ylluminate opened 9 months ago

ylluminate commented 9 months ago

Any chance we can get an appraisal of where we may be going in the way of Continuum Mission relevant info? I find myself often wanting to see QP levels outside of the game so as to strategize on what Quipment to equip in order to get things lined up for competition, etc.

Is there any near-term function that might add this to crew views in order to help maximize QP earning?

nmoschkin commented 9 months ago

Continuum missions and quipments are being heavily programmed-for in the beta.

Please use https://beta.datacore.app/

Under Roster -> Items -> Quipment Helper, and also Tools -> Continuum Helper

Be aware, continuum functionality and quipment support are both extremely heavy-duty and non-trivial subsections, ergo, they are in the beta and won't be released to production until v2.0 is ready to roll.

I encourage everyone to hit the beta. We have no load or bandwidth limit. It's a cloudflare page.

Also note, beta's backend uses the production databases, all data exchange with the backend on beta will reflect in production, and vice-versa.

ylluminate commented 9 months ago

This is great news, thanks!!!

ylluminate commented 9 months ago

@nmoschkin this is nice - just spent some time in there and really excited with your efforts. One thing I have not found, though, is a way to try to use crew that has maximum QP potential. For example, I'd like to opt first on using crew that is not maxed in their QP (ie, 4 slots already open), and thus try to push up other crew that has fewer QP needed for opening a slot and then other crew that would simply be of value to work on opening slots first. I'm not entirely sure how this would be calculated, but I could see high voyage potential and event bonuses being perhaps considerable. Also simply doing shuttles easier might be of value. Any thoughts?

nmoschkin commented 9 months ago

@ylluminate I'm building a lot of new components with this endeavor, with a long eye on many of them being reusable, down the road for other features.

For the first part, sorting by QP potential, etc, that's totally already going in (I never said it was done, yet! LOL!) I just pushed a bug fix, in fact, there will be several new builds a day, check back frequently, and make a habit of emptying your cache if you want to use this particular tool, as it changes frequently).

As for using shuttles and voyages? Well, voyages already deals with quipped crew, broadly. It will show you a quipment icon on a crew seated in the big view, and also it will let you exclude all currently quipped crew, automatically.

The shuttle helper picks up quipment-charged crew by virtue of the fact that quipped crew's primary game stats are changed to reflect the higher values, automatically, so changing that code wasn't necessary.

But, recommending quipment to go on to crew to populate voyages or shuttles would be brand new modules unique to each of those specific tools, so those would be considered separate features, and thus, separate roadmap bullet points. But obviously tooling of that sort will have to eventually go in to those units.

Thanks for the feedback! It definitely helps to gauge how people use our stuff, and where we could go next! We can continue this discussion here, or on discord, but don't hesitate to reply. I might not get to you right away, but I check often enough.

ylluminate commented 9 months ago

Where are you at in context of DataCore in Discord? I have tried the Continuum section a bit more and I'm finding it hard to really nail down actionable chains given the wide range of recommendations. It seems like we should be able to streamline this better.

I think we also need a "perma ignore" for Voyage calculations so as to always make certain Continuum priority crew off limits for Voyages... Hmmm.

nmoschkin commented 9 months ago

@ylluminate I am tweaking the underlying mathematical engine very often. Nearly every new commit contains a change to the algo. So, I am tweaking it, and involving others in the discussions on Discord of how the math might go, and how the end-results might be filtered, etc.

The algorithm sits in a webpack worker. Now, the biggest problem with webpack workers is that some browsers don't refresh them unless you "disable the cache" in developer mode, or completely empty your browser cache. Firefox is notorious for this.