Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Simulator Enhancements (03/13/24)

Pages: 1 ... 34 35 [36] 37 38 ... 106

Author Topic: [0.97a] Arma Armatura v3.0.5 BETA [2/8/24]  (Read 653916 times)

JUDGE! slowpersun

  • Admiral
  • *****
  • Posts: 614
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #525 on: December 28, 2021, 12:33:48 PM »

Just had a thought...

What if the drone bits (like that for einhandler) carries a strong enough MELEE-range weapon (like the laser blade for aleste) with point defence capability, and give it insane speed and maneuverability while being restricted to a short engagement distance....

Then put it on a melee mech (which doesn't shoot down missiles etc).

will the dancing beam blades chop down incoming stuff like missiles/bullets/fighters?


While we're on topic of the einhandler, I've been wanting to say thig for a while, but I keep forgetting to come here and say it.

I think a shield type drone, much like the mobile dolls in Gundam Wing had, would be a cool alternative as well. 2(+1 as a replacement) floating drones that have a shield in front of them, with it's own flux. It can float around the einhandler, and blocks shots, but has a weakness of EMP damage disabling it or passing right through it.

Mobile Doll Gundam Reference: https://gundam.fandom.com/wiki/OZ-02MD_Virgo

Who says we can only have 1 type of drone? Perhaps make it a swappable component?

Well, in Gundam Wing those are the mass produced version of one of those two test Gundams, the one with 8 shield drones.  But would be cool to have a shield heavy mech... just dunno how to make shields into weapons in game except via ramming (which requires f=ma, so needs lots of A and at least some M).

This one:  https://gundam.fandom.com/wiki/OZ-13MSX2_Mercurius
Logged
I wasn't always a Judge...

sphr

  • Ensign
  • *
  • Posts: 46
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #526 on: December 28, 2021, 08:08:29 PM »

re:shield drones

I don't know enough about modding yet, but how are the shield sizes determined?  Can they be set explicitly regardless of the actual size of the ship hull?

If so it could be interesting to give shield drones omni, large shield radius, small arcs, which will result in a more shield like segment arc, and give it fast shield speed, so that it can raise the shield and turn it fast.  then as long as it is just floating around (or just made to orbit the main ship like some other mech ships), it should activate shield automatically wrt incoming fire? 

but one problem is default shield AI in SS seems to be too efficient and sometimes they won't raise shield unless the incoming fire actually hits it, and with a small hull drone, it might just do nothing (as the fire won't hit it) while the projectile continues on and hit the main ship.... lol.. 

drones on strike...
Logged

JUDGE! slowpersun

  • Admiral
  • *****
  • Posts: 614
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #527 on: December 28, 2021, 11:00:26 PM »

re:shield drones

I don't know enough about modding yet, but how are the shield sizes determined?  Can they be set explicitly regardless of the actual size of the ship hull?

If so it could be interesting to give shield drones omni, large shield radius, small arcs, which will result in a more shield like segment arc, and give it fast shield speed, so that it can raise the shield and turn it fast.  then as long as it is just floating around (or just made to orbit the main ship like some other mech ships), it should activate shield automatically wrt incoming fire? 

but one problem is default shield AI in SS seems to be too efficient and sometimes they won't raise shield unless the incoming fire actually hits it, and with a small hull drone, it might just do nothing (as the fire won't hit it) while the projectile continues on and hit the main ship.... lol.. 

drones on strike...

I had actually more figured drones would be used more like a stretchy lasso, and then drag a shielded mech towards target at high speed (so you get waaaay more A than normal for mech, with shield up should slap).  But if you just want the drones to act more like weapons, could just adapt new code for Tempest drones into a mech... but with shields instead of EMP explosion, I guess.  Just think that with shields instead of explosion, drones will just bounce off like flying cockroaches against a screen door.
Logged
I wasn't always a Judge...

