Standalone [1.3] tModLoader - A Modding API

- Mod sound & music playback reimplementation & fixes.
So you'd rather play with mods that don't have their music and sound effects implemented?
- Object-oriented topological sorting-based redesign of interface layers and world generation passes.
You'd rather have mods release on their current structure only to have to update again later when they optimize/redesign their world generation layers and such?
- Conversion of Tile to 'struct' for the sake of memory optimizations.
Memory optimizations, especially on a 32-bit app does mean things, because the lighter certain things are, the more mods one can run before running into Out of Memory errors... A huge problem with the current 32-bit only TModloader for 1.3.x
- Steam Workshop support - though this may release after TML 1.4, the timing is still a bit undedecided
I give you this one, its a nice to have. We do have the in-game mod browser, but I'm certain the TModLoader team would rather shift mod hosting over to Steam so they don't need to continue operating the mod repository they've got currently that powers their in-game mod browser/downloader/installer. I'm sure the TModloader team doesn't get paid to host the mods on the mod browser as it is...

Out of the four items above, feels to me only one of them aren't more necessary than the others. Steam Workshop Support ... But again, that's up to the team to decide.
 
especially on a 32-bit app does
tML is a 64bit .NET Core app in 1.4 (originally targeted AnyCPU, don't know if there are plans to support both architectures again yet). This isn't downplaying the usefulness, just adding some extra context. Any memory improvements are good for a game like Terraria.
 
tML is a 64bit .NET Core app in 1.4 (originally targeted AnyCPU, don't know if there are plans to support both architectures again yet).
That's good to hear. However, I'm referring to how the current tML release is purely 32-bit only, (And needs yet another 3rd party to get a 64-bit client released) ... Glad to hear this barrier has been defeated.
 
So you'd rather play with mods that don't have their music and sound effects implemented?

The music and sound already works although with some looping and bugs, which should be prioritised before launch, but the Tmodloader team would rather "reimplement" the entire thing from scratch rather than just fix some bugs in the current code.

You'd rather have mods release on their current structure only to have to update again later when they optimize/redesign their world generation layers and such?

Yes. It doesn't take long for modders to update their mods. Ask the modders themselves if you don't believe me. It's a small price to pay, and like I said, Tmodloader updates could be published with large changes infrequently, so as to avoid modders having to update numerous times and often.

Memory optimizations, especially on a 32-bit app does mean things, because the lighter certain things are, the more mods one can run before running into Out of Memory errors... A huge problem with the current 32-bit only TModloader for 1.3.x

We've all had fun playing Tmodloader for the past 5 years without this change. Why is it necessary all of a sudden now? It's a positive improvement I would like to see but why couldn't the modders release Tmodloader now and work on these nice optimizations afterwards instead of making people wait?
 
Ask the modders themselves if you don't believe me.
Nah, bro, I'd rather have everything in one go. Also, for anyone that doesn't only own QoL mods, it definitely does take time to properly polish.
 
Nah, bro, I'd rather have everything in one go. Also, for anyone that doesn't only own QoL mods, it definitely does take time to properly polish.

Well let's say Fargos or Thorium for example, how long will it take?
 
Well let's say Fargos or Thorium for example, how long will it take?
Took me like 3-5 days to port Fargo's Mutant Mod, but it was incredibly unpolished. Souls would take considerably longer. Thorium already has a port started by @direwolf420 AFAIK, but I'm not familiar enough with the code-base to estimate.
 
Took me like 3-5 days to port Fargo's Mutant Mod, but it was incredibly unpolished. Souls would take considerably longer. Thorium already has a port started by @direwolf420 AFAIK, but I'm not familiar enough with the code-base to estimate.

So for this large 1.4 update you'll have to spend 1-2 weeks sorting out one of the biggest mods on the platform, and less time for smaller mods.

Let's imagine Tmodloader prioritises all of the most important bugs, fixes them, then releases today. You'd spent 1-2 weeks updating. Then Tmodloader can spend time working on their four main core objectives listed above in their own time, and push out an update when that's complete in a couple of months time. In which you spend another week updating.

Would you prefer making thousands of players wait another six to twelve months for Tmodloader, so that modders don't have to spend 1-2 weeks time updating their project?
 
So for this large 1.4 update you'll have to spend 1-2 weeks sorting out one of the biggest mods on the platform, and less time for smaller mods.

Let's imagine Tmodloader prioritises all of the most important bugs, fixes them, then releases today. You'd spent 1-2 weeks updating. Then Tmodloader can spend time working on their four main core objectives listed above in their own time, and push out an update when that's complete in a couple of months time. In which you spend another week updating.

Would you prefer making thousands of players wait another six to twelve months for Tmodloader, so that modders don't have to spend 1-2 weeks time updating their project?
Your thinking is flawed.

Firstly, the amount of time tML has taken is inexcusable, and that's honestly obvious at this point. Certain contributors have down an amazing job at scaring off or discouraging other contributors from ever touching tML due to previous events.

Secondly, your method of thinking is narrow-minded. The entire point of stuffing this into a single update is to avoid annoying and cumbersome accommodations and obsolete/otherwise archaic implementations in the future. A lot of time has gone into refining and improving the actual code base and API as a whole. Your thought experiment isn't realistic and doesn't accurately represent what the team is focused on, so it doesn't really apply.

Currently, it's more of a "just make them wait since they've already had to" type deal, since releasing tML as it is now when there's still a lot of other stuff that needs to get done is just going to frustrate modders and will discourage updating anyway. The main stuff the team wants to get done does not represent what is currently being worked on.

If you want to play tML 1.4 so badly, then just grab a beta from GitHub.
 
Secondly, your method of thinking is narrow-minded. The entire point of stuffing this into a single update is to avoid annoying and cumbersome accommodations and obsolete/otherwise archaic implementations in the future. A lot of time has gone into refining and improving the actual code base and API as a whole. Your thought experiment isn't realistic and doesn't accurately represent what the team is focused on, so it doesn't really apply.

They could make these changes after releasing. Development doesn't cease after release.
 
They could make these changes after releasing. Development doesn't cease after release.
You completely missed the point. One of the main purposes of this update is to abolish redundancies and obsolete features. This would just reinstill them later.
 
You completely missed the point. One of the main purposes of this update is to abolish redundancies and obsolete features. This would just reinstill them later.

Why not do this after releasing?
 
Why not do this after releasing?
Because doing that after a release would force a bunch of mods to update again, which is generally inconveniencing and takes away from one of the main goals of tML 1.4 restructuring and refactoring its internals. Stop being selfish and asking for an unfinished mess of an update.
 
Because doing that after a release would force a bunch of mods to update again, which is generally inconveniencing and takes away from one of the main goals of tML 1.4 restructuring and refactoring its internals. Stop being selfish and asking for an unfinished mess of an update.

Is an object-oriented topological sorting-based redesign of interface layers and world generation passes necessary to this goal?
 
Is an object-oriented topological sorting-based redesign of interface layers and world generation passes necessary to this goal?
Absolutely not. No idea why the hell that's there, blame Mirsario.
 
would I be able to use steam mods along with tmodloader somehow, or is it impossible?
 
Strange to see that Blushiemagic still didn't update this thread to the new Alpha version for 1.4.
Maybe tomorrow or in a couple of days she edits this thread.
 
Strange to see that Blushiemagic still didn't update this thread to the new Alpha version for 1.4.
Maybe tomorrow or in a couple of days she edits this thread.
blushie really isn't around much, anymore. Most of us want to keep this more under wraps, regardless.
 
Why under wraps?
No need to spread the news of the alpha around and get peoples' hopes up regarding a potential proper release date. This is still just an alpha, as well, and isn't production-ready. It's only out currently for the sake of testing.
 
Back
Top Bottom