SignatureBeef/Open-Terraria-API

OTAPIv3 Client: user-friendlyness

0x3fcf1bbd opened this issue · 1 comments

This is a rather broad topic & issue, but I'll try to get straight to the point.
As it currently stands, the client isn't very user friendly in my opinion, for a few reasons:

  • Many many files:
    the folder contains many files and subfolders, that could maybe be organised better.
    Could have a DLL folder for all libraries, a subfolder for each kind (FNA gets its subfolder, Avalonia too, etc), a folder for OTAPI MFW modifications, and maybe moving (or deleting?) the installation, single use files somewhere else.

  • Leftover test files:
    Some testing files for the MFW mods were left there, and while this can provide examples, I think that by default no scripts should be preinstalled, and only up to the user to do this.

  • MFW lacks documentation about plugins/scripts:
    I have searched a bit, and I couldn't find any tutorial other than the examples given already. Examples are nice, but they don't teach much more than what one is able to salvage from them. If possible I'd greatly appreciate to see a MFW wiki being created, but I'm aware that it may take time.

  • Basic UI?
    Not really a great point, more of a nitpick, but I think that the launcher's UI could be improved. This I could do a PR probably.
    Once I clicked "Build otapi" instead of "Launch otapi", I think you can understand my pain.

I think that it is potentially the best Terraria modding framework, but it may become not broadly used due to this^. Of course it is quite niche compared to tML, but I believe it could be used for things such as server custom clients - in that case being user-friendly would be worthwhile.

i totally agree with this.
for the client end of things - this is now a quite big project that only stemmed from a few people probing to see if it was possible. and while i would love to be even able to compete with tml, i think there is a long way to go and there is only myself working on this unfortunately.

the client should really be considered alpha/prerelease as its so new and with that means quite a lot of bugs, some even from the process of porting windows from xna to fna (as you have seen).

Many many files:

this is something ive been working on. the main problem here is that no matter what i try there is some blocking issue to work around.
i have recently implemented a ./bin redirection for the tshock guys, however the same trick doesn't totally apply for otapi, nor does single file publishing as FNA wants to load the content files from the base folder of the app domain, which can be ./bin or %TEMP%/.net/{random}, which is a massive problem if i want to have the OTAPI files isolated.
i am still working on this as time permits, but been very busy again lately.

Leftover test files:

yes, i agree. like ive mentioned, the client side of things is so new i have mainly left them in for myself, and to demonstrate what 'can' be possible for those who were interested in the client back when i started it. now that more people seem to be interested in this side of the project, i will plan to disable them by default (just more important issues at hand first)

MFW lacks documentation about plugins/scripts:

yes this should have documentation, but im also interested to see what questions people have too so please, feel free to make some issues asking questions on its repo or here. the current examples mainly show you can [de]attach to/from events, at mod and runtime for a general base for people to start with in each language it supports.

Basic UI?

hey this is the first time we've had a UI! but yes, it was moreso smashed together in the early days for a more simple take instead of using the command line. i have plans to redo the entire UI so you can have multiple installs, and mainly so the installer/patcher can also work from another directory.
the problem with this so far, is OTAPI itself (the game) relies on the installer for the .net runtime, as during the patch process, the Terraria client installed on your machine gets retargeted from .net 4* to .net6 thats included with the installer.

once i can implement a way around FNA issues, and issues with running from a shared .net runtime, it should solve most of the technical issues stopping me from upgrading the UI.