sphr

  • Ensign
  • *
  • Posts: 46
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #528 on: December 28, 2021, 11:24:27 PM »

re:shield drones

I don't know enough about modding yet, but how are the shield sizes determined?  Can they be set explicitly regardless of the actual size of the ship hull?

If so it could be interesting to give shield drones omni, large shield radius, small arcs, which will result in a more shield like segment arc, and give it fast shield speed, so that it can raise the shield and turn it fast.  then as long as it is just floating around (or just made to orbit the main ship like some other mech ships), it should activate shield automatically wrt incoming fire? 

but one problem is default shield AI in SS seems to be too efficient and sometimes they won't raise shield unless the incoming fire actually hits it, and with a small hull drone, it might just do nothing (as the fire won't hit it) while the projectile continues on and hit the main ship.... lol.. 

drones on strike...

I had actually more figured drones would be used more like a stretchy lasso, and then drag a shielded mech towards target at high speed (so you get waaaay more A than normal for mech, with shield up should slap).  But if you just want the drones to act more like weapons, could just adapt new code for Tempest drones into a mech... but with shields instead of EMP explosion, I guess.  Just think that with shields instead of explosion, drones will just bounce off like flying cockroaches against a screen door.

Rather than looking for a particular solution/meta, I am more like exploring ways of potentially making arma mechs look and function more according to

The rule of cool

:)

---
Just wondering, how is the ships (drones are also ships) size (which affects the shield?) vs hitbox (seems like it is auto-determined from the sprite?).  Is the shield size also automatically determined or is it explicitly changeable.

If not, there can always be a "shield-shaped" particle for a PD weapon, but it cannot block against direct-fire weapons, which is a shame.
Unless there is some existing ai-package that can make a fighter sacrifice itself by blocking incoming fire to the owning ship, which will then definitely trigger its own shield.


EDIT:

just tot of another voodoo trick:
The shield drones themselves does nothing but fly around the owning mech.
But while the drones exists, the shield arc and speed (assuming omni) of the mech will be increased.  When the drones do not exists or are too far. the mech will have greatly reduced shields (or even outright none).  Also, to simulate drone dissipating the flux instead of the mech, can just add temporary buff to mech flux capacity/dissipation rate while drones are active.  (though I agree, that would be cooler, if the flux generated by hits on shield is transferred to the drones instead, so they get overloaded instead of the mech, which can still continue to fight, just without shields until the drones recovers)
« Last Edit: December 28, 2021, 11:29:59 PM by sphr »
Logged

Mira Lendin

  • Captain
  • ****
  • Posts: 315
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #529 on: December 28, 2021, 11:46:44 PM »

The Jun Mk.III weapon is a work of art!
Logged
^^

sphr

  • Ensign
  • *
  • Posts: 46
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #530 on: December 29, 2021, 01:04:59 AM »

The Jun Mk.III weapon is a work of art!

I really like it too, both the behavior and the aesthetics/sound.  Found myself replacing compatible weapon slots with it as I find them (still lacking the BP in my current game).
Logged

sphr

  • Ensign
  • *
  • Posts: 46
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021) re: on Mecha Customizability
« Reply #531 on: December 29, 2021, 01:12:25 AM »

re: on Mech Customizability

I think it is every mecha fan's dream.  The goal, is that every (piloted) mech can become as unique as the pilot himself.

While the looks of it is heavily dependent on the shoi's hard labor, I was thinking whether there are other ways that may work without at an easier level.
At least, we can just discuss about it to see if any new/better ideas develop.


So my first vector of attack goes to the hullmods: special hullmods that allows adjustment of the mech (some may be mech specific, so as to keep the design of each mech more consistent, and possibly pave the way to attach visual differences in the future)

Most customization mods should have 0 OP costs, so there is greater freedom in choosing a combination, but each customization mod should have balanced and believable trade-offs:

The fun in customization isn't about adding everything including the kitchen sink, it is about creating something possibly unique.


