Excellent work, although I should've provided you with the actual description for AMMO_REDUCED. An actor must be an entity, so in this case it's "shooter," not the weapon. And the condition-applicable object can be more specifically labeled "weapon" (since it only applies to weapons), same for the target (to be clear it's the weapon itself and not the ammo). The full comments on that trigger: "triggered after a weapon's ammo is decremented due to shooting (also on depleting when it reaches 0); trigger belongs to the *weapon* not the ammo, so it can check either weapons that are their own ammo or those containing an ammo item; often combined with SA_CONDITION_AMMO_COUNT in use; note that this is triggered for *each* shot during burst fire, and is never called for weapons with unlimited ammo"
Oops, yes I meant I_AMMO_COUNT. SA_CONDITION_AMMO_COUNT is its internal name in the source code, so the source comments use the proper internal names. Didn't notice that was in there and might cause confusion when taken out of context.
Post by Aves Dominari on Nov 26, 2013 16:32:50 GMT -5
So, I've run into a roadblock here. I have several 'Ripper' weapons; they fire living creatures instead of bullets and have a chance of spawning minions every time they hit an enemy. That second part is proving to be remarkably difficult, as I keep getting this error message:
F=0010245 | | GM::processSpecialAbilities() | CHNGROCH effect data specifies ability (SPWNROCH) that cannot be found on an item
Here's the SA in question (CHNGROCH just switches the faction that the minions spawn under when you pick the weapon up):
SPWNROCH - PROJ_HIT_OBJECT RANDOM<=10 - - - - SPAWN_ENT - ENTITY=ROCH|NUMBER=1|FACTION=ALIEN|AIR_SPAWN=1|TU=DEPLETE DEFAULT DEFAULT "The ripper turns into a Roach."
The problem is obviously the combination of PROJ_HIT_OBJECT and SPAWN_ENT here, but I've looked through 10101's lists and there doesn't seem to be an alternative combination that would work. My next course of action would be to rip an example from Rookie's Tale, but I don't remember anything like this there either. Any idea what I can do here?
I've always wanted to eventually have a weapon that spawns aliens on contact (you can see one of my old tests in the core SA data, called "Rabbit_Blast_Spawn" where I was playing with spawning rabbits from a projectile ;p). So there shouldn't be any problem with spawning entities from projectiles.
Looking at the error message, it's actually coming from your REMOVE_SA_ITEM trigger, which is trying to remove an item-based SA from a non-item object, which isn't allowed (since the engine knows objects other than items aren't allowed to have item-based SA). So the problem here is you're trying to remove the spawning ability from the original item from somewhere that doesn't have access to the item itself. There's probably one or more ways around this issue, depending on your setup, but maybe what I've told you here can already help you find a new direction to solve it?
Post by Aves Dominari on Nov 27, 2013 17:35:40 GMT -5
I actually managed to figure out a compromise. The clunky SA switching was to make sure that the player-spawned Roaches would be under a friendly AI's control so that the player didn't have to worry about moving them every turn (and couldn't do something like sit in a corner and amass large numbers of Roaches before plowing through the AI). Seeing as it's causing problems, though, I just changed it so that the SA spawns the Roaches underneath the source's faction.
The idea of ensuring they're AI controlled is a good one, and I would definitely prefer that over having to control them manually. If you've changed it to use the source faction, doesn't that mean they'll now be under the player's control when fired? I wonder if you could use a combination of the ITEM_FIRED trigger and E_FACTION condition to dynamically change the item's SA when it's fired, setting it to have one of a set of SA's that have a static faction setting. I believe E_ conditions applied to ITEM_FIRED would refer to the user, so when the weapon is fired it checks the user's faction--if it's X-COM an allied faction-based spawning SA is created on the item, otherwise it creates an alternate alien faction-based version. It of course destroys any previously existing SA first. Just an idea to test out, if you're still unsatisfied with the way it works now.
Excellent, with that I solved it pretty quickly. Apparently your scripts are perfectly fine! Due to some uncareful copy-pasting on my part the game was doing the wrong error check for prop/item-based SA removal, so it was giving you that message and quitting even though it was perfectly valid. Sorry about that! I've uploaded a new pre-release (9.4e) to the private board that corrects the issue (the only difference is the new .exe).