@editable Concrete Classes @editable Members Broken Occasionally

Make a concrete class with some editables

some_class:= class<concrete>:
    @editable MutatorZone : mutator_zone_device = mutator_zone_device{}
    @editable AudioPlayer : audio_player_device = audio_player_device{}

Then slap the class in a creative_device / sub class of creative_device (I extend creative_device in some projects but it happens with or without inheritance)

MyDevice := class(creative_device):
    @editable SomeClass :  some_class = some_class{}

    OnBegin<override>()<suspends>:void=
        SomeClass.MutatorZone.AgentEntersEvent.Subscribe(SomeMethod)


    SomeMethod(Agent:agent):void=
        Print("Some Method")

This works for me about 50% of the time… When it’s not working the only that will fix it is abandoning the current island i’m in and starting a new project / migrating the same code over to the new island. quite frustrating

2 Likes

what exactly breaks? been using that for along time on many occasions and never encountered an issue

This setup is not supposed to break, maybe you’re linking the mutator before Pushing Verse Update, which gets rolled back when you do ?

When you Push Verse Changes, some changes can rollback (in live edit only) without you knowing it

No Once The Issue Occurs, It Persists forever.

it does not recognize that there is an editable selected within the concrete class. I get the stale default mutator_zone_device{} as if there was nothing there

It’s not supposed to happen with native devices, this bug only happens with creative_devices, usually you can fix it by providing an optional instead :

@editable
MutatorZone : ?mutator_zone_device = false

yeah i’ve found the optionals to work sometimes as well. the faliure context is super frustrating to be forced into though. and it doesn’t work every time for me as well :frowning:

1 Like
@editable
MutatorZone<private>: ?mutator_zone_device = false

GetMutator()<transacts>:mutator_zone_device = MutatorZone? or mutator_zone_device{} # Mimics the non optional field

It shouldn’t work “sometimes” though, try to understand what’s wrong in your code or your map, because your setup is clearly very basic so it shouldn’t fail

i promise there is literally nothing wrong with the code lol.

as far as accessing the concrete class members i even sleep for 1.0 on begin

then i do a simple for loop

for(SomeClass:SomeClasses):
    SomeClass.Mutator.AgentEntersEvent.Subscribe(SomeMethodHere)

or

SomeClass.Mutator.AgentEntersEvent.Subscribe(SomeMethodHere)

this is some sort of initialization failure on begin on Epics Behalf

1 Like

It’s literally the most basic thing one can do, so idk what to say, does it do the same on other projects ?

yes by occasionally in the title i did not mean that it randomly stops working in a level that it was already working in, I meant that sometimes in fresh islands this issue happens and persists forcing you to migrate the same code to a fresh project where the same exact code proceeds to magically work again. Even code this simple does not work when it decides it wants to be broken.