I've briefly listed down some category/subcategories of ideas for the hullmods.  Please feel free to add on/suggest/generate more ideas.  Maybe it will become interesting/feasible enough to be implemented at some point.

Spoiler
* Category: attachment mods: Basically, this just allows choosing of some attachments (like UWS of the einhandler and drones of others) from some prepared alternatives. Possibly including removing the attachments completely in a design in exchange for some other system bonuses.  Einhandler with melee or shield drones? now you can :)


* Category: system tweak mods:  These usually adds bonus and corresponding penalty on the mech in small ways (less than existing mods costing OP with similar effects)
  Also, each upgrade/downgrade can have a few grades with different "magnitude" instead of just one type, but there should only be at most one type equippable in each sub-category.
  e.g.
  - engine/booster tweaks:
   -- upgrade: +topspeed, -maneuverability, -flux
   -- downgrade: -topspeed, +maneuverability, +flux
   -- prototypes: ++topspeed but may other special penalties in addition to the usual ones above


  - generator tweaks: this one is hard.  on one hand, I think it should allow more powerful weapons to be installed (+OP) and to be able to use weapons longer (+flux), it SHOULD generate more heat as a result (-flux).  Maybe a more correct model is to view flux capacity as an inversed "battery" (battery is full when flux is at 0) while flux dissipation rate is really "energy generation" rate. But generator require "fuel", which is not actually used in-game, so I think it may be modeled by CR%.
   -- upgrade (power hungry, runs out of juice faster):   +OP, +flux dissipation (energy generation), -PPT with increased CR% decay rate afterwards, +supply usage, -CR% recovery
   -- downgrade (efficient, lasts longer): -OP, -flux dissipation (energy generation), +PPT with reduced CR% decay rate afterwards, -supply usage, +CR% recovery
   -- prototypes: ++ OP, ++flux dissipation etc but have chance of special malfunctions?


  - armor tweak
   -- upgrade (increase mass): -topspeed. -maneuverability, + supply usage, -CR% recovery
   -- downgrade (decrease mass): +topspeed. +maneuverability, - supply usage, +CR% recovery


  - power diversion (re-distribute power without changing production, i.e. flux)
   -- power to weapons: +OP, -shield efficiency/arc/speed, -phase stuff (not familiar with this)
   -- power to shields/phase: -OP, +shield efficiency/arc/speed, +phase stuff
   -- power to systems: -OP, -shield/phase, +system CD/effects/range


  - flux(energy) tweaks : trade off between capacity and efficiency

  - shield/phase tweaks : trade off between shield/phase duration/efficiency vs flux capacity/rate

  - others?



