-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set affecting skill from context menu #101
Comments
We have bigger problem here:
This is pretty advanced functionality, so i am unsure if it can be implemented in current eos. I have most of functionality to support it in new (fast affector/affectee tree traversal & fit ghosting). |
Granted, this kind of feature might not be able to accommodate cases like those without significant reworking (in which case, it's probably not worth it with the current codebase). However, IIRC, EFT also does not take those cases into account. Not saying Pyfa should be like EFT, however users that come from EFT to Pyfa will be able to experience at least the same functionality, so I believe even having the limited functionality of currently affecting skills will be a benefit. Fake edit: I just checked, and it does seem that EFT includes skills which are not trained yet. Hmm... I'll have to look at the character classes and see how these things are applied. I haven't looked at it yet, but when a skill is set to lvl0 or even "Not Learned", are they removed from the skill list of the character entirely? Would it be as simple as including those in the skill list of the character? That way the show up in the affector list. And then to reduce problems and help debug, we can possible remove any lvl0 skills from the items stats > Affected by window so that we show what is actually affecting it, rather than skills that are lvl0 and could affect it. |
I've started work on this feature: blitzmann@45fca2a It goes a bit deeper than I thought, but is a relatively easy thing. Each module in a fit goes through and finds any other item/skill/etc that is affecting it and adds it to a map. However, before it adds it to the map, it checks to see if it even changed the value at all. If not, then it doesn't get added. This is how we only show currently affecting skills / items in the "Affected By" tab - if we have a skill that is not trained, then it's not affecting the item and isn't added. I changed this by moving that conditional to a parameter in This makes it possible to have a list of skills for an item that can affect it and display them, but also allow us through the use of the As far as I'm aware this doesn't have any penalties in regards to performance/bugs, and I've confirmed that I am showing the same stats between this change and Stable, so I consider the backend support for this feature is more or less completed. I now just need to make the context menu. This is also a change that I will submit pull request for as it deals with a few EOS changes. EDIT: I lied about backend being completed. There still seems be issues with pulling all the skills affecting it. |
I made some progress as to why some skills aren't showing up in lvl0 characters vs lvl5. I should clarify: lvl0 character is actually a character with all skills set to "Not Learned", not level 0. Any skill that has a level (including 0) shows up properly in the list as expected. The problem seems to stem from the way skills are saved in the database for each character. It seems that a new character starts with a blank slate, and it seems that skills are added "as needed" ie when you change a skill's level. This feature iterates through the skills that are pulled from the database - if the character doesn't have a skill (was not previously set), the logic doesn't know about it, and thus it doesn't show up. Likewise, the "All 0" character that I was using only has something like 279 skills in the database (hence why some of them are showing up, and some of them aren't). As a comparison, "All 5" has 399 skills. It seems that new characters and the default "All 0" character save skills as needed (the functionality of which I haven't figured out yet) So the fix is simple - make sure the characters have all skills attached to them. I'll make a pull request for this feature tomorrow if testing passes. |
Yes, EVE handles these effects in a more straight-forward manner. I think we can't do much about it atm. In best case - write skill name as a module-level attribute (like context and state, for example), and process it. Or just wait for new eos arrival at soem point. |
With my work on affected by tab, decided to look at this again. Immediately realized that we could do something that doesn't overhaul the whole system. The issue is basically that, during calculation, the ship hull itself is registered as the affector, and then in the effect file the skill is used to modify the bonus. Continuing with the flow, the registered affector (ship) is then read from the fit object and inserted into the afffectors list. The nice thing here is the way it's set up. After we register the affector, we can override it at any time before it's added to the affector list. We simply do I developed a new parameter for effect code,
We have this:
The skill modifies the modifier with
I'll be making a new prerelease to see if anyone in the community can find something I've broken with this before merging it into the main branch. |
Finally get to close this. 01db1ef |
Affecting skills are already collected per module, figure out a way to tap into this and access via module / ship context menu.
The text was updated successfully, but these errors were encountered: