|
Post by Kyzrati on Jul 19, 2013 16:23:54 GMT -5
Okay, thanks for the notice. Sorry about that.
|
|
|
Post by strangeguy on Jul 25, 2013 13:52:16 GMT -5
I wanted to add someone new who could use an existing weapon a bit more efficiently, so giving them a slighter different weapon with same name that changes when dropped or picked up so you can't use it on anyone else. Unfortunately it crashes if it is loaded when it changes. Probably just destroy it when dropped, I was even thinking of doing that at first, but you might want to know if you don't already.
|
|
|
Post by Kyzrati on Jul 25, 2013 16:34:21 GMT -5
Thanks for the notice, I could fix that fairly easily, though it would help if I could see the SA script and data for the items involved. Sometimes the cause of a problem ends up being something other than what may seem obvious. Looking at the source, the only issue I can currently see with an ammo transfer is if a loaded weapon is converted to another which tries to provide *another* ammo item that is *also* compatible with the same weapon. In this case the old ammo will be kept, but it will also try to load the new ammo. That might be causing a problem (if so there may be a message in the run.log mentioning where things went wrong).
|
|
|
Post by strangeguy on Jul 25, 2013 16:42:38 GMT -5
Looks like it using the same ammo was the problem. After deciding to just go with destroy I'd changed things so they had to reload less often as well as other advantages, and trying out converting now it works fine. With it being more different I think I'll stick with destroying.
|
|
|
Post by Kyzrati on Jul 25, 2013 16:48:21 GMT -5
Excellent, good to know. In any case, I'll add a check to make sure that old ammo is destroyed if a new one of the same type is being added manually.
|
|
|
Post by Kyzrati on Jul 25, 2013 17:54:22 GMT -5
For completeness sake, I just looked into this further and discovered it wasn't so obvious (of course): The cause had nothing to due with ammo compatibility, which was already properly checked, and was instead a problem with how *any* kind of ammo was being transferred. Ammo wasn't being cleanly removed from the original item, so it looks like CONVERT_ITEM was completely broken when attempting to use manual ammo. Fixed for next update.
|
|
|
Post by 10101 on Jul 26, 2013 4:33:42 GMT -5
I somewhat miss the SA 'MELEE_HIT_PROP2 and MELEE_HIT_CELL2 (something like MELEE_HIT2 triggering on any hit, no matter what the target is, might be better).
It's something to make bad things happen, when silly things are done. For example if you hit an entity in melee with an impact grenade the grenade explodes (and needs to be removed in the process, but E_HELD_ITEM_CONSUME=="xyz" causes an crash, when used with MELEE_HIT_PROP etc.)
|
|
|
Post by Kyzrati on Jul 26, 2013 6:16:46 GMT -5
For grenades in particular you can also set the type to VOLAT, which does exactly what you're describing: explode when you strike someone with it in melee. (Of course it comes with the other properties of volatility, like explosion when dropped/falling.) Trying that through SA is somewhat difficult.
The intended idea of IMPACT grenades is that they essentially arm instantly when thrown with the intention of detonation, not when striking something with them, which doesn't arm them. (Another way to look at it is they are so easily and quickly primed it costs 0 TU.)
However, these statements are somewhat beside the point since I'm only responding to a specific example of what you're indicating. I've added your suggestions to the growing list of improvements the system will need to eventually consider. Expanded features will be better done all at once, or at least in large chunks, later on.
|
|
|
Post by 10101 on Jul 26, 2013 7:19:13 GMT -5
VOLAT is a littlebit too much of it, as it also explodes when the carrier is hit and the grenade is in the belt.
As another example think of a bottle filled with an magical potion that is used as a melee weapon. After hitting the enemy/prop/cell the bottle is broken and the potion gone, but a lot of strange things might happen as the potion spills all over the place.
Or in general things that get destroyed, when abused as melee weapon (not only against entities).
Or that iron crowbar hitting an generator or whatever is filled with electricity (shocking news for the attacker).
Priority might be low as most of the time it is of interest only, if someone does something silly people normally wouldn't do.
|
|
|
Post by Kyzrati on Jul 26, 2013 8:06:28 GMT -5
Mmmmm, yes, those are some pretty fun ideas. Will definitely have to add those triggers. So, so many triggers...
|
|
|
Post by strangeguy on Jul 29, 2013 17:34:59 GMT -5
One minor thing I discovered back when I was doing that and I've realised I should have mentioned- ITEM_FELL applies when dropped on death but not if dropped while living. As it's an AI unit for me not particularly important (though panic could still be an issue) but in other cases it might be good to have it trigger then. Maybe an option as you might want it to behave like now, though I'm struggling to think of any circumstances.
|
|
|
Post by Kyzrati on Jul 29, 2013 18:00:42 GMT -5
That was intentional. The game defines "falling" as an uncontrolled drop, so it would only apply when a held item falls to the ground on death. While alive, although "drop" is the name of the action, I've assumed that if you've got something that is dangerous to drop and you're standing on the ground then what you really do is "place" it on the ground. ITEM_FELL will still apply if you are, for example, flying and "drop" the item from mid-air, or if the floor under the item gives way and it falls to the level below, etc. It also applies if you're knocked unconscious, since that would be uncontrolled.
The original idea behind that particular trigger was to handle volatile items, not deal with items being simply placed on ground. Sounds like what you're referring to here would be another trigger.
EDIT: I like the idea of a new trigger like ITEM_DROP/ITEM_PLACED, which would enable things like deployable turrets.
|
|
|
Post by strangeguy on Aug 2, 2013 18:06:28 GMT -5
I've been using a map-wide invisible explosion caused by an extra-tough enemies, hits an always spawned normally useless invisible prop and spawn some reinforcements. Easy enough and works fine, but I wanted it to be delayed a bit, if just so you can make some room, so I gave the prop a special ability by the explosion which then spawns.
It doesn't work, I can't get the ability on the prop to trigger even with a plain PROP_NEW_ROUND and causing an explosion in case something was wrong with the spawn rather than trigger.
|
|
|
Post by Kyzrati on Aug 2, 2013 23:08:53 GMT -5
Good catch, I see that's an oversight on my part. The game stores all prop-based, turn-triggered abilities in a special place so they can be activated properly, but I forgot to add the prop to the list if you use *another* SA to add the applicable turn-based SA to the prop. So right now this particular case you've found won't actually trigger...
I'll fix that, but until then another way to make it work is to split your special receptor prop into *two* different props, the first is responsible for receiving the explosion, which converts it into the second, and the second prop comes with the SA that triggers after your intended duration. (When the first prop is converted into the second, the second will be properly added to the turn-based check list.)
|
|
|
Post by Aves Dominari on Sept 7, 2013 20:42:42 GMT -5
I really do hate to post another question here, but I've hit a roadblock that I can't simply ignore or work around. The system you should be familiar with; there's a number of placeholder entities scattered throughout the map. When the player uses a special ability to select the race he wants to fight, an invisible explosion will transform all of these placeholder entities into actual enemies. The problem is that it doesn't seem to be working in the slightest. The ability is used, the explosion happens... and all of the placeholder entities are still there. I'm certain that the explosion actually happens; there's a second or two where the game lags after the ability is triggered. My runlog isn't giving me any errors. I made sure the special abilities are attached to the explosion, that the explosion has the proper radius and power, and that the correct explosion is being used. Hell... I even reinstalled the game, just in case. I also hacked in a quick invisible prop spawning system, and it won't work either. I was thinking about attaching the SAs to the entities themselves and triggering the mutations when they get hit by explosions, but there's no way to check for explosion names or traits so there's no way to do specialized spawning (which defeats the whole point). All you need to do is press 'z' and then 'a' at the beginning of the game to trigger the explosion. All the relevant SAs begin with 'SECT.' If the attachment is buggered I'll email it to you. Attachments:
|
|