* Category: pilot mods:  These usually enhances the capabilities of the mech, at the expense of greater demands on the pilot.  Unlike trade-off mods above, these will usually either provide only bonus if IF conditions are met, or provide only penalties if not (with possibly some special cases having in-between grades based on multiple levels of conditions).  They may not seem "balanced" in the overall campaign. But isn't that the intent? These are aces, heroes, legends, and the kind of MC you see in mecha films/animes ;)


  - general pilot mods - which adds some small bonus as long as the ship is captained but penalties otherwise. It is sort of balanced at campaign level by the actual number (and limit) of captains hired and salary paid.  Adding them to every ship is not good as those without captains will actually perform worse.  But the bonus should be minimal in magnitude (esp since pilots already comes with skills)


  - specialized pilot (skill) mods - In addition to just being piloted, these mods requires that the captain has a special skill (differentiate between normal and elite, with those requiring elite skills having greater bonus/penalties).  iow, bonus if the pilot has the skill, penalty if not.  The bonus provided by this mod should match the skill required, and usually change the mech enough that its role on the battlefield becomes completely different. The total number of this category of mods on a single mech at the same time should be limited though, to differentiate them from the next sub-category.


  - legendary pilot mods -  Not in legendary as a rarity/uniqueness qualifier, but rather (in my pursue of immersion), the mod was originally (pseudo lore-wise) built for a specific legendary  ace pilot.  In addition to possibly require a specific hull-type or ship equipment/stats, it will have multiple skill requirements (some elite) such that only a pilot that satisfy all requirements will be able to utilize the full power provided by the mod (bonus should be greater than any similar combinations of specialized pilot mods in prev category), in effect making such cases rare enough to be called unique (usually).

    if ship conditions are not met, it cannot even be installed.

    If pilot skill requirements are not net, there may be severe penalties that makes adding the mod much worse than not doing so
   
    There can be multiple "lesser" levels of conditions where a pilot partially fulfilling the full requirements will get a mixed of bonus/penalties. 

    While the original mod(mech) is designed and built around a single legendary pilot, people who want to utilize this mod in "present day" may have to raise/train a pilot specifically to meet the strict requirements (unless a pilot can be found that naturally meets all requirement, in which case it is destiny).

    Of course, only one of such mod can be installed in a mech at one time.

    Just for fun lore-wise, every legendary mod can be named after the callsign/mech/name of the ace pilot it was supposedly built for (+ stories/accounts of famous accomplishments in the modified mech) which highlights the ability of the mod.  If there are ever plans to implement this idea, we can even set up a brainstorming session for people to submit their designs along with back story and pick the most interesting ones.
[close]




Logged

hydremajor

  • Captain
  • ****
  • Posts: 461
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #532 on: December 29, 2021, 02:44:02 AM »

@sphr

I see your customisation post and raise you a "strike pack" suggestion

Think of it as such

A mech gains access to strike packs

Strike packs are sets of equipements built to pertain to certain roles

Lets say we have 3 Strike packs:

Fighter, Interceptor, Bomber

Each pack comes with different weapons built into the mech itself, further each pack enables the use of different hand-held weapons

Next make it so each Pack sees itself given three options for handheld weapons, each themed around a weapon type/damage type

For Bombers in our example

the Body itself has built in micro missiles for self defense while the arms can pack either,
A magnet bomb bay (think magnetized mines that pull themselves to the target)
A anti-matter blaster
A long range Hellbore-esque cannon

see where I'm going with this ?

EDIT/Continuation:

Basically each mech using this would have multiple "tech trees", the question wich tech should such a mech be ?
« Last Edit: December 29, 2021, 04:29:16 AM by hydremajor »
Logged

sphr

  • Ensign
  • *
  • Posts: 46
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #533 on: December 29, 2021, 04:39:49 AM »

@sphr

I see your customisation post and raise you a "strike pack" suggestion

Think of it as such

A mech gains access to strike packs

Strike packs are sets of equipements built to pertain to certain roles

Lets say we have 3 Strike packs:

Fighter, Interceptor, Bomber

Each pack comes with different weapons built into the mech itself, further each pack enables the use of different hand-held weapons

Next make it so each Pack sees itself given three options for handheld weapons, each themed around a weapon type/damage type

For Bombers in our example

the Body itself has built in micro missiles for self defense while the arms can pack either,
A magnet bomb bay (think magnetized mines that pull themselves to the target)
A anti-matter blaster
A long range Hellbore-esque cannon

see where I'm going with this ?

Just to explore this further.
Wouldn't it be better if roles like fighter/interceptor/bomber is not determined by pack but designed by choosing the mods?
iow, all the options in the strike packs are taken out by themselves, and allowed to be chosen across the board, so that appropriate parts can be chosen for each "system point".

for Interceptor that perhaps value speed over power or endurance (e.g. during pursuits), take decreased armor, upgraded booster, and select weapons that are good at catching/disabling fast enemies
for Bombers, perhaps take increased armor, booster, reduced CR + speed+ agility and perhaps a generator so that larger/more powerful weapons (OP wise) can be mounted, since their targets are usually slower and larger crafts
for Support, perhaps drop power/speed/armor for extended periods of operation and give them super long range weapons to try to stay out of enemy fire.
for Fighters, perhaps being balanced and able to "hold the line" , so average in most aspects

