Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Axis & Allies 1942 Online is now available in Early Access! Buy it on Steam. The FAQ is available.
New Premium Module: Tyrants of the Moonsea! Read More
Attention, new and old users! Please read the new rules of conduct for the forums, and we hope you enjoy your stay!

Making it Work: Inventory

12829303133

Comments

  • ThacoBellThacoBell Member Posts: 9,571
    Looks good, thanks for putting that together.

    DanathionAdulJuliusBorisovRavenslight
  • DoubledimasDoubledimas Member, Mobile Tester Posts: 1,183
  • PeccaPecca Member Posts: 1,960
    edited September 2016
    Little late to the party, but I have some points to the ground slots. First (minor), using the scrollbar to shift 4 slots might complicate things for modders that would want to change the layout of the ground slots. So ideally the code should allow modders to change the number of slots shifted.
    Second, it should be specifically stated, that the different layout for tablets, the scrollbar vs arrow buttons, would be put in the same code and would use "e:IsTouchUI()" as a condition.
    The scrollbar isn't an independent element, it is always used for "area" elements in the UI, so that likely means that the ground slots would have to become such area for PC layout (that means the slots would not be independent elements), while for tablets, the arrow buttons are independent and are used to shift another groups of independent elements. This complicate things but I still think it's possible (maybe not exactly in a way we propose though).

    Edit: Thinking about it, using the scrollbar almost certainly wouldn't work this way (shifting one line at a time) because the 2.0 UI changed how scrollbars are used. Remember the old 1.3 load screen (four fixed slots) versus the new one (smooth dynamical scrolling) to understand the difference.

    JuliusBorisovAdul
  • lefreutlefreut Member Posts: 1,424
    Pecca said:

    Edit: Thinking about it, using the scrollbar almost certainly wouldn't work this way (shifting one line at a time) because the 2.0 UI changed how scrollbars are used. Remember the old 1.3 load screen (four fixed slots) versus the new one (smooth dynamical scrolling) to understand the difference.

    It may be possible with 'scrollbar func' to replicate the old scrollbar behavior. If I have time, I will try this.

    PeccaAdul
  • Mr2150Mr2150 Member Posts: 1,170
    You can scroll slots with a mousewheel (that function already exists in the UI) however it doesn't display a scrollbar - so it's only a partial solution.

    PeccaAdul
  • lefreutlefreut Member Posts: 1,424
    I did some experimentation. If you put a slot (the UI element used for the ground) inside a list (to be able to have a variable number of elements and a scrollbar), the slot is unusable. So this will require an engine update for this to work.

    Or we can fallback to the buttons and the mousewheel.

  • Mr2150Mr2150 Member Posts: 1,170
    edited September 2016
    Which is one of the reasons we probably moved over to buttons & mousewheel in v2.0+ The 'actionscroll' action works fine in those instances but all it is really doing is simulating pressing the buttons.

    However, I used the quickloot slots in a list to create a scrollable (with scrollbar) quickloot in DUI++ so it is possible to have functioning slots in a list with a scrollbar.

    @lefreut - if you are doing more research here's how I did that...

    (NB - It's worth noting there is a known issue with the 0th slot because LUA starts counting from 1 not 0).

    list
    	{
    		column 
    		{ 
    			width 310
    			button
    			{
    				area 5 0 52 52
    				bam STONSLOT
    				enabled "QLfilter(rowNumber) and QuicklootMode == UIStrings.UI_Advanced"
    				frame lua "loot.groundItems[rowNumber].item['frame']"
    				icon lua "loot.groundItems[rowNumber].item['icon']"
    				tint lua "loot.groundItems[rowNumber].item['tint']"
    				usages lua "loot.groundItems[rowNumber].item['usages']" --how many selected
    				count lua "loot.groundItems[rowNumber].item['count']" --How many to a stack
    				align center center
    			}
    
    			button
    			{
    				area 79 0 230 54
    				enabled "QLfilter(rowNumber) and QuicklootMode == UIStrings.UI_Advanced"
    				text lua "loot.groundItems[rowNumber].item['name']"
    				text style "normal"
    				text align left center
    			}
    		}
    		area 			4 10 318 -60
    		enabled 		"getSlotContainerId(0,'containerId') and QuicklootMode == UIStrings.UI_Advanced"
    		name 			"QLdisplayrows"
    		rowheight		dynamic
    		hidehighlight
    		table			"loot.groundItems"
    		var				"selectedLootItem"
    		scrollbar 		'GUISCRC'
    		scrollbar hide lua "getHeight()"
    		action
    		"
    			PickUpItem()
    			if #loot.groundItems == 0 then repositionQuickloot() end
    		"
    		actionAlt
    		"
    			QLSearchString = loot.groundItems[selectedLootItem].item['name']
    		"
    	}

  • lefreutlefreut Member Posts: 1,424
    Mr2150 said:

    Which is one of the reasons we probably moved over to buttons & mousewheel in v2.0+ The 'actionscroll' action works fine in those instances but all it is really doing is simulating pressing the buttons.

    In my opinion, it's a bad reason. They rewrite the UI code, they could have make it work like in the previous version.
    Mr2150 said:

    However, I used the quickloot slots in a list to create a scrollable (with scrollbar) quickloot in DUI++ so it is possible to have functioning slots in a list with a scrollbar.

    It works when you have one element per line. In the inventory, we have a grid. I think you can only know which line is clicked and not which element. Also, the inventory use 'slot' not 'label' or 'button', most of the interaction code is hidden.

    Ravenslight
  • Mr2150Mr2150 Member Posts: 1,170
    edited September 2016
    Yup - it can only cope with one element per line, I think... hence it's a list... It would be brilliant if the UI could cope with multiple elements per line - like an array rather than a list. That would benefit many UI screens.

    EDIT: But that's one of the reasons I'd very much be in favour of changing the ground slots to quickloot slots (and it would work as ground slots are a subset of quickloot slots)

    So_LoW
  • AdulAdul Member Posts: 1,912
    lefreut said:

    Mr2150 said:

    Which is one of the reasons we probably moved over to buttons & mousewheel in v2.0+ The 'actionscroll' action works fine in those instances but all it is really doing is simulating pressing the buttons.

    In my opinion, it's a bad reason. They rewrite the UI code, they could have make it work like in the previous version.
    I concur. They're the ones with the source code, so they should be able to restore that mechanic if they choose to go in that direction.

    Ravenslight
  • Mr2150Mr2150 Member Posts: 1,170
    edited September 2016
    I'm not actually fussed either way however it's an assumption to think that they could have made it work like the previous version - this is a completely new UI and there may be something in the UI/engine that we are unaware of that prevents it.

    For example, the crash to desktop bug on 'page 5' of the ground slots. With a scrollbar in action instead of pages and buttons, it might be that the bug presents itself more often or something - hence they might've made the decision to move to buttons from the scrollbar so that the issue is minimised. That's speculation on my part, but it could explain the decision.
    (The bug is easily reproduced... just drop 32 individual items into the ground slots of the inventory and you'll get a crash as soon as you scroll to the 5th page... )

    I guess, as feedback to this process, it would also be useful to know if certain things were off the table or not possible....

  • FlashburnFlashburn Member Posts: 1,725
    I like it... but I'm not too keen on the double spacing between each line. Although separating the Armor Class Modifiers section with a double space, away from the main AC info, would be okay with me. Pardon if that's already been brought up. I haven't really been paying attention to this, more like waiting for the final iteration to appear.

    Danathion
  • lefreutlefreut Member Posts: 1,424
    For information, here are the data that are accessible when you pick an item: currentHP, AC, maxHP, THAC0, equippedItem, dmgMax, dmgMin, tempItem.

    So we don't have the change in Attacks per round, THAC0 and damage are only for the main hand and AC is only one value, you don't have details about slashing, crushing, ...

    I will make the code with the available information but if we want all the things in the mockup, this will require an engine update :(

    Ravenslightcmk24Danathion
  • ThelsThels Member Posts: 1,328
    @lefreut: That looks awesome, good job!

    However, seeing the interface with an actual proper background, I have the feeling that the box containing "PAUSED" is a little too close to the side of the panel. I think it would feel easier on the eyes, if there was some space to the left in between the box and the edge of the interface screen.

  • lefreutlefreut Member Posts: 1,424
    @Thels, it's like that since 1.3. I don't know what's the general opinion about this, but yeah this can be moved a little to the right.

  • RavenslightRavenslight Member Posts: 1,609
    I’m fine with where it is. If moved over it shouldn’t be by much.

    DanathionAdul
  • RavenslightRavenslight Member Posts: 1,609
    So you mean that this won’t work on a BG installation, only a BGII one with the current patch?

  • lefreutlefreut Member Posts: 1,424
    The code (but not the UI.menu file) should work for all versions but you will need to change the images to match the style of the other UI (and you probably will have to adapt the position of some elements).

    Ravenslight
  • Mr2150Mr2150 Member Posts: 1,170
    edited September 2016
    Great job @lefreut

    It works well - I especially like how you extend/shrink the headers based on the appearance of the scrollbar.

    The collapse/expand is clean... ;)

    I did notice a bug here - but I suspect it's an engine/calculation issue on the comparison. I've just picked up a quarterstaff but something is odd with the damage calculation.




    EDIT - Not a bug, it's because it's mainhand damage only and the +0 is an average....

  • lefreutlefreut Member Posts: 1,424
    @Mr2150, thanks :)

    For the header, I had to use a hack to make it work because you can't draw where the scrollbar should be. The code could be simpler if this bug is fixed (and if we have a way to know if the scrollbar is needed or not).

    The damage is not identical, so the line is shown. But the average is the same (4-7 and 3-8), +0 is correct. Maybe in this case the text should be white, I can fix that.

  • Mr2150Mr2150 Member Posts: 1,170
    Yup - just made an edit as I realised the same. I guess this is what I meant when I said I would find average confusing :) In that instance, I would agree that it should be white because the average is 0, but agree that the line should still be shown because it's now a different range.

    I think there is code to work out if the scrollbar is needed - I used something elsewhere which has a similar function, let me check how I did it.

  • Mr2150Mr2150 Member Posts: 1,170
    edited September 2016
    @lefreut

    You can use 'scrollbar hide lua' in conjunction with 'scrollbar func' and 'scrollbar' ... so you will probably need some kind of check function that compares the content height to the box height to determine yes/no.

    Infinity_GetListHeight('table') might also be useful.

  • lefreutlefreut Member Posts: 1,424
    I choose to display the average because two lines for min and max damages require new strings. My code only use existing strings so there is no need for new translations.

    Mr2150
  • lefreutlefreut Member Posts: 1,424
    edited September 2016
    Mr2150 said:

    You can use 'scrollbar hide lua' in conjunction with 'scrollbar func' and 'scrollbar' ... so you will probably need some kind of check function that compares the content height to the box height to determine yes/no.

    I have a function that compute the height of the element so I know if I should draw the list with scrollbar or not.

    'scrollbar hide' does not work for what I need, even if the scrollbar is not here, you can't draw there :/

  • PeccaPecca Member Posts: 1,960
    Just as in the record screen discussion, I'll throw my mockups here if anyone wants to use them.

    AdulDanathionJuliusBorisov
Sign In or Register to comment.