a thread about a fish trying to understand

[pulsar bobcat]

.

[kind fable]

right

you have no way of knowing if the UI or inventory is going to be ready first

[pulsar bobcat]

a thread about a fish trying to understand

[kind fable]

your UI should call a function on the inventory to get a callback when the inventory is ready (all data is ready)

example:

{
    if (IsInventoryReady())
    {
        Delegate.Execute();
    }
    else
    {
        OnInventoryReady.Add(MoveTemp(Delegate));
    }
}```

[pulsar bobcat]

cat, i think kaos want us to be alone 😅

[left shore]

I tried to do that too few days ago and people told me that the ui shouldn't call the inventory and that my design was bad in that way...

Not sure if it's a good approach (just letting you know, I'll leave :D)

[kind fable]

now when your inventory is ready, you broadcast this, from the inventory and your UI can then read all the stuff from the inventory it needs

[pulsar bobcat]

thats exactly what i am trying to do

[kind fable]

it can then bind those delegates to by dynamically

basically you want your UI to only do its setup once the inventory is ready

[pulsar bobcat]

void UPGInventoryComponent::OnPostReplicatedAdd(const FPGFastSlot& FastSlot)
{
    UE_LOGFMT(LogTemp, Warning, "PostReplicatedAdd called on {0}, Index: {1}, Item: {2}",
            this->GetOwner()->GetName(),
            FastSlot.SlotIndex,
            IsValid(FastSlot.Item) ? FastSlot.Item->GetName() : "Null"
        );

    if (bCanSendToHUD)
    {
        OnInventorySlotAddedLocallyDelegate.Broadcast(FastSlot.SlotIndex, FastSlot.Item, FastSlot.VisibilityGT);
    }
    else
    {
        /// cache someway
        OnInventorySlotChangedLocallyDelegate_Cached.Add(OnInventorySlotAddedLocallyDelegate);
    }
}

[kind fable]

this is not what i am saying though

you are thinking completely wrong

this is NOT what i am saying

[granite pagoda]

No, people told you that the inventory shouldn't call the UI
The UI should be a layer on top and the underlaying gameplay systems shouldn't be aware of it

[left shore]

also that (both)

[kind fable]

stop thinking about the fast array and stuff for now#

your UI needs to know if your inventory is ready or not

[pulsar bobcat]

whats the diff between your code and mine ?
it checks if UI is "ready", and if so call the delegate, if not, "store" it for later

[kind fable]

this is what your registering

NOTHIN|G to do with items or the fast array

when your inventory broadcasts out its ready, your UI GRABS the data and does its initial setup

this is very basic common way of doing it

[pulsar bobcat]

yes

[kind fable]

what you posted up there is WRONG

[pulsar bobcat]

i think im just not using the good words, because what you are saying is what i want to achieve

[kind fable]

this is not what i am saying to do.

not even close

@granite pagoda

any idea how i can word this better?

maybe im being a bit too advanced

[pulsar bobcat]

here im using post add because i dont have any special init, ill just create one by one the slots

[kind fable]

its nothing to do with the slots

[left shore]

I think the input is the inportant thing here

[kind fable]

your UI will do an initial setup when the inventory is ready (and it may already have items)

you setup your UI with the data already in the inventory

then you bind to the callbacks so it can be dynamic

(OnItemAdded/OnItemRemoved)

after initial setup

[pulsar bobcat]

so, you we are only taking about

HUD:

• gets created
• gets inventory comp from owning player
• call "im ready"

Inv Comp:

• "im ready":
  • do stuff

?

[kind fable]

but the call is special

if the inventory is ready, it fires the delegste instantly

[pulsar bobcat]

yes, but why cant i use the "OnAdd" delegates i would like to use ?

why do i HAVE to do a special init

[kind fable]

because the inventory might have items BEFORE the UI is on screen

[pulsar bobcat]

didnt say the opposite

[kind fable]

then what do you do?

[pulsar bobcat]

well there is no issues, its created on server and prob already reped to client

[kind fable]

...

[pulsar bobcat]

it waits for HUD call

[kind fable]

you are lackig a lot of knowledge with latency and unreal networking

[pulsar bobcat]

let me do a graph and come back in a few mins

[kind fable]

what shows up first the UI or the inventory data

you cant determine that unless your inveotyr makes the UI

which is very bad design

[pulsar bobcat]

i swear we are saying the same thing, but my words are not correcty used so it makes me tell something im not thinking

[kind fable]

think blueman is writing an essay

[granite pagoda]

@pulsar bobcat Ok so this is like a deferred initialization

Your UI "submits" a request to be notified when the inventory is ready, if it's ready it fires immediately
If it's not, the delegate is queued up and fired once the inventory becomes ready

Inventory/manager doesn't care what's waiting for initialization, if it's UI, or whatever else
It's a common patten for a generic "notification" system for when something is ready or becomes ready at some later time when it notifies anything queued up and waiting for that to happen

You don't need to cache any parameters, whatever data the delegate needs should either be in the delegate payload (which UE delegates support) or lambda captures
The only parameter if any should be the reference to the inventory itself, that's it

Now I'm not sure if my explanation actually helps 😆

[kind fable]

yeah its really hard to explain

but its super simple design pattern once you have done it once

[granite pagoda]

yeah

[kind fable]

people get caught it up in a tunnel vision style

[pulsar bobcat]

yes, thats what i understood since the start of this thread ^^'

[pulsar bobcat]

.

[kind fable]

maybe i should make a blog post about it

cause its a pretty common design pattern especially for multiplayer systems where noting is guarenteed to happen first when it comes to UI

most people hack it by using delays and shit, but that is a terrible way to do it

[left shore]

I do a loop of delays of 0.05, it's good

[kind fable]

amount of people that use Delay of like 1.f then initialize, is terrible design pattern

[granite pagoda]

that essey would have been written quicker if my PC wasn't completely frozen at the moment 😆

[kind fable]

that AI is going to take over the world

i swear

[pulsar bobcat]

so thats what you are saying Kaos and Blue Man ?

updated image, forgot to delete something

[pulsar bobcat]

@kind fable
ig i shouldve of pinned straight away

You can answer tomorrow, gn

[granite pagoda]

looks correct

[pulsar bobcat]

So we are on the same page since the start of this thread 🥲

[left shore]

even I am

[kind fable]

that wasnt what i said or suggested but 🤷

you keep thinking about ItemAdded/ItemRemoved

this is not a good way to do it.

[granite pagoda]

Actually nvm, didn't notice this part

Like Kaos said, bind to register and when it actually gets registered set up the rest

[pulsar bobcat]

i dont understand why

[kind fable]

you dont save the OnAdded/Onremoved delegates

that is not what i ever said

[pulsar bobcat]

@kind fable i think its better if we continue here

so what you are saying is, when inventory is ready, you send a special "init" event to the UI, then bind the actual "OnSlotAdd/Remove/Change"

but instead of this "init" event i wanted to store the delegates "OnSlotAdd/Remove/Change", i understand that if its cursed then i'll go with your design

[kind fable]

your thinking so linear about the problem

your focused on one train of though

like the pattern i showed is how our inventory UI is done

we ask the inventory, are you ready, it responds either instantly or delayed with "i am ready now, here is the items i already have"

we setup the initial items that the inventory sent us

then we bind to listen to new changes from the inventory

[pulsar bobcat]

okay i see

i'll work on that

[kind fable]

if its done properly, you can reuse the same functions

in your UI

so you dont need to do different stuff

basically your still running the logic on the UI as if the delegate fired

but instead your looping through the initial stuff in the inventory

[dapper inlet]

i dont know why you need the bHudReady thing

you can add an intermediate controller layer to separate your UI from having to be updated directly by inventory

see MVC style

your inventory just updates the controller when it is ready, UI reads from controller + listens for update from controller if inventory pushes changes

[pulsar bobcat]

whats the benefit with a extra layer ?

[dapper inlet]

you dont have all that init order nonsense you have

• multiple systems can read from same controller

the controller can just be an object that lives somewhere, can be referenced by both the inventory component + ui

ideal place is PC

or use the inbuilt MVVM thing

[kind fable]

MVVM is ok, but i wouldnt suggest it without having a working system in place. its extra complexity to a simple problem.

also MVC style is a PITA in unreal.

the issue is mainly multiplayer

[dapper inlet]

i agree, its up to him to make the decision

[kind fable]

what shows up first the UI or the data

MVVM would work, but its a bit of a setup to do

the data might have replicated from server before the inventory UI is even available

[pulsar bobcat]

what happens if the inventory comp calls OnInventoryReady before UI binded itslf to it ?

[kind fable]

then those binding delegates are useless

[pulsar bobcat]

there is no backup there

[dapper inlet]

yeah i had that problem so i just setup my own MVC framework

[kind fable]

thats what that special function does

that i showed you

{
    if (IsInventoryReady())
    {
        Delegate.Execute();
    }
    else
    {
        OnInventoryReady.Add(MoveTemp(Delegate));
    }
}```

it doesnt matter if its ready or not, it will fire the delegate

either instantly or delayed

if you decide to use MVVM,its a bit of a setup to do

[pulsar bobcat]

i dont fully understand what this function do

[kind fable]

but it has benefits in you dont even need to broadcast/bind delegates in your UI

read it @pulsar bobcat

its really super simple

[pulsar bobcat]

from what is it called ?

UI ?

[kind fable]

?

[pulsar bobcat]

what calls CallOrRegister_OnInventoryReady

[kind fable]

your UI with a delegate

[pulsar bobcat]

so its this part ?

[kind fable]

InventoryManager->CallOrRegister_OnInventoryReady(FOnInventoryReady::FDelegate::CreateUObject(this, &ThisClass::HandleInventoryReady));

from your UI c++ base

[pulsar bobcat]

okay

but, if IsInventoryReady(), it fires it with Delegate.Execute();, so this handles the case where the inventory was ready before the UI tried to bind itself ?

[kind fable]

yes

[pulsar bobcat]

but your FOnInventoryReady contains params ?

or do you read the inventory

[kind fable]

you can send what you like

maybe the inventory component pointer

maybe the inventory items as an array

your choice

or nothing