In the future, all these mods can perhaps corresponds to actual visual parts using armaa's current system which can provide even better immersion (e.g. instead of arbitary mods, each mod is represented by an inbuilt part, but we can say have left pauldron which supposedly houses an upgraded generator, and right pauldron which contains the internal systems to support a more powerful propulsion), or we can choose two of the same system type for a more skewed design.

iow, I was hoping that the roles can be designed by every player even using the same (mech) platform, instead of being distributed as "packs".   but of course, practically, any kind of customization systems that gives more options is welcome as it will definitely improve things so even packs are good :)

Logged

Space_Lettuce_OG

  • Ensign
  • *
  • Posts: 45
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #534 on: December 29, 2021, 06:26:11 AM »

Yes, the personal design aspect of ships in StarSector are what makes the game a brilliant gem, near infinitely replayable(while still feeling fresh), and so fun.

Removing this aspect would only detract from the fun, in my opinion.
Logged

JUDGE! slowpersun

  • Admiral
  • *****
  • Posts: 614
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #535 on: December 29, 2021, 10:34:48 AM »

Yes, the personal design aspect of ships in StarSector are what makes the game a brilliant gem, near infinitely replayable(while still feeling fresh), and so fun.

Removing this aspect would only detract from the fun, in my opinion.

I mean, it is still limited by hard point type to limit which types of weapons go where.  But yeah, I agree, please don't drop this!
Logged
I wasn't always a Judge...

sphr

  • Ensign
  • *
  • Posts: 46
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #536 on: December 29, 2021, 10:11:21 PM »

Yes, the personal design aspect of ships in StarSector are what makes the game a brilliant gem, near infinitely replayable(while still feeling fresh), and so fun.

Removing this aspect would only detract from the fun, in my opinion.

I mean, it is still limited by hard point type to limit which types of weapons go where.  But yeah, I agree, please don't drop this!

I am only speculating, but I think the only reason some of the current systems restricts the hardpoints is because mech sprites requires special handling.  if the hardpoints can mount regular weapons, it will look very strange unless there are appropriate replacement sprites that can be hacked into replacing it (maybe making original weapon invisible? not even sure whether that is possible). But EVEN so, there is need to prepare replacement sprites that matches the weapon/fire.   now, recall the number of types of weapons and how varied their behavior animation is....

which is why atm, it is easier to just restrict stuff, often with little or no choice (e.g. einhander).  in some cases where the original weapon sprites looks ok, it can still be made generic so anything that fits can go in (e.g. aleste(s) back mounted turrets).

But I am personally hoping that as mod gets developed, there will be more mech-specific options (e.g. like aleste(s) arms options) or even some more general way that can allow use of common weapons (but with a general means of replacing the looks/animation) that doesn't look out of place on a mech.

between use of common weapons vs the looks of mechs, I will prob choose the latter :)  If I just wanted more weapons, I'll find some ship mods with a gazillion weapon mount points...

EDIT:
tl;dr: I wanted a customizable mech, but I don't want to change it so much that it no longer looked like a mech.
« Last Edit: December 29, 2021, 10:13:07 PM by sphr »
Logged

sphr

  • Ensign
  • *
  • Posts: 46
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021) (idea)Versatile Platform Framework
« Reply #537 on: December 30, 2021, 01:54:49 AM »

tl;dr: Idea (pseudo-technical proposal) for framework/system for mech customization, potentially feasible
---
EDIT:
Upon closer investigation, the original method may not work due to the way the game engine works with creating a modified ship.  Added a backup method (original method still listed) which I was hoping not to use due to the need of global storage (probably done using in-game method of storing save-game persistent data if there is no better way)


---

