JIT Widget Loading about pypipboyapp HOT 12 CLOSED

I aware of the problem, but there is no easy solution to it. Since currently we don't have that many widgets there is no performance problem (at least I did not observe one). Therefore I decided to just let it be for the time being, and find a solution at a later time.

Using a Just-In-Time loading scheme would require us to re-implement functionality from Qt (e.g. the widget menu, the persistent storage of widget status infos). In my opinion the effort for this required is not worth it.

Another, more practical, solution would be to rewrite widgets so that they don't update themselves when they are not visible. I already did this with the individual tabs of the inventory browser and it is working great (It is not exactly true that I didn't experience performance problems with constantly updating hidden widgets. In my first version of the inventory browser, all tabs would update themselves when the player inventory changed. With about 1000-2000 items in the inventory [I just went to the workbench of my player base and added all items there to my inventory], I experienced performance problems. Which I was able to mitigate by using above mentioned method.).

from pypipboyapp.

Ah okay, it's as I thought, possible but a lot of time and effort would be required to implement.

While I haven't been experiencing any performance issues either, I can't help the need to make things run more efficiently. Your solution is probably something all widgets should be doing regardless of how many updates it handles. I think I have some work ahead of me.

Speaking of work ahead; I was thinking of trying to consolidate the two different player info widgets. Maybe make it configurable so you can pick and choose what is shown, and if possible, in what order. Thoughts? Otherwise, any further work you might need assistance with?

Aside from that, I am thinking of working on the Help widget trying to fill in the documentation gap. Is this on anyone's plate right now?

from pypipboyapp.

Yes, at some point every widget should do it. I think the best course is to adapt them one-by-one over time, we don't need to rush it.

Merging the player info widgets is a good idea, but you should talk with akamal before you 'destroy' his widget. I actually don't know why he did its own in the first place. Making them configurable is a good idea, but also a lot of work when you want to do it right. I also though about this when I made mine and decided to postbone it to a latter time, and spend my time implementing other widgets. But now that we have enough widgets we can re-visit this idea. The easiest would be a configuration dialog that just allows you to set some widget elements invisible. Allowing to configure the order is a harder task, but should still be feasible.

Completing documentation is always a good idea (and one thing I am not good at all, somehow I regularly fail at describing things so that other can understand it). If you want to do something, this would be the most helpful.

from pypipboyapp.

Alright, thanks, hopefully Akamal will read this thread or I will find other means for contact (because apparently I'm blind and can't find any other means of communication on Github).

After I tweak my existing widgets to save processing, I'll build a documentation framework and see what I can do to fill things in appropriately. Although I think I had a question about that. Did you mean to have that as a built in widget? Or should I, while I'm at it, make it a standalone?

from pypipboyapp.

I've seen it now!

I built the smallplayerinfo widget simply because it's what I wanted for my play through: The original playerinfo widget alongside the date\time widget took up too much space (see screenshot below of the layout I'm using); showed some things I didn't care about; and didn't show some things I did. In hindsight, I probably could have modified Matz's original widget, or made it configurable, but I didn't want to come across as trying to take over. I also really didn't have enough knowledge of python\qt to take a configurable approach. So, I just built a new one, and contributed it under the assumption that more choice is better!
By all means feel free to hack it about, I'm not precious about it, and a configurable widget definitely seems like a usability improvement. Worst case, if I really don't like it I can always carry on using my own! : )

With regard to performance, I'd had similar thoughts to you Killeand, but Matz's idea of widgets detecting when they're visible, and suspending processing\ui update if not makes a lot of sense. I'll look at updating my widgets when I can (with the exception of the hotkeys widget, it makes sense for that to work even if it's hidden, and if no keys are defined it's not really doing anything anyway).

Better documentation sounds like an excellent idea, I get the impression that most people haven't really grasped the extent of the functionality. I'm happy to help with writing some of the documention, what sort of framework have you got in mind Killeand?

Screenshot showing size motivation behind smallplayerinfo widget:

from pypipboyapp.

Okay, so allowing for the smallest possible size (both dimensions) signature if at all possible would be best. Although in the end, height would be hugely based on how many features you activate, unless I wrap the layout with a scroll area (but that's probably not desired by anyone).

So possible features should include:

• Worldspace
• Game Time/Date
• Actual Time/Date
• Active Radio Information
• Health
• Action Points
• Level/Experience
• Encumbrance
• Currency
• Rads
• Active Effects and Drugs

Should there be anything else you think?

I'll jump on this once I get my widgets in order and set up the help docs.

Speaking of, Akamal, the "framework" I mentioned. Nothing too special. Mostly just trying to set up a stylesheet (and seeing if I can load it in the QTextBrowser using the import statement or the link hypertext), creating a template and general structure guidelines for future help docs, and a possible folder structure should we get a lot of pages.

Did you have any thoughts on this subject?

from pypipboyapp.

More choice is always better, that's why I didn't object merging your player info widget.

The list sounds good, but do we have a reliable method of detecting the amount of Rads? If not I would remove Rads from the list. You could add armor DR instead, DR is the only thing not covered by any widget yet.

from pypipboyapp.

In regards to rads, I'd say yes for detecting radiation as it is being applied, provided that Magic Effect form names are not spelled differently in non-english versions of the game. For existing or applied radiation damage, not so much.

I believe my Player Stats (soon to be renamed Combat Stats) widget shows current weapon and armor values. I haven't seen anything like in New Vegas where the stats are split up between DT and DR, it just appears to be the total resist values for a certain damage type. Unless there is some kind of separation I'm missing? But, nothing says I can't take those numbers and add them as well. The stats widget does require a bit of space because of the images.

from pypipboyapp.

According to my experience the rad magic effect can only be used to detect the presence of radiation, but the numbers are not always reflecting what the geigercounter ingame says. I think I will dig into the scripts and FO4Edit to find out how this magic effect really works.

True, the player stats widget shows the DR. They changed the DR/DT system again. Now we only have DR, which works completely different from the other games.

from pypipboyapp.

From what I am gathering, the Rads shown is the total number of possible rads from the source. The actual number taken I think uses the Damage Reduction calculation for Radiation Resistance, and then a distance from source is applied. This theory applied to walking in water, and approaching a single barrel. When approaching multiple barrels, it seemed to ignore resistance. We can basically get everything except for the distance coefficient, which goes with what you are saying that the Rad number is semi-bogus.

Didn't someone request that Rads be added on Nexus?

Addendum: If the numbers are useless to show, would it be worthwhile for me to duplicate my code in the Auto Doc that shows the Irradiated, and Radiation messages for when rads have been applied but not handled, and when Rads are currently being applied?

from pypipboyapp.

I tested some stuff in regards to radiation. The effect values are the radiation when within the radiation hazard zone, and the radiation resistance is already deducted from this value. The only thing the effect value does not take into account is the distance reduction when you are at the edge of of the hazard zone. The radiation that comes from swimming has no distance reduction, the water radiation effect value seems to be the only correct one.

I wouldn't say that the values are completely useless, they are the maximum rad damage you can receive when you enter the radiation harzard zone. We could even sell it as feature by saying that the value is a predicition of what radiation damage you might face when you continue your path into the radiation hazard zone. I just wouldn't label the value "Rads" but something like "Max Rads" or "Rads Prediction" or something similar to emphasise that the value does not necessarily represent the amount of radiation you are facing right now.

Yes, someone on Nexus wanted a Rads display (and I think more than one).

from pypipboyapp.

Roger. I will ensure that the rads option has a label stating that the numbers are not going to be exact.

from pypipboyapp.