alexbatalov / fallout1-ce-assets

7 stars 3 forks source link

What's the goal here? Some communication? #1

Open phobos2077 opened 11 months ago

phobos2077 commented 11 months ago

So another big move comes out of nowhere. Do you want to transition from SSL to Lua? Is there any blog post/forum/discord with some context of what you're trying to achieve?

I'm following this project closely for a while, even made some contributions (but last one wasn't merged without any comment, and I'm not the only one...). But now I just don't understand if I should contribute or not because of all the "secrecy" and lack of communication. We set up a CE discord server but you're nowhere to be seen. Tried to contact you directly on different platforms to no avail.

What's the deal here? How do you expect "community" edition to have any community at all if you mostly ignore it?

alexbatalov commented 11 months ago

Hey mate, first of all thanks for keeping an eye on the project. You're damn right, here is some explanation.

The goal for this repo is to be a home for assets which will be bundled in future releases. I see three major asset types - graphics, game data and scripts.

Graphics - I guess this one is obvious, there is a demand for some visual improvements:

Game data mostly refers to slight improvements/fixes to maps, protos, and maybe localizations. One example of what I'd like to fix are edges on some non-square maps. I like the aesthetics of Tactics where edges gradually fade to black and have tried to make something similar with edges clipping but it only works in square maps (in F2 the same implementation looks much uglier). I want to store these files as JSON so that their content is visible in any editor and the changes are comparable.

As for the scripts I wanted to add Lua support from day 1 for Fallout 2. What I'd like to achieve besides initial transition is to gradually move some hardcoded behaviour to be scriptable. One example of what can be unhardcoded is world map travelling with random encounters setup. It is entirely hardcoded in F1, somewhat configurable in F2, but with scripting you're free to create virtually anything. In order to see how Lua fits Fallout engine, some research is needed and F1 is a better place for it (mostly because it's smaller and there is no active development targeting vanilla F1 engine).

I want this repo to keep the "source" of assets, so png for images, JSON for protos, UTF-8 for translations. Some build scripts will "compile" them to the engine-native format, probably validating it in the process (for example, that png image only uses colors from the system palette).

Let me know what you think.

phobos2077 commented 3 months ago

I urge you to take a look at existing high-res UI resources out there, namely bundled with Hi-Res patch and sfall, if you haven't already. So I would just port some HRP/sfall features first, then build upon them.

Recently I've made a small, vanilla-friendly extension for all inventory screens. You can find pictures here. This will be included (along with FRM files) in the next sfall update.

As for the scripts. You're not the first one to imagine using Lua instead of SSL. Despite our best efforts improving SSL language and capabilities (sfall modderspack contain improved and extended SSL compiler + decompiler, compared to original), the language still has some limitations and sometimes finicky to work with. But there are good reasons to keep using it:

  1. Community experience. Modders are familiar with FO opcodes and language already.
  2. Headers. This is a big issue. I'm assuming you have written some kind of int2lua decompiler? First of all, I'd very interested if you share this tool with the community. Second, the code for FO1, FO2 scripts, as well as all major mods used macros extensively. So simple int-lua conversion will generate code that is hard to read and have lots of duplicate code. Team behind EtTu project (full FO1 conversion into FO2 engine) did a lot of work to solve that, like their ReDefine tool. So something like this will be needed.
  3. Existing restoration/unofficial patch projects. Years of work has been spent fixing these games by community. So to make use of that, you would need to have some pipeline/tool made available so we could convert these projects into Lua as well, if so desired by devs.

About scriptable behaviors - I urge you to look at how hook scripts are currently designed in sfall. I'm planning to implement them to support modern mods. I suppose this idea of yours and hook scripts should be integrated into a single system somehow. So you don't end up with 2 different mechanisms for the same thing.

The main takeaway I would like you to go with: reinventing the wheel is fine, but at least consider existing wheels that came before :)

I'll be very interested to discuss your next plans and maybe help to align them better with the existing modding community. I figured, "Community Edition" should be all about that, right? :)