Versatile Platform Framework
(borrowed from Aleste(S))

goals:
- to allow easy selection of custom parts (as opposed to cycling which can be hard to work with if number of parts increased)
- to allow easy addition of new compatible parts (no need to change code. Just add weapon + selector hullmod. Can be added by separate mods and will work together)
- to allow easy propagation to new mech hulls (just define the hullmod built-in with corresponding weapon slots, and it will gain access to all compatible parts)
- to allow flexible means of restricting part selection for technical/game-balance/immersion reasons.


Basic operation
Basically exploiting the hullmod system, using the approach used by Aleste(S) atm (which allows switching of left/right arm devices)
Note: may not work due to how the game engine creates the ship wrt optional parts

Spoiler

Original method:
- framework basically consists of 2 parts:
  + a ModuleInterface, which is a hullmod that manages a single customizable point
  + a PluginModule, which is a hullmod that can "plugin" a weapon/part to a compatible ModuleInterface (the weapon/part is assumed to be available and outside scope of this framework)

- ModuleInterface:
  + implemented as a hullmod not available to other ships
  + must be is declared as a built-in mod into the hull-types only. 
  + must be associated with one or more weapon slots which the hull must define.
  + must be associated with default weapon/parts which the hull can define as built-in (if not, it will be installed automatically)
  + implements applyEffectsBeforeShipCreation(), where it will check if the managed weapon slot contains the default part or null (in which case it installs the default part). If so, it will search and an associated InterfaceCustomized hullmod (which indicates whether the interface is already customized to block other customizations)

- a PluginModule is implemented as a hullmod
  + must define method isApplicableToShip(), such that it can only be installed on a ship with compatible ModuleInterface hullmod and not have the associated built-in (not removable) InterfaceCustomized hullmod.
  + in applyEffectsBeforeShipCreation, it will change the part on the managed weapon slot to the one it indicates, and adds the associated InterfaceCustomized if it is not already added


Backup method:

This method is actually more robust, but requires persistent storage, which I was hoping to avoid.


- framework basically consists of 3 parts:

- a global plugin registry, which is a map of plugin interface ids to a collection of pluginmodules ids.
  The purpose is to allow the scripts to lookup and identify at runtime which plugins can go into the interface.  This is required if the plugins/interfaces are are not added by one mod.

- ModuleInterface (modified from original)
  + (unchanged) implemented as a hullmod
  + (unchanged) declared as built-in
  + (unchanged) associated with specific weapon slot
  + (unchanged) associated with specific default part
  + (changed) implements applyEffectsBeforeShipCreation() where it will get the complete list of compatible plugins from global registry, then checks if any plugins-hullmods are installed.
    + if a plugin hullmod is installed, it will do nothing, except to unsure that the corresponding InterfaceCustomized  hullmod is added if it is not yet done so.
    + if plugin not installed, it will restore the default part to the managed weapon slot, and remove the corresponding InterfaceCustomized  hullmod (alternatively, if InterfaceCustomized method not used, no further processing required)

- a PluginModule is implemented as a hullmod
  + (addded) at earliest opportunity (including being called by other methods below as last resort), registers its id with the global registry, under the corresponding interface hullmod (maybe in the constructor of the hullmod class if applicable)
  + (unchanged) implemented as hullmod
  + (unchanged) overrides isApplicableToShip() such that it can only be installed if the compatible ModuleInterface hullmod exists, but not the corresponding InterfaceCustomized hullmod. (alternatively, if InterfaceCustomized method is not used, it needs to get the list of competing plugins from global registry and make sure none is installed other than itself)
  + (unchanged) overrides applyEffectsBeforeShipCreation(), change parts, add corresponding InterfaceCustmoized hullmod if not already added

[close]


Example
---
EDIT: the example is not applicable to the backup method.
---
How the thing should work in a simple example(in theory at least)
(Note: some understanding of the modding system may be required)

