Remove unused content from CoreRPG

[Tommycore]

Heya!

tl;dr- I was wondering if there's an easy way to remove all the unused content from the CoreRPG ruleset.

So far I've been going through every single form and used merge="replace" on frame tags to load my own graphics. Simply because I don't want to load the same frame image three times under different names. That'd be a waste of resources. Especially as I don't want to use any of the fantasy looking gui-elements. However, while it is a good training in getting to know the ruleset, it is tedious work. I gotta be careful not to use replace/delete merges on any graphics that are still referenced somewhere, because that can lead to me searching for unthrown errors for a little eternity. Is there any way to tell FG to unload, or better yet, not load in the first place, anything that hasn't been used? Because at that point I'm beginning to wonder if it wouldn't be more efficient to start from a blank ruleset, and only throw in the stuff I need, so the result is a nice and slender ruleset without all the tons of overhead. I mean - CoreRPG is an amazing allrounder that can offer a lot for many systems. But it seems like the typical tradeoff - being bloated and somewhat cumbersome - applies here as well.

I tried searching the forums, looking at other rulesets that are based on CoreRPG, googling, but I'm none the wiser, I'm afraid. Any help/suggestions/views appreciated.


Cheers!

[Trenloe]

You need to specifically remove what you don't want. There's nothing automatic to remove stuff that isn't used.

I wouldn't recommend building a ruleset from scratch. This is how most rulesets prior to v3.0 (when CoreRPG came out) were developed and now they are way behind FG functionality and need to be converted to using the most current CoreRPG - or stay with years old functionality. I'd recommend using CoreRPG and remove what you don't need in a layered ruleset. If you just want to change a graphic then change the underlying graphic definition.

[Tommycore]

Ah, bummer. I was afraid that answer was coming. Thanks nonetheless, especially for getting back to me so quickly. I'm curious though - what functionality exactly are you talking about? I mean, as far as I understand it, there's nothing the other rulesets cannot make use of, is there? So shouldn't it simply be a matter of keeping up with the new releases of FGC/FGU?

Addendum: At what point of ripping CoreRPG apart and implementing substitutes would the danger of CoreRPG making major changes and breaking a layered ruleset be higher than missing out on new features in a completely custom ruleset? What if I wanted to do my own chat via OOBMessages, change general data layout, etc.?

[Talyn]

Most of the core functionality you see in all the layered rulesets are contained in CoreRPG. Rollable tables. Story templates. Reference manuals. Basic and grouped lists. And so on. That way they only have to update CoreRPG and all the other rulesets get the benefits of that. If you really want the responsibility of keeping up your own codebase in sync with them, I mean... go for it I guess? I'd rather have them do the heavy lifting while I just concentrate on my special bits of code.

All I'm seeing you talk about right now are the graphics. And sure, it can be a little tedious. But every single ruleset and every single theme replaces graphics. Good thing all those definitions are pre-built into CoreRPG and you're not having to build them from scratch, right?

Adding cool new features? Go for it. Look at how 2E is doing things, and giving the main developers ideas that they could implement back into CoreRPG that would benefit everyone. A few things from Savage Worlds (the 'new' lists come to mind) were also added to CoreRPG.

Also, let's say you build TFT then release it (free or retail, doesn't matter). Then for whatever reason you move on. Take a look around the forums at the rulesets, extensions, modules, etc. which have been abandoned. There's practically zero ROI for this stuff, and the very nature of community development is that you end up with a rotating community. Then you have new users come in and ask "wtf is this? why doesn't [insert ruleset here] behave normally?" and so on. (Like Trenloe up there. He wrote the Edge of the Empire ruleset which is pre-CoreRPG. Load that up and prepare for a whole new learning experience because it doesn't look or behave like anything else. And he's so busy with Pathfinder 2 who knows if he will ever have the time or interest to do a full overhaul to make it CoreRPG-compatible? Trenloe is one of the top community developers around FG, I would listen to what he's telling you.) Or it's been left behind to the point it no longer works. At least layering over CoreRPG keeps all the basic functionality users expect intact (again, SmiteWorks is doing the heavy lifting there) so it's just your bits of custom TFT code that need to be looked at.

[Tommycore]

I know the simple question "Which is the way to go" has been answered quite a few times. Believe me, because I've read every single thread about it I could find. I may not have posted much, but I've been reading a lot. Which is also why there is not even a hint of a doubt about the capabilities of Trenloe, Zaccheus, Lord Entrails, and all the others, including the devs of course. I've also been taking apart the CoreRPG ruleset to the virtual bones, looking at how things were implemented, trying to rebuild them, etc. I went from a complete and utter noob to at least a solid foundation of basic understanding of functionalities and concepts within the time I've been working with FG now. I may be new to Lua and FG, but I've been working as a professional game developer for quite some years now, so please believe me when I say that I am not asking this because I was too lazy to do my own research, didn't read up on the topic, don't have a solid grasp on programming, or am otherwise showing a lack of respect for the time and skills of my fellow community members.

