bradallred / gemrb Goto Github PK

I guess for now we would have to set/unset this from DragItem and ReleaseDraggedItem.

Got a suspect now though. Previously the minimal test didn't do any gui stuff, now it does pop open a window for a tick or two. That could easily cause the crash, since travis workers have no screens. My terminals have some sort of framebuffer going on, so I can't verify it there. It does exit with 0.

loading the window is not enough, the portrait part needs to be reloaded too (different window), otherwise it'll look wrong even if the misalignment is fixed. No idea when this got broken, the history is pretty harmless. EDIT: oh, but didn't check CharGenCommon changes.

expected:
https://i.ytimg.com/vi/jQCoYNoZaaA/hqdefault.jpg

705379b (and some previous commits) removed the "repeat click" code from the event manager. The idea is to use repeat action capabilities of Control and set the repeat delay individually on the appropriate buttons instead of relying on a global state with limited options.

GUI scripting refs will leak if assigning aliases. Either need to let views track multiple refs or better yet somehow decouple them from the scripting engine… cant use C++11+ so might not be feasible.

if you ctrl-j to jump around, it will also open the journal. Similarly ctrl-m&maps for debug dumps and so on.

somehow these were broken and don't display text anymore. They still exist and are not obscured just the text is missing.

problem being my quick look though master branch I can't see how this text is actually being set...

Some stages are closed via python, but at the end a few remain. This was broken in ab3d936, where also DelAllWindows got removed from Interface::StartGameControl and so the documented behaviour of GemRB.EnterGame was lost.

Any particular reason, as it's quite handy?

maybe you have it in some stash, so just noting here.

fc62088 removed SetKeyPressEvent. IIRC it was initially added to switch between pcs in non-walk environments and in this branch this is handled by core.

We have SetHotKey, but it only works on buttons. One window in cg had a cheat in the original that was triggered via a hotkey. I could create a hidden button just to get it working, but that's ugly. Ideas?

b5030f8 and more specifically the portrait dragging redesign (f31bad0) removed a bunch of lastActor setters. However, there's still plenty of code for that around.
lastActorID
lastActor
SetLastActor
GetLastActor
GemRB_GameControlSetLastActor

It just can't work anymore (ID is never set). Besides cruft, it breaks several users and is partly responsible for #6 .

I looked why the inventory is so sad. Rightclicking doesn't work for me to get item descriptions. Through some random luck, I noticed middle-click does. So I suspect we have the wrong key for IE_GUI_BUTTON_ON_RIGHT_PRESS in the EventMap. Can you confirm with your mouse?

guicg4 with str, dex and co. If you click on their names, the labels vanish and may later reappear. Could be the same issue as #59 , but this is a bit more contained if not faster to reach.

a8b784c removed too much code in InventoryCommon.

Long-term, ItemHash should probably go or everyone should use it.

also #46

Randomly clicking around the first window (soa/tob choice) often makes the version label (that we create) vanish. Reloading the window helps. It's also visible in the same case of Start2.py. Also in some other labels, which disappear when clicked on, but that might be a different issue.

One such example, easier to reproduce, is the inventory encumbrance labels, which we also create. I thought perhaps clicking on the bag button below them forces it infront, however just making the button locked or fakepressed doesn't fix this. Making it disabled helps, even though it's the wrong state, but it doesn't fix it completely and sometimes the labels clip the button bam ...

(we disable bugs on the other repo)
running bg2 and going into guirec customisation, choosing the (ai) scripts button reliably asserts:
gemrb/core/GUI/TextSystem/TextContainer.cpp:476: void GemRB::ContentContainer::LayoutContentsFrom(std::__cxx11::list<GemRB::Content*>::const_iterator): Assertion !layoutFrame.Dimensions().IsEmpty()' failed. `

the stack is always destroyed for me, so I didn't investigate further. Seems like the latest code changes caused several new problems, so I'll check that first (game loaded with wrong area, button overlay insets misaligned and only work for the first portrait, copyresref change broke travis). Perhaps related, the sound listing in cg also shows empty.