Spoiler
For example, let is create a new pilotable Aleste(V) similar to Aleste(S) using the new system.
It will have the exact same number of combinations, just that it may be easier to select the parts (and in future expand the list of compatible parts).
In addition, the system allows parts to be fitted to different shiphulls, as long as they declare the same ModuleInterface and weapon slots.


Some declarations (assumed to be implemented correspondingly):

There are 2 customizable points on Aleste(V), left arm and right arm.

key:
- hmod:{modname} - hullmod
- wslot:{id} - weapon slot
- wp:{id} - weapon


declare the following interfaces and plugins (managed part)


- hmod:VMI_AlesteVLArm - for left arm (associated with wslot:A_ARML with default built-in wp:armaa_alesteLeftArm) and associated hmod:VMC_AlesteVLArm to indicate slot is customized
  + hmod:VMP_AlesteVLArm_Grenade (wp:armaa_aleste_grenade_left)
  + hmod:VMP_AlesteVLArm_Blade (wp:armaa_aleste_blade_left)

- hmod:VMI_AlesteVRArm - for right arm (associated with wslot:A_ARMR with default built-in wp:armaa_alesteRightArm)  and associated hmod:VMC_AlesteVLArm to indicate slot is customized
  + hmod:VMP_AlesteVRArm_HvyRifle (wp:armaa_aleste_rifle_right)
  + hmod:VMP_AlesteVRArm_Minigun (wp:armaa_aleste_minigun_right)


Lets say we have the basic platform with the following built-in hullmods

- hmod:VMI_AlesteVLArm
- hmod:VMI_AlesteVRArm


----------

Refit session #1

Spoiler
applyEffectsBeforeShipCreation:
- starts from basic variant defined in ship hull
- hmod:VMI_AlesteVLArm will check that wslot:A_ARML contains defined default part (wp:armaa_alesteLeftArm) or null (in which case it can install the default part?) and remove any hmod:VMC_AlesteVLArm if it exists
- similar for hmod:VMI_AlesteVRArm

refit screen:
- we should see the mech with default parts wp:armaa_alesteLeftArm and wp:armaa_alesteRightArm installed
- we should see all the 4 plugins mentioned eariler available to install (ignoring OP cost)

action:
- supposed we choose hmod:VMP_AlesteVLArm_Grenade

[close]
----------

Refit session #2
Spoiler
applyEffectsBeforeShipCreation:
- starts from basic variant defined in ship hull
- hmod:VMI_AlesteVRArm no changes
- hmod:VMI_AlesteVLArm will check that wslot:A_ARML contains default part or null, in which case it will remove any hmod:VMC_AlesteVLArm if it exists. it will not do anything otherwise.
- hmod:VMP_AlesteVLArm_Grenade will change wslot:A_ARML part to wp:armaa_aleste_grenade_left and adds hmod:VMC_AlesteVLArm if it does not exist

(note that even if order of application is flipped for last 2 lines, end result should still be the same)


refit screen:
- we can no longer see hmod:VMP_AlesteVLArm_Blade applicable (due to the hmod:VMC_AlesteVLArm present)
- the plugins for right arm is unaffected


action:
- supposed we remove the selected hmod:VMI_AlesteVLArm_Grenade
[close]
----------

Refit session #3
Spoiler
applyEffectsBeforeShipCreation:
- starts from basic variant defined in ship hull
- hmod:VMI_AlesteVRArm no effects
- hmod:VMI_AlesteVLArm will check that wslot:A_ARML contains default weapon (which should be true, because we start from base hull), it will then remove hmod:VMC_AlesteVLArm


refit screen:
- we can see all parts for left arm available again, because hmod:VMC_AlesteVLArm is removed.
[close]

---