I am also not just asking to get a basic "Which is generally a better idea" answer, because - like I pointed out - I did my research. And normally there are a myriad of good reasons to stick to CoreRPG, like you said. I am looking for consultation on the details. Like I said - CoreRPG is a superb allrounder, offering an amazing adaptability. But if I want to make it look and act like FG was written for my game, I would have to get rather deep into CoreRPG, and either carefully entangle my code for layering, or ripping out whole subsystems. I'm talking about things from highlevel functionality like overwriting basic dice action, the /die slashcommand including ChatManager.onSlashCommand() for updated help text, down to low level stuff like data management, or window controls. And yes, I could unload a lot into extensions, but that means including required extensions every single time you start a new game. Extensions, mind you, that are meant for a specific game, where I have neither time nor will to make sure that they work properly in vanilla CoreRPG, let alone any other ruleset. So my thoughts are about how high the risk is of getting into conflict with any update to the CoreRPG, if I cut deeply into it's fundaments. Not because of some switched graphics. Not because of some minor visual stuff and extended rules. I know the answer if that was the case.

I am sorry if my questions didn't make that clear. I did not mean to appear rude or condescending. Thank you for your input.

[Talyn]

I didn't take it as rude at all.

I get what you're saying but... look at it from this perspective: as one of the DLC Developers myself, in addition to getting all the playable data, I have to figure out how to adapt the printed rulebook (PDF) into a reference manual, which has nowhere near the layout capabilities that books/PDFs do. That's why we've (most of us anyway...sigh) stopped using "convert" in favor of "adapt" for all this stuff.

In addition, SmiteWorks themselves are looking for more consistency going forward, now that Unity is nearing release. A week or two ago they did a mass changeover to all the radial icons so that everyone in every ruleset sees the same thing. Coming soon are new toolbox and sidebar icons and layouts for the same reason. They (and we) want users to be able to jump from a D&D 5E game into a Savage Worlds game into a Traveller game with as little difficulties and WTF-ness as possible. The community ruleset devs (GURPS for instance, since that's what you're using as a baseline) will hopefully get on board and catch up eventually.

So rather than having a "I shall force FG to kneel to my whims" and then end up with confused users and doing more support than you'd otherwise need to, why not just go into it with the attitude of "this is the commonality of the FG experience that users expect, I'll work within those parameters and expand outward from there?"

[LordEntrails]

Tommy, I know you're deep into the development side or considerations of this, and those are important, but as Talyn has mentioned, I also think you should look at the user/customer side of things. There are 'business/emotional/customer' side of things that I would look at a bit more.

First, where are most of your users going to come from? Are they going to be existing FG users, or do you think you will be bringing new people to FG? If they are existing FG users, will they prefer to have 'expected/typical' FG behavior, or will they prefer a new experience? I don't know the answers to these. The 'safe' answers are to say they will be existing users who will want a typical FG experience, but, those may not be the 'right' answers. (If their is a right or wrong answer to these questions.)

Another aspect is how 'perfect' do you think your architecture will be? And if new functions are added to CoreRPG, are you going to want to inherit those? For example, Reference Manuals, Story Templates and Random Encounters are all new capabilities that have been added to FG since I started using in 2015. These are things that may not have been envisioned as beneficial a year before they were developed, but have proven to be very positively received by the community. Do you want to inherit those automatically? Or do you want to adapt/import as you decide?

Also be aware, one of the primary reasons for re-architecting FG to Unity it to accelerate the pace of new features. So expect even more new stuff to be added to CreoRPG over the next few years than have been added in the last few.

Maintenance... inheriting CoreRPG means you need to be aware of the dev channel and make timely updates to your ruleset when CoreRPG updates break it. BEing stand-alone means you are not tied.

Longevity... How long do you want your ruleset to be viable? A big part of this is of course dependent upon what license you release your ruleset under. But the other big side of this is after you stop being active, do you want your ruleset to survive and carry on? If it's not CoreRPG based, it is very unlikely it will last more than a couple of release cycles.

Hopefully that discussion helps you decide. Though I will add one more section, what I see the typical FG user has as expectations (even f not reasonable/practical. And, anywhere I say ruleset, these expectations also apply to extensions);
- Updates don't break your ruleset
- New FG/CoreRPG features are available in custom rulesets when they are in CoreRPG
- Rulesets will continue to work forever

edit: Oh, and I totally understand the logical and emotional reasons to want to 'control' your own ruleset

[Tommycore]

Ok, you're right. I can, after all, make a usual FG port, and put in all the fancy bits via extensions. Quite a bit more work, cause I'll have to keep multiple projects going and up to date at the same time, but hey. Worst case scenario I can still drop the extensions and keep a solid normal FG experience. Maybe I'll just say screw resource austerity and simply replace the images. And make some minor adjustments to offsets and the like.

Thank you all for your time and input. This community is awesomesauce =D