tab is used for two things:

• immediately trigger a tooltip
• show the hp/maxhp overhead text for party/friendlies, iff pressed over the gamecontrol

the first we do in the wm via a hotkey, the other in gc manually. So the hp display never shows up, because the wm eats the event, It can only be achieved because the code is not strict — by using ctrl-tab or other mod keys.

It sounds awkward to check for the gc in WindowManager::HotKey, so I'm looking for ideas.

previously used VA_ARGS, but that is apparently nonstandard prior to C++11... however, it is part of C99... (dont know if that helps)

so the question is what target platforms does this not exist for? Is there a better alternative then individually defining multiple macros?

split off:

I was researching why the map window is not working and found the problem. During the refactoring of CreateControl calls last year, inheriting of the reused control's size (frame/region) was removed. All the map creation is explicitly called with an empty region, so the control creation fails. The control's window is not available in the binding though, so that will have to change.

IIRC the map control has a bunch more wrong with it than that... I've been ignoring that. I think I have a stash from last year that got it halfway working again.

I was fixing something else, but then got dragged down this rabbit hole. And now gave up.

The mage window needs to use the same openwindow call for its selection-changed callback or it doesn't update properly when switching between mages and sorcerers. Different windows are involved, so it makes little sense to try to hack it from the update method.

However, it just doesn't work. OpenTopWindow closes itself, but even manually calling Close doesn't help. It's also easy to get the event to fire too often. Anything I tried mostly made it worse, usually somehow breaking selection on the portrait window.

Happens sometimes in the inventory too, but most reliably with the bag icon just before the quickslots in the actionbar. Just hover over them and they'll start blending to white and back to some brown.

Maybe related, maybe not, but in the inventory, slots get an animated white border when you hover over them. The speed is similar, the thing just doesn't cover the whole slot here.

I was unable to test BIK videos when implementing the new MoviePlayer class.

While I don't know for sure they are broken I want to open this issue to remind us to look at it before merging with master.

Since the PortraitWindow is the topmost window (created after the rest really) then it receives the key events. This is only a problem for the keys which the window (or its focused button) respond to such as the arrow keys.

Seems like it could be several issues in one, but just load a game with a bunch of chars and let them complain of boredom or something, to fill the message window. Pausing or other new content doesn't scroll the text area and the scrollbar itself doesn't work. Had to pause/unpause several times to get it to display the later stuff (seemed like old content needed to be pushed off the history buffer).

Currently tooltips background drawing is implemented like the originals. That is the positioning of the background is controlled by the XPos and YPos of the sprites. The result is that multiline tooltips having their text too low.

Also, the cursor buffer is only 128px wide which is too small to fit a fully extended tooltip (the main bg sprite alone is 128px wide). simply extending the buffer is not quite enough to fix it, however, because the XPos setting on the sprite is only 64px.

It would probably be easier to ignore XPos and YPos on those sprites and programmatically center things.

Similar to drag, nothing is firing them now.

Needs to be reimplemented as core no longer deals with that.

Currently tooltips are always rendered in the center of the cursor buffer so around the edges of the screen they become decoupled from the mouse even if they could fit without clipping off the screen.

kind of a minor issue; its better then them getting clipped as they would if they always centered on the cursor.

I took a peek into why the sound/script lists are empty. Don't have much time today, so I'll just document the short investigation:

• cg soundlist: consistently turns up empty, because the directoryiterator has a NULL Entry
• guirec script list: works in some saves, not in others, seemingly consistently. When it doesn't work, GemRB_TextArea_ListResources still did its job and a sane count was sent back to python. Weird
• haven't tried the others

click+esc and no obvious way to get them back. They need their default hotkey revoked.

Looking at selection brought me to #38, which made it obvious the portraits aren't interactive any more. The selection change handler successfully updates their borders, but that's it. No clicks work for selection, inventory opening or dragging.