So by making system manages each ModuleInterface independently, we can easily scale up and allow more "interfaces" to be customized easily.
While parts with functions may require specific handling/scripting by the dev developer etc, cosmetic parts or (parts with little change to behavior, just adjusts magnitude) can easily be created by sub-mods once the basic hull set-up and Interface-Plugin system is designed by the developer.

for immersion, I think the interfaces should be given industrial designations.  e.g. SATA3.5 or USB 3.0 (lol). So all the interfaces can be traced to a particular model/standard within the AA industries/techonologies to create a complex modular system for mech parts (instead of just being able to install anything anywhere)

[close]


Backward/multi compatibility
Plugins can be made compatible with more than one interface type
Spoiler
Requirements:
- define appropriately in isApplicableToShip() to check for multiple ModuleInterface hullmods AND their associated InterfaceCustomized hullmods
- in applyEffectsBeforeShipCreation(), it must add the CORRECT type of InterfaceCustomized (must check the ship to see which type of ModuleInterface it has)
- optional: in applyEffectsBeforeShipCreation(), the performance may be modified according to the type of interface. (e.g. you can plugin a USB 3.0 device to a USB 2.0 interface, but don't expect the full performance the device is capable of)
- this can create the immersion that some advanced parts can still be used on older mech designs, but may suffer some performance issues.
[close]

Adapters
(roughly idea atm, haven't worked out the exact system to know whether it will work)
Spoiler
Have a micro-usb plug but only a regular USB interface?
ah hem.. I mean
Have an advanced Einhander arm that doesn't go into an Aleste arm socket?

Adapter hullmods are special mods (never built-in) which can be applied to a mech to convert the interface type to another:
- like a regular plugin mod, it adds the InterfaceCustomized mod and changes the weapon slot to the default weapon of the new interface (to block parts using original interface from being installable)
- adds the new interface hullmod which allows its compatible parts to  be installed
- may carry extra cost (e.g. OP) (because adapters are never as good as being built-for)
- but it will allow your old Aleste to equip the new Einhander parts on the adapted interface
[close]



And at the end of the day, what I hope to see, is a framework that allows highly customizable mechs (using the fixed parts system in armaa), that have parts that can be easily extended  by the mod developer, and possibly expanded even more by the community, and all the options easily available to a single player (want blue parts? just install a sub-mod that add blue versions of the base parts)

---
EDIT: added backup method if original method doesn't work due to different way game-engine behaves from original expectation
« Last Edit: December 30, 2021, 06:39:22 PM by sphr »
Logged

hydremajor

  • Captain
  • ****
  • Posts: 461
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #538 on: December 30, 2021, 05:09:37 AM »

Meanwhile a more "reasonable" alternative I propose here is a third built in hullmod to change the backpack on the mech

each backpack applying multipliers on both mobility stats and flux related stats

Heavy pack improves Flux stats but lowers mobility

Light pack ups mobility at the cost of Flux...

Edit:
Another point in favor of that is that it can be a purely statistical change and not have to add in sprites.

This in turn allows that to be retrofitted onto the older mechs with some amount of ease....
« Last Edit: December 30, 2021, 05:35:20 AM by hydremajor »
Logged

Space_Lettuce_OG

  • Ensign
  • *
  • Posts: 45
    • View Profile
Re: [0.95a] Arma Armatura 1.5.2e (9/16/2021)
« Reply #539 on: December 30, 2021, 06:50:59 AM »

Meanwhile a more "reasonable" alternative I propose here is a third built in hullmod to change the backpack on the mech

each backpack applying multipliers on both mobility stats and flux related stats

Heavy pack improves Flux stats but lowers mobility

Light pack ups mobility at the cost of Flux...

Edit:
Another point in favor of that is that it can be a purely statistical change and not have to add in sprites.

This in turn allows that to be retrofitted onto the older mechs with some amount of ease....

You lose a great deal of customizability with this method. That's why I, and I'd imagine many others, would not be in favor of it.
Logged
Pages: 1 ... 34 35 [36] 37 38 ... 106