Buildfile Base - Phase Two

#1

Hey all! I’m gauging interest for a community-based project. Essentially the premise is to have a base buildfile to work from so that projects can jump right into making maps and events instead of having to spend time setting up standard patches (QoL, Skill System, etc), adding common community graphics / classes / items, and so on.

In addition it would have every major tool available with examples of how they are used, samples for how to insert mugs, music, tilesets, etc, and sample events for common events such as recruiting characters, moving characters on the map, dialogue, cutscene battles, etc.

  • Yes
  • Yes, but do not include new classes / items / etc
  • No, too much variance on a per project basis
  • No, would not be used
  • No, skill system / ccb already exists as a base
  • No, other

0 voters

UPDATE:
Okay guys, the poll results are pretty clear with 88% YES and about 2/3 of that wanting new community assets included.
Moving forwards I want to have a community decision about what exactly does and doesn’t get included. Let me know what tools, graphics, patches, etc you think should be included. I’ll keep a running list so that we don’t get duplicate suggestions.
Here is that.
Let me know any credits I’m missing / that are incorrect, please.

8 Likes
#2

I’ll probably have to switch to FE8 at some point so this would be nice.

#3

Back when I lurked on Pokémon forums there was someone who made a buildfile, it was pretty great, specially because in Gen 3 there’s no definitive game to hack (there are base features that FR has over Emerald and vice versa) but luckily we do have FE8. A lot of people used it in their projects while others took the buildfile and gave it further improvements.
This will make FE hacking more straightforward and approachable for people, helping our community grow for the best.

TL;DR It is, and I think we can pull it off.

1 Like
#4

@CT075 was throwing around a similar idea. I don’t want to put words in his mouth so I’ll let him explain it if he wants to.

#5

I’ve had something like this on the back burner for a few years now; it’d be awesome to see someone actually do it!

If I had my way, the buildfile shell would be minimal at best, possibly with skill system/CCB or whatever (things that actually require significant setup) able to be turned on via a debug option. Buildfiles are pretty good at being plug-and-play anyway, so I’m not sure it’s necessary to really make the base have any “real” functionality.

I personally dislike the idea of adding things like community graphics/classes etc in by default (even if they can be “turned off” via configuration options and ifdefs), but it might ultimately be the better idea for longterm adoption. Similarly for examples – how many people actually look at the included text anyway instead of going straight for the tutorial?

One thing that this opens up, however, is that with a common buildfile base, you can possibly do something like hook FEBuilder (or a similar other graphics frontend) up to it much more easily. I had a design written up for how this would work, but I don’t know if I could find it at the moment.

I won’t be able to contribute much personally, but good luck! I’ll be watching this with some interest.

1 Like
#6

That sounds like Fire Shell which is dead.

1 Like
#7

I am interested in what kind of implementation it will be.
Are you planning to implement things like package systems like apt or npm?
Or are you planning to add many chunks of #IFDEF?
Or is there any other implementation?

If you are implementing in a package system, I would like to make it available to FEBuilderGBA too.

FEBuilderGBA has not yet packaged music and graphics.
These are because we need a lot of data and the license and the law are very complex.

#8

Looks like Chair’s gunna have to learn build files.

#9

Had I the time, I’d probably do something like this. Given my understanding of buildfiles you can literally include enable/disable tweaks to everything. I say add as much as possible, make it all enable-able and disable-able via a text file in the root folder, and it will be good to go.

Frankly, given the nature of buildfiles, this seems a no-brainer.

#10

Having this sounds like the excuse we need to finish the empty parts of UT2…

#11

I’m considering 2 implementations currently, which is ifdefs, or just having includes that could be commented out. I’m leaning more towards includes since it would be cleaner.

#12

As someone who has struggled to get a buildfile working, having a solid base to work from with the common add ons ready to go would be neat.

As long as samples show a breadth of what can be done (perhaps a chapter where you can comment in and out different win conditions, for example) to show the possibilities would be useful for first timers.

#13

You guys shouldn’t need an excuse…

7 Likes
#14

This is a very cool thing! VBA was kind of like a base for buildfiles but it had a bunch of extra stuff that newcomers didn’t really understand. I love this idea as it helps newcomers in the community get to learn and understand how buildfiles work if they are feeling that builder is not for them. Also if we do manage to create a “buildfile base” then I suggest going up and adding new things to UT2. It’s very unpolished and can use some fixing. Other than that hope this suceeds! Hope I can do anything to help.

#15

Wouldn’t having one master “options” file where you define things that control the ifdefs be cleaner though?

#16

That’s what I mean, all the optional includes would be contained to their own file.

#17

???

#18

Said includes would all be in one file. So in the main buildfile an optional includes event would be included, and then within said event all the optional includes would be lined up. So you could either uninclude them all via the master or uninclude specific ones from the event.

#19

I think for people whose projects involve the skill system, this won’t be very useful, because the skill system is basically already a project base. The only thing it doesn’t already have is graphics, aside from skill icons, skill animations, and 1 mug (Capture replaces the default 0x1 mug with a blank image for the purposes of trading with enemies without crashing the game in certain emulators).

I do agree that the skill system is intimidating to newcomers (as a project example/base buildfile) due to its sheer size. That is an argument for going forward with this project; however, it could also be explained in UT2 instead.

I don’t really feel one way or another about including animations by default, but bear in mind that animations and music (and text, to a lesser extent) drastically increase the time necessary to assemble the project. I personally get impatient when I have to wait more than 30 seconds to build; I doubt anyone else enjoys it either. The most annoying thing is waiting 5 minutes for your project to compile, only to be faced with an “1 error found. No data written to ROM” because you made a typo.

One thing I think would be cool is showing how to break up your buildfile into pieces so that you can build only certain parts of it. For instance, you only assemble events and whatnot that’s relevant to the chapter being worked on, while the rest is already in a rom.

#20

Fair points. I won’t include music other than a sample, unincluded by default, piece of music (probably like an FE7 song) to show how to do it. I’m planning to make all the animations and whatnot optional so if you don’t want to use them or wait around for them you don’t need to.
I’m interested in what you mean on your last point, though. Would you have two copies of makehack?