Recent content by Aragas

  1. Aragas

    Resolved General [1.7.2] Loading any mods with dlls before Native causes siege engine placement icons to be not visible

    Can definitely confirm that this is a new regression!

    I created a simple empty module that only contained a derived empty class of MBSubModuleBase and put it before/after Native in the launcher and via command line args in Bannerlord.exe just to confirm.
    When the simple module was loaded before Native, the siege icon stuff disappeared.
    When the simple module was loaded after Native, everything worked as expected.

    Nothing foreign was used while testing. Neither BUTRLoader was affecting the launcher or any other non-native module like Bannerlord.Harmony was present in the loading list!
  2. Aragas

    [Tool] Localization Parser

    RESERVED, I SUPPOSE
  3. Aragas

    [Tool] Localization Parser

    This tool allows to extract every hardcoded localization string (e.g. `{=TauRjAud}{NAME} of the {FACTION}`) from the game's libraries or from a module's libraries to a .csv file. Link to the GitHub repository. Using as a dotnet Tool Installation 1. Install the latest .NET 5.0 Runtime. 2. Run...
    • Aragas
    • Thread
    • csharp dotnet localisation localization tool
    • Replies: 1
    • Forum: Community Tools
  4. Aragas

    OSP Kit Module Template for Visual Studio and dotnet

    RESERVED, I SUPPOSE
  5. Aragas

    OSP Kit Module Template for Visual Studio and dotnet

    Template extension for dotnet, eases the process of creating new mods for M&B 2: Bannerlord. This is another Module Template for Bannerlord. Just like dealman's template, it can work with Visual Studio, but it's based on the new dotnet template system instead of the classic .vsix extension...
  6. Aragas

    Suggestion General UI Widget Modification

    order_without_power said:
    I just discovered that for multiple mods which assign UIConfig.DoNotUseGeneratedPrefabs, the value of the last mod in the load order will be used. This will cause conflicts with other mods higher up in the load order which have a different value for UIConfig.DoNotUseGeneratedPrefabs.
    Click to expand...
    You can use a Harmony prefix in the property getter of UIConfig.DoNotUseGeneratedPrefabs that will block any further attempts of editing the property as a workaround
  7. Aragas

    Suggestion General UI Widget Modification

    emrozdemir said:
    Some of the issues with switching between XML and generated code in the same movie are,

    1. The code gen doesn't work like that. The generated code needs to have/know all the types and instances while generation. Essentially it needs to say "this string variable in this TextWidget is binded to this string variable in SPInventoryVM(for example)". And it needs to say this like "_textWidget.Text = _dataSource.HeroLabelName" for example. So it needs to know the specific type, instance and variable name. If it cannot know it, needs to get it in runtime, and that's reflection, what we're trying to avoid. So it goes from most parent to bottom, not individually separate.

    2. The generated code needs to have direct references to the instances it is creating. Since it needs to add children, set it's ids, set it's visual properties like Size, Sprite etc. So it needs to say, "Ah, I'll be adding a TextWidget FooBar and it's size is this, it'll have this as a Brush and it'll have this amount of Children etc." Changing that into a different widget with an overriding xml and adding new children or changing it's type, will break other references to FooBar and it's children. In the generated code FooBar might have 3 children and a widget higher up might be referencing it's second child like
    FooBar.AddChild(WantedChildWidget);
    HigherUpWidget.WantedChildWidget = WantedChildWidget as ListPanel;
    So even though the FooBar and WantedChildWidget is overriden from the xml, they're referenced in the code. This will result in an error.

    There are more issues like these but I don't want to make this post too long.
    Click to expand...
    Understandable.
    We did had a little discussion with our team about the runtime cost of reflection. Because the serialized XML widget can't change, any reflection action could be cached, bypassing the speed decrease.
    We use this technique a lot, creating delegates for property getters/setters or methods and caching them in our static/instance constructors and calling them without any overhead!

    emrozdemir said:
    Currently they're separate. The code is generated from the XML but after that there is no connection between the two. We cannot use XML in generated code and generated code cannot use XML.
    Click to expand...
    It boils down to the auto generated Widgets being the smallest units of UI modification.
    If a modder wants to change something inside of an auto generated Widget, perhaps some small inner Widget that is a separate XML file - he will need to indicate to the game factory that it switches to the old behavior when loading the widget, then do the XML magic. This seems quite acceptable!

    We will investigate how we could, for example, compile and cache the final Widget result after patching to match the AutoGens performance and basically follow your behavior, but at runtime instead of compile time, because of the dynamic patches. This does look like an interesting step to take and an interesting challenge! ?
  8. Aragas

    Suggestion General UI Widget Modification

    emrozdemir said:
    This will still be the case if we only used the xml. Since if we change related stuff in the xml like type names, hierarchies, Brush/Sprite names etc.(depending on how the mod accesses/modifies them). If there are no changes to the xml, there will be no changes in the generated code.
    Click to expand...
    Agree.
    C# is adding another potential breakage by using variable names. Depending on the generator, they might differ slightly, like elements in the same hierarchy level switching numbers. This is still theoretical and unproved anyway.

    emrozdemir said:
    I'm not sure what you mean with this. The code is generated from the xml and it goes through multiple automated generation stages before the deployment. So neither the xml or the generated code is outdated. I think this is happening not because the "SettlementNameplates" xml's content is different than the generated code, it's because only the "SettlementNameplate" is using the xml and the rest of the game is using the generated code.
    Click to expand...
    Yea, it wasn't checked whether it's needed to do the switching to XML in cascade. This will complicate things, because we'll need to know the affected Widgets all the way down.

    I'm not even sure here. Is the issue only when XML references autogens or when autogens reference XML's too?
    Would it be possible to make autogens and xml widgets work with each other? So cases like when you need to switch a specific autogen won't trigger cascade switching of everything.

    It's great to hear that we can potentially disable autogens globally, but considering that we can have a dotnet framework, dotnet core and mono runtimes, we wouldn't want to disable such optimizations just because it's easier for us to change stuff!
  9. Aragas

    Suggestion General UI Widget Modification

    Serialization of the XML to a generic Widget class at runtime and auto-generating it in compile-time differ a lot in performance, but it's seems more of a 'quick fix'. Optimizing the generic serialization logic is harder and more expensive.
  10. Aragas

    Suggestion General UI Widget Modification

    In the Beta e1.5.9, the modding community found out that most of the UI Widgets are now auto-generated in C# instead of being parsed from their XML definitions in the runtime. The game has an API to switch to the previous behavior, but the .xml definitions are not the same as the auto-generated...
See more
Back
Top Bottom