[MOD][WIP] FTL: Overdrive

[speedoflight]

Since we're planning the animation class' structure, I'll mention an issue that I noticed in DryEagle's pirates mod; specifically, some animations appear to be hardcoded in that some are played from start to beggining, and others play random frames of the animation (namely, the "console typing" animation).

Wat animations?? i never saw a weapon / effect animation with a random order that will make non sense..can u specify?? i dont think thats even possible the way the png strips are designed and the way the game handles it.

[kartoFlane]

*shrug* I didn't test it, only saw it mentioned here.
As to how it is possible: the engine works by taking the image, extracting each frame and storing it inside an image array (as I presume). That way each frame can be accessed independently of the other, and the animation can be played in a random order.
From the post I suppose the random order is only used by the console working animation.

[DryEagle]

For augments, why not have a 2 tier system: for the regular folk, just have a list of attributes that they can change, and allow people to customise augments as needed.
plugins can be used to add to the list of attributes for those who really need something extra.

So you would have a default list of attributes which can apply to an augment: first you would split them by category, then have a ton of attributes. and you can pull specific ones into your mod.

e.g.
crew attributes - augments can affect any of rates: movement, combat, healing, repairs, suffocation, fire damage, fire-put-out, xp gain?

ship: weapon recharge, shield recharge, jump charge, nanobot dispersal, hull damage deflection, system damage deflection, dodge chance, repair amount, bonus scrap ...?

special attributes: z-shield, slug repairs, autorepair in general?, ftl jammer, the thing that lets you jump to any beacon...

you could have a list of all of these attributes, and then allow people to throw them into an augment blueprint, e.g.

Code: Select all

<augBlueprint name="Ancient_Artifact">
   <name>Ancient Artifact</name>
   <desc>An ancient artifact which upgrades multiple ship systems when connected to the reactor, granting increased fire rate, dodge, repair rate, and a chance to resist hull damage.</desc>
   <augAttribute name="weaponrecharge">1.2</augAttribute>
   <augAttribute name="shipdodgebonus">0.1</augAttribute>
   <augAttribute name="hulldamageresist">0.3</augAttribute>
   <augAttribute name="crewrepairrate">1.5</augAttribute>
   <rarity>4</rarity>
   <storePrice>200</value>
   <sellValue>250</sellValue>
</augBlueprint>

if people need to add special attributes which are not going to be included in an expansive "stock" set, they can write a plugin which will alter whatever they need, using higher level programing language than a simple xml entry. for everyone else, they will have the ability to easily make diverse and somewhat complex augments with a wide range of values. including separate entries for store sell and buy values allows for commodities to be made as tradegoods, or whatever is needed by the mod.

[966socho]

Is there a plan of including the ability to make blue options based on ship name/type or crew skill mastery?

[John Luke Pack Hard]

For augments, why not have a 2 tier system: for the regular folk, just have a list of attributes that they can change, and allow people to customise augments as needed.

Augments are already pretty complex. Some modify variables, while others enable special behaviors. Take, for instance, shield recharge booster, rock/titanium plating and drone retriever arm.

Shield recharge booster is a very simple variable change/multiply. Nothing special there.

The plating augments are rather ambiguous. On one hand, they can be seen as variables. 15% in both cases to prevent damage from being fired at. On the other hand, the 'variables' are never referenced anywhere else in the game, meaning these augments could also be seen as encapsulating special behavior.

In the case of drone retriever arm, it has to be implemented via Java function with a changeListener that picks up if the player fired a drone, and triggers the "refund" when the player leaves the sector. The behavior can only be implemented by the aforementioned function. Where the function exists is up for grabs between extern-plugin or hardcoded+xml sheet enabled.

Is there a plan of including the ability to make blue options based on ship name/type or crew skill mastery?

If the idea's on the list, we'll get around to discussing it.

On the other hand, I'm fairly certain there's a generic method in Java for testing object/variable case matches, so this might not even be worth discussing.

[speedoflight]

But i thought the point of augments is to make completely custom augmentations, not to pick one of 100 possibilities and stack em to make an augmentation with all in 1. I mean, augmentations will be a really pain in the ass, i know it, cuz its almost impossible to make "custom" augmentations with the powers u want. I mean, there must be a "list" where the code will pick all the possible choices, and that list will be always finite, so "custom" augmentations in the end is not the right word.

I mean, custom augmentations in overdrive will be same as FTL now, but the only thing that will change is the list of possible options u will have, and some other tweaks, but i will not call it "custom" augments, since thats not really possible. (i think).

[John Luke Pack Hard]

But i thought the point of augments is to make completely custom augmentations.

What I'm picking up is that, either way, augments are going to need *some* form of code, no matter what, whether that's just a 25% decrease on recharge rate, or a new, full-blown behavior that flips combat lopsided.

So I think we'll go with third-party plugins for all augments, with the core Overdrive module containing default plugins for vanilla augments.

[John Luke Pack Hard]

To further expedite development, I'd like to apply principles of XP development where possible, so I'll be developing the "animation" subclass of image tomorrow, and looking towards reporting results within the week.

In addition, I'd like to see more frequent discussion or feedback, because the faster we discuss this, the sooner KuroSaru and I will know what to do.

EDIT: I just realized I'll need the xml parser to fully test the capabilities of the animation constructor.
KuroSaru, please upload the xml parser to GitHub and reply to this thread with a link.

[John Luke Pack Hard]

I just recently had a discussion with someone at r/ftlgame and it reminded me of a point I wanted to bring up:

Vanilla FTL's beams behave differently when it comes to damage and effects. Damage is applied by room, whereas damage effects (fire and breach), are rolled by tile.

I want to see what the modding community as a whole thinks about this.

So, beam behavior: keep, stricly by tile, strictly by room, optional by mod.

I will point out that it will take minimal amounts of work from we, the coders, to implement "optional behavior by mod", but I will forewarn that doing so may decrease the overall quality of the mods due to the extra layer of complexity that potential players may have to learn. Personally, if we do implement the option, I believe the modders should agree on a standard convention with warnings in mods containing exceptions to the rule.

[DryEagle]

I'd prefer all beam effects to be per-tile, that seems to make more sense. If you go across 3 tiles of a room, that should hurt just the same as going across a corner and clipping 3 rooms.

Also, not sure how possible this would be to implement, but how about beam effect based on how much of a room you hit? i.e. if your fire beam goes clean across a tile you would get a guaranteed fire in that tile, but if you just clip the corner of it you'd have 10-20% fire chance or so, based on how much of the room the beam actually covered.

That is to say, if a tile is 35px across, possible to set it so each 3-4px your beam travels across the room adds 10% chance of effect, starting from 0? or 5% if you want the max chance to be 50, etc.

Again yes this would add complexity, but on the other hand, it would be more visually intuitive and make for deeper choices when you go to attack...