The various GameControl cursors don't work. Likely anything that has special cursors is broken.

This ticket should be updated with the specific cursors so we can check them after reimplementing this.

broken by 7b04d6b

making this issue as a reminder to reimplement this before merging into master.

broken by 7b04d6b

making this issue as a reminder to reimplement this before merging into master.

This can probably wait until after merging with master.

Seems that we now have 2 methods for attaching timed events. SetTimedEvent requires a Game to exist so it is unsuitable for timing anything outside of that. However, it might be that SetTimedEvent runs off "rounds" instead of "ticks" and i dont know if using ticks would be suitable for all instances. If rounds are directly tied to ticks then there is certainly no reason why we cant switch everything to a generic timer.

movies require the full screen, blacked.

This will take a while to retest, as it's not possible to trigger most cutscenes or stores now. Just testing regular resting: ok; with windows: top window doesn't stay on top, the messagewindow obscures it.

I see you're syncing with the branch on the main repo — I guess we can continue there directly and slowly kill of the remaining reports here? Less work for me this way, since I can commit stuff directly.

broken by f6cb538

Will need to address the TODO there to fix it. Maybe use an RGBA buffer instead too.

Broken in 2ddcd2f

I guess just call WindowManager::SetTooltipDelay for now. This needs to be saved in the INI too... maybe just don't worry about saving it for now and refactor the setting out of Interface and into their own manager (I actually have a prototype for this).

Sprite2D.cpp:74: void GemRB::Sprite2D::release(): Assertion `RefCount > 0' failed.

if you start a new tob game, it will abort right after looking up the small portait. At least that's the last thing in the log. Could be related to the fact that at that point, the cg window is not unloaded yet, while the game textarea is already visible.

I thought perhaps clicking on the bag button below them forces it infront, however just making the button locked or fakepressed doesn't fix this. Making it disabled helps, even though it's the wrong state, but it doesn't fix it completely and sometimes the labels clip the button bam ...

Could be some new code is not checking for all the button states (2x locked and 2x "fake"). I don't think there's any reason not to draw labels on the toppest top.

Likely also happens with other created labels. All that I can think of are currently untestable: encumbrance on the container window, in stores, hp overlay in iwds.

961ef20 was all broken, so recheck:

• pst hp button toggling
• dragging items to other pcs

the rest was already handled in 76cb6ff . 95% sure the same fixes are needed, but other bugs need to be tackled first for this to be testable.

just so it's not forgotten: 5a04992 is to blame.

Do you still have any uncommitted, unfinished work? What parts of our systems shouldn't be touched or complained about until then? ;)

Do you have a general plan of attack, dependency graphs etc.? Github

• has
  • these
• nice
• lists we could use
  Also milestones, but that's overkill imo.

Don't know if it's related to the last changes in that area, but the load/save window can scroll almost indefinitely (and there's a one-off error, most likely on the py side now).

like for getting actor names. Seems focusWin is null then so WindowManager::DrawTooltip does nothing. Maybe needs special casing.

didn't look at it from the overhead text angle yet, which is also not working.

reproduce by furiously clicking in any (start) window. It can take a few seconds this way, but it's quite reliable. Seems to happen around chu frame borders, so try at 800x600 for best results.

Assertion `me.buttonStates' failed.

235                     assert(me.buttonStates);
(gdb) p me
$3 = (const GemRB::MouseEvent &) @0x7fffffffd7b0: {<GemRB::ScreenEvent> = {<GemRB::EventBase> = {
      repeats = 0}, x = 536, y = 539, deltaX = 2, deltaY = 5}, buttonStates = 0, button = 0 '\000'}

Looks like a part of the drag code, but with no apparent users of buttonStates later on.

I have an unfinished stash from last year that seems to add support for nested modal windows... I'm presuming this must be needed somewhere, but I have no recollection of where.

the preview is crucial. It also makes no sense to store a full screenshot, it would just bloat the savegame.

... looks like WindowManager::GetScreenshot can now do part of it.