Author Topic: [BG Official] Brickadia Hate Thread  (Read 50938 times)

ur delusional if u think a spiritual remake of blockland isn't gonna have mod support before release
credibility tanks below sea level as soon as they drop the "ur"s and "u"s

They are designing all the game systems with the eventuality of modding in mind, as such it'll be easy to add new content to existing systems. The only reason you can't make mods right now is because you would need their unreal toolkit to create compatible assets, and they're not ready to work on making a releasable toolkit for the purpose of modding yet since there is a lot of logistical issues that need to be considered with that which will actually be easier to consider once the game is more complete. Also, as Electrk mentioned earlier they are also waiting to see if unreal will end up having its own official scripting language, since anything officially added to the engine will obviously be a superior solution to any scripting language they could add later. And even if an official scripting language never pans out for unreal they can still add their own.

any game without modding support in as early as the alpha will never have mod support because it's too expensive to implement later in development. modding is an interface, everything should be built on top of it, not the other way around

you can easily look at minecraft as a good example of late mod support. for like, 8 years since its launch mod compatibility was nonexistent and mods that referenced the same namespaces would conflict with each other. it took microsoft's buying of the entire brand and 3 more years to add some semblance of mod support and you can see how poorly it's made. compare that to a game like kerbal space program which shipped with outside assembly loading in as early as alpha, you can see the difference in mod quality

probably one of the first things brickadia should've shown off was its mod support. of course all mods would be unstable but it would give people time to adjust to brickadia's method of content creation
You've gotten really good at talking matter-of-fact about things you aren't trustworthy authority on. How many codebases have you interacted with or have watched start from alpha to completion that totally couldn't implement mod support because it's "Too expensive"? Do you honestly believe one has to literally reinvent the wheel in order to add mod support?

Sure it's not loving easy to add modding support once the official release builds are pushed out, but considering this is basically their passion project, they have no deadlines and this is the only thing all of the developers are working on, if they waited until the last moment to start developing mod support it probably wouldn't take that long to implement. You're doing a lot of ass-pulls about a codebase you haven't done any research on and you're saying matter-of-fact statements about design philosophy you don't have any legitimate experience with. But sure, go on and keep writing paragraph upon paragraph about it like it means anything to anyone, and keep pretending you give a stuff, it's only your time that you are wasting.

>it took 8 years since it's launch for minecraft to get mod compatibility
Once the 1.6.X updates rolled out around, how item and block IDs were referenced and used were directly restructured so more items and blocks, and items with changing properties were easier to add, for both future updates and mod content, which by that point about four years after the game's release, already had a whole host of mod content. The first widely used third-party API, Bukkit, was released only about one and a half years after the game's first few public builds. The game never really got it's official modding API release because from what it sounded like, third party content was already filling that role sufficiently.

unreals native blueprint and package systems aren't an actual modding system. you should check your facts because if you think having the capacity to only make unscripted cookiecutter addons is 'mod support' then you're crazy lol


The way it stands you could probably not make a brickadia new duplicator without injecting dll files
Historically, mod content for unreal games required you to work with a modified unreal engine studio tailor-made to mod the game. I have no loving clue what you mean by the native blueprint and package systems aren't an actual modding system, this sounds like someone talking out of their ass would say. Arguing semantics is handicapped, but anything with modified files or user-generated content is a mod, anything that facilitates modification or creation of third party content is a "Modding system."
« Last Edit: August 15, 2019, 09:50:16 AM by IkeTheGeneric »

Also I realize how futile it would be to argue with you on this, you're just going to clatter pots and pans about surface level information since you don't give a stuff anyways, I've come to the conclusion you get into this big wordy arguments because you like arguing and feeling like you're right about things. It just honestly pisses me off when idiots go on about things they don't understand, you come off as extremely arrogant.


The biggest thing that tips me off that you're full of stuff is how you called Blueprints "Not an actual modding system" when Blueprints is UE4's visual scripting interface.
« Last Edit: August 15, 2019, 09:59:25 AM by IkeTheGeneric »

You've gotten really good at talking matter-of-fact about things you aren't trustworthy authority on. How many codebases have you interacted with or have watched start from alpha to completion that totally couldn't implement mod support because it's "Too expensive"? Do you honestly believe one has to literally reinvent the wheel in order to add mod support?
you don't have to have a masters in computer science to know that if you derive 200 classes from one deprecated interface, you'll have to go back and change all of those 200 classes if you use a new interface. mod support is incredibly hard to achieve later on in development. it's not as easy as just go back and change a few lines of code so that they're public, you have to go in and add callbacks and hooks so that other assemblies can supply their own logic. it's a scale problem, and as the project grows the problem becomes bigger and bigger. i'd haul out my second edition of code complete from the closet and copy and paste the entire chapter on development costs and how scaling and scope influences it but i dont think you deserve it

