Yes i'd want to look at it basically, quite of what the CSL is mostly my integrating disparate features into a single system, and when i can i try to make things more moddable in the future. I would not want to implement all of what you are doing ( i really want to have separate projects ) but i'd like to have compatibility.
My AI has the same content as the real AI you are used to, so if you use
TalentDragonCombat, i use
SCTalentDragonCombat, and basically i kept all the core AI scripts almost the same names since there is a lot of community content which uses those basic scripts. If you modded any core functions, i'd want to add those modifications to what i am doing, and if i were to implement core improvements to the AI, i'd like for what you are doing to take advantage of it.
As for the turtles, i have an example of a spell called acid spittle which is similar in concept to a breath weapon. This is probably not needed, but the direction i am trying to take the game to make it far more flexible.
In the preliminary i have the following....
int iImpactSEF = VFX_HIT_SPELL_CONJURATION;
int iSaveType = HkGetSaveType( SAVING_THROW_TYPE_ACID );
int iShapeEffect = HkGetShapeEffect( VFX_DUR_MIRV_ACID, SC_SHAPE_MIRV );
int iHitEffect = HkGetHitEffect( VFX_HIT_SPELL_ACID );
int iDamageType = HkGetDamageType( DAMAGE_TYPE_ACID );
The above functions are wrappers, which have knowledge of CSL specific rules, so if for some reason acid damage were magically made to have half range, the visual effect would reflect that, but you mostly are just inputting the defaults. But most of the time it's just doing the defaults passed into the function keeping the overhead low.
Then i implement the above as the following excerpts
// total damage of d8, based on damage type
iDamage = HkGetSaveAdjustedDamage(SAVING_THROW_REFLEX,SAVING_THROW_METHOD_FORHALFDAMAGE,d8(), oTarget, iDC, iSaveType);
// apply an effect based on size, etc so any mods done to the damage or area show up
ApplyEffectAtLocation(DURATION_TYPE_INSTANT, EffectVisualEffect( iShapeEffect ), lImpactLoc);
// apply the damage
effect eDamage = HkEffectDamage(iDamage, iDamageType );
This allows the system to handle varied results for fire breath, like if you are underwater fire does not always even work ( impeded rules ), on other planes fire does double aoe size, extra damage and the like. This also allows people not directly editing your scripts, to modify the effects, so putting a variable on a blueprint would make something that normally does fire damage suddenly do positive damage, so if a "positive" dragon was added to a red dragon, it's breath weapon and ANY spells it casts suddenly do positive damage, are all white flames instead of the regular ones.
Think of the PNP rules which look at Descriptor, Element, subschool, and that sort of thing, with my system the logic is exactly like what you see in the rulebook, while the game actually does it with lots of if/then in each spell or feat which only handle situations the original coder planned on. This should make it simpler for separate systems to work together, and far more flexible -- just imagine if i created a illusion/shades red dragon which is 60% real, it's breath weapon is fire, but it's a illusion, i thus have hooks to easily implement a dragon whose damage is actually an illusion just by putting variables on said creature.
This can be used to implement magic items, new classes ( frost mage for example, imagine an ice dragon with frost mage levels whose breath weapon is treated similar to his other spells ), and anything really you can imagine.
( side effect is you don't have to constantly do new visuals, as the visual is defined by the shape, element and size )
End result though is, a single breath weapon script which handles all dragon types.
Retour en haut
get generic, default Dragons working ) - generalizing these scripts into default AI & global Feats is beyond.
