|
Post by strangeguy on May 21, 2013 7:45:01 GMT -5
I'm working on a mech whose weapon can overheat, draining all TU as it shuts down to cool down. However I'm having a bit of a problem- the only trigger that works for it (or at least I see) is PROJ_HIT_ENT2 which means no chance of overheat if missing. Also it is a burst and it triggers for every entity hit, though that will be less of a problem when I make it actually random, currently guarenteed for testing purposes.
|
|
|
Post by Kyzrati on May 21, 2013 8:17:52 GMT -5
Yep, you're right, the closest thing would be PROJ_HIT_ENT2, but it doesn't really do the job since it's not intended for that. I looked down my list of "yet-to-implement" triggers and see an ITEM_FIRED. I'll go ahead and add that now and release a 9.2 update for you. There will be two versions: ITEM_FIRED for targeting the item itself (meltdowns, malfunctioning and the like), and ITEM_FIRED2 for affecting the user. Optional data will include a condition for whether the shot missed, as well as specification of the applicable firing modes.
|
|
|
Post by Kyzrati on May 21, 2013 10:29:04 GMT -5
I've uploaded R9.2 here, but haven't launched it officially yet, so check it out and get back to me on whether or not it works as you'd like and if there aren't any problems I'll update the download link on the site. I tested it out and I'm pretty sure it should do what you want, though I didn't implement the miss/hit variable I referred to earlier since there would be too many exceptional situations--it'll always trigger after firing as long as all normal conditions are met. ITEM_FIRED targets the item, ITEM_FIRED2 targets the entity that fired it. By default it will apply to all firing modes unless you restrict it with the ATTACK_MODE condition. Possible values are MELEE, SNAP, BURST, and AIMED. (Ex: ATTACK_MODE==BURST would only apply it in burst mode, so you could create several versions for different modes, or have it apply in all modes except SNAP (!=SNAP), etc...)
|
|
|
Post by strangeguy on May 21, 2013 11:24:21 GMT -5
Getting a fatal error with 9.2. Run log gives me: F=0004185 | | Particle3D::loadParticles() | Incorrect particle data count in line 5 But I'm using identical Particle3D to with 9.1 and that worked fine. The specific line it refers to is part of the lightning I copypasted from I think Rookies Tale.
|
|
|
Post by 10101 on May 21, 2013 12:56:24 GMT -5
There could be several reasons. One is that between your version of Rookies Tale and your mod is a difference in datacount due to version updates. Another one could be that you missed something (a single '-' might be enough) as you copied the data.
I tested this one with my own mod, and it works with 9.1
Lightning_Glow GEN CONST 200 0 STATIC - - - 0 NONE - - 0 +ALPHA white 0.5 SINE- - NONE - - - - NONE - - - - NONE - - - - - - - - - - - - - - - - - - - - - - Lightning_Glow_E GEN CONST 70 0 CONST 20 0 0 1 NONE - - 0 NONE - - - - NONE - - - - NONE - - - - NONE - - - - Lightning_Glow ENTER - 0 -2 0 - - - IMM - - 0 - - - - - Lightning_Core GEN CONST 500 0 STATIC - - - 0 A_SYM - 50 1 SET yellow_2 - - - +ALPHA yellow_5 1.0 SINE- - SET black - - - +ALPHA yellow_5 1.0 SINE- - - - - - - - - - - - - - - - - - - - Lightning_Fork GEN CONST 70 0 CONST 20 0 0 1 NONE - - 0 NONE - - - - NONE - - - - NONE - - - - NONE - - - - Lightning_Glow_E ENTER - 0 -8 0 - - - R_XY - - 1 - - - - - + Lightning_Core ENTER - 0 1 0 - - - IMM - - 0 Lightning PRO INF 0 0 CONST 20 0 0 1 NONE - - 0 NONE - - - - NONE - - - - NONE - - - - NONE - - - - Lightning_Glow_E ENTER - 0 -8 0 - - - R_XY - - 1 - - - - - + Lightning_Core ENTER - 0 1 0 - - - IMM - - 0 + Lightning_Fork ENTER - 30 -2 0 - - - R_XY - - 1
|
|
|
Post by strangeguy on May 21, 2013 17:26:14 GMT -5
Had a closer look at it seems like particles have changed, adding a couple of columns. Wasn't mentioned in the changelog or Kyzrati's description of 9.2 (unless I'm missing one somewhere). Might take me a little time to get that in order.
|
|
|
Post by Kyzrati on May 21, 2013 19:24:08 GMT -5
Damn, yeah, I forgot to mention the changes I made to the system earlier (since I didn't plan on doing a 9.2 release). The modpack changelog is already updated with the new stuff, so I guess I'll throw that up now and make it official.
I'll update the modpack to M7 soon. You won't really need the modpack itself, just knowledge of the few columns I added, which you've probably seen already. The relevant changes were these: * [particles3D.xt] Children > Count > Num randomized values are now 1-based (e.g., "-3" chooses from 1~3, not 0~3) * [particles3D.xt] Children > Conditions > "Rate" renamed to EFactor, added Rate and RFactor columns to support variable spawn rates * [particles3D.xt] Added Sounds > EFactor column to support new DELAY event
You should probably ignore the first one, though it may affect the appearance of a few particles. The new columns mentioned, which you can see in the data in R9.2, are all blank ('-'), since they add support for optional new features 10101 and I were talking about earlier, and some other stuff I thought of.
|
|
|
Post by 10101 on May 21, 2013 23:41:28 GMT -5
Would ITEM_FIRED / ITEM_FIRED2 be activated through PROJ_SHOOT / PROJ_RAIN ?
Could be THE opportunity for alternate firemodes.
|
|
|
Post by Kyzrati on May 22, 2013 0:00:07 GMT -5
Hm, that's a pretty good idea. At first I didn't even quite get how that would equate to alternate firing modes, but now I see how that could be used for all sorts of things, assuming you attached to it whatever TU conditions and other requirements were necessary. I'll add that to the list for future consideration.
|
|
|
Post by strangeguy on Jun 6, 2013 10:40:40 GMT -5
I've been thinking of letting the player man the mounted guns I added last Union update (if you haven't played it there's a mounted MG prop in the wall space with an immobile machine gun equipped entity behind) but I've ran into a bit of a problem. I used the same names but different tags for when infantry are actually on it, but conditions for special abilities seem to only to work with names. I can change the names, but it's not ideal.
Also I'm using the TU=DEFAULT setting for the mutating, but it seems to restore all TUs instead of keeping them the same
EDIT: Another thing I wanted add was a prototype plasma weapon for infantry, which could overheat but whose wielders have a specially protective armour (that's inferior against everything else). Unfortunately material damage modifiers don't seem to work against special ability inflicted damage. I can still give it good protection but have all non-heat weaponry deal bonus damage but that isn't what I really wanted.
|
|
|
Post by Kyzrati on Jun 6, 2013 11:48:19 GMT -5
It's possible I forgot to convert all the name checks to tag checks since tags were added pretty late in development. I'll look into both of these issues tomorrow because it's *really* late here now... (I guess it was worth it since I finally got to add some cool new features, including particle-controlled animation support for items and props.)
|
|
|
Post by Kyzrati on Jun 7, 2013 1:49:36 GMT -5
For the first issue, I see that I left in the E_NAME condition in case it's still needed for some purpose, but back when tags were added I created a new "E_TAG" that you can use in place of E_NAME. Try using that instead.
I apparently forgot to implement TU=DEFAULT for MUTATE effects. Fixed for the next release.
As for the last issue, how are you trying to do it that it's not working? A MOD_ENT effect using STAT=HP|OPERATOR=SUB should pass the damage through their armor filter so long as you don't have IGNORE_ARMOR=1. Another way to do it would be simply check the wielder's armor type with the E_ARMOR_NAME condition and apply the damage only if they're not wearing the expected armor.
|
|
|
Post by strangeguy on Jun 7, 2013 4:54:06 GMT -5
I did try using E_TAG but at the moment I have it all stuck on one special ability and I only changed one to E_TAG, meaning the name one triggered first and apparently I've set it up so only one can go. Works fine now all are E_TAG, thanks.
A MOD_ENT like that is exactly what I'm using. I've tried massively increasing or decreasing the armours materials value for that damage and it doesn't change how it hurts. Having it check their armour is a good idea though, I might just do that.
|
|
|
Post by Kyzrati on Jun 7, 2013 8:05:30 GMT -5
Wow, on closer inspection I realize you found an oversight on my part. I see I wrote a special function for handling SA-sourced damage that passes it along to another function which I thought was handling material-based modifiers, but it turns out those are normally applied immediately when an object is hit by a projectile, so SA were not checking their damage against the material after all. I'll have to add it in (will affect/fix DAMAGE_CELL, DAMAGE_PROP, and MOD_ENT HP subtraction). For now the armor check solution should work in your case, though.
|
|
|
Post by strangeguy on Jun 18, 2013 19:47:39 GMT -5
I've been back trying to get mounting/dismounting MGs to work, but ran into something of a problem. I need to change the prop and the entity between mounted/dismounted states, one of which needs PROP_MANIP and the other PROP_MANIP2. Putting both on doesn't seem to work.
|
|