Sure it's not loving easy to add modding support once the official release builds are pushed out, but considering this is basically their passion project, they have no deadlines and this is the only thing all of the developers are working on, if they waited until the last moment to start developing mod support it probably wouldn't take that long to implement. You're doing a lot of ass-pulls about a codebase you haven't done any research on and you're saying matter-of-fact statements about design philosophy you don't have any legitimate experience with. But sure, go on and keep writing paragraph upon paragraph about it like it means anything to anyone, and keep pretending you give a stuff, it's only your time that you are wasting.
i dont know why you keep mentioning codebase like cpp has some special god-tier tool that allows you to inject mod support into any system on your solution. its not even some super enigmatic field of design, it's just common sense. you build the foundation before you build a house, because you can't just lift up the house and change the foundation in post.

it took 8 years since it's launch for minecraft to get mod compatibility. Once the 1.6.X updates rolled out around, how item and block IDs were referenced and used were directly restructured so more items and blocks, and items with changing properties were easier to add, for both future updates and mod content, which by that point about four years after the game's release, already had a whole host of mod content. The first widely used third-party API, Bukkit, was released only about one and a half years after the game's first few public builds. The game never really got it's official modding API release because from what it sounded like, third party content was already filling that role sufficiently.
Bukkit isn't that good. it only solves the superficial mod conflicts when two mods reference the same class, but from there not much can be done. because callbacks dont exist in the vanilla minecraft code, two mods cannot hook into the same methods unless they're entirely additive mods (add outside content). if you wanted to make a mod that dropped two dirt items instead of one when you break a dirt block, you had to recreate the entire dirt class from scratch and use that instead of vanilla dirt.

If minecraft had actual mod support, they'd have callback interfaces that any class can publicly add their own logic on to so all mods can supply their own logic to default methods without fear of conflicting. this is something that bukkit can't really do because it requires rewriting a lot of classes from scratch. even making some kind of IModdable interface is hard because you need to expand that into IModdableBlock and then IModdableMob and then each subcategory for special methods each uses. I'm sure blocks all share their own constructor and destructor and that's a great place to add callbacks but many of the other blocks have their own logic, like doors and switches with states, or ice and mud that slow you down.

Historically, mod content for unreal games required you to work with a modified unreal engine studio tailor-made to mod the game. I have no loving clue what you mean by the native blueprint and package systems aren't an actual modding system, this sounds like someone talking out of their ass would say. Arguing semantics is handicapped, but anything with modified files or user-generated content is a mod, anything that facilitates modification or creation of third party content is a "Modding system."
not only is the sdk that would come custom made for brickadia like 50 gb, but the developers still have to add their own package management in order to prevent people from just making whole builds and redistributing them as the mod itself (see: vanilla blockland). and even then its all pretty damn limited, we'd be forced to use blueprints, which suck.

i know you like to look at mod support as this hollow definition of changing a video game, but there's definitely levels to it. blockland has really good mod support because not only can you add new content to the game, you can change content that already exists. i don't know the landscape of blueprints but i'm guessing its entirely additive and you can't actually change baked content in the game. things like ammo systems on an additive mod support system are basically impossible because you wouldn't have access to firing methods of other classes.
« Last Edit: August 15, 2019, 10:44:30 AM by PhantOS »

not gonna even unpack this, you're full of stuff and you're always full of stuff, good day sir

not gonna even unpack this, you're full of stuff and you're always full of stuff, good day sir
how many codebases have you interacted with

not gonna even unpack this, you're full of stuff and you're always full of stuff, good day sir
why would you do this to yourself LOL

why would you do this to yourself LOL
go ahead and explain to me what i'm going to get out of arguing with someone who doesn't know what they're talking about, im not a brickadia developer

what makes you think i don't know what i'm talking about? because i'm not a brickadia developer either i have absolutely no knowledge of design practices?

im not telling them how to do their job i'm just highly skeptical of unreal's modding capabilities and i know for fact that as of right now there's absolutely no runtime mod support and even if they add a scripting language to it it's going to take a few years for it to leave preview mode and be stable
« Last Edit: August 15, 2019, 10:52:46 AM by PhantOS »

what makes you think i don't know what i'm talking about?
by what you said, you talk big game for a dude posting entire screeds on a lego forum


im not telling them how to do their job i'm just highly skeptical of unreal's modding capabilities
baselessly skeptical about an engine you straight up showed you dont know how it works by saying stuff like what you did about blueprints lmfao


i know for fact that as of right now there's absolutely no runtime mod support and even if they add a scripting language to it it's going to take a few years for it to leave preview mode and be stable
based on what knowledge? how do you know this?
« Last Edit: August 15, 2019, 10:54:15 AM by IkeTheGeneric »



go ahead and explain to me what i'm going to get out of arguing with someone who doesn't know what they're talking about, im not a brickadia developer
as soon as you explain to me what the hell you got out of whatever the hell you just posted. did you just need to vent a little? do you feel better now? why would you put that on blast like that? why would you waste your time writing out something you're not even gonna attempt to defend? LOL

baselessly skeptical about an engine you straight up showed you dont know how it works by saying stuff like what you did about blueprints lmfao
there have been so many instances of the devs saying that they plan on incorporating blueprints into mod support that it's practically ingrained into my existence. i know its a visual scripting language, and like all other visual languages, the developers have to supply their own fields to the visual scripting interface and that's as deep as it gets

based on what knowledge? how do you know this?
unreal mods are compiled
« Last Edit: August 15, 2019, 10:57:45 AM by PhantOS »