|
Post by Kyzrati on Jun 18, 2013 20:36:55 GMT -5
It seems you've found a limitation of the engine. The two versions of ENT/PROP MANIP triggers are not compatible in a single action, because the engine will only activate the first one which is valid (i.e. passes all conditions), even if both are valid. This was by design because otherwise large entities could unexpectedly trigger multiple props/ents simply by pressing 'n' while facing them all at once--a rare case, but something that must be considered. The alternate would be to allow only one part of a large entity to be its "active part" for manipulation, which would be annoying in other ways (repositioning in probably an unrealistic manner just to activate something).
Intentionally allowing simultaneous activation of all such triggers in front of an entity leads to other potential issues/bugs depending on what kinds of SA exist and what it's possible to face all at once...
As a result the current method is a bit more limiting in that regard.
Maybe I should code in an exception to allow all such triggers on a single object to be activated at once (assuming necessary conditions are met), rather than a blanket reduction to the first one found. Without this change, I doubt there's any other way you could achieve your goal here, eh?
I could do it this weekend when I return home--I don't really want to mess with the code without my large monitor.
Also, I should probably release this including the other fixes I made for you a little while back, but I've been trying to avoid too many small releases since that dilutes the changelog and interesting features available for major releases. I might start doing version pre-releases on the forum, meaning only modders and anyone else accessing the forum will be able to play in-development mods, but that's more or less how it is anyway. This'll give you a chance to actually see/use the changes without me having to do an official release.
|
|
|
Post by 10101 on Jun 18, 2013 23:13:56 GMT -5
There would be 2 ways to circumvent this Problem:
First: Using 'manipulate' two times. The first one does something to the prop/entity adding an trait. The second time the first SA doesn't work as it finds the trait. Then the second one activates, (finds the trait) and does something with the entity. Either the second one or a third one then removes the trait(s).
Second: All about explosions. The manipulated prop/entity creates an explosion hitting the manipulating entity. Disadvantage: that explosion could hit more than one entity.
|
|
|
Post by Kyzrati on Jun 19, 2013 4:08:42 GMT -5
Explosions are nice and flexible but wouldn't really work here as you say.
And I was thinking about trait use to enable multiple manipulation triggers, but that would require two separate actions, which doesn't really seem feasible for this situation since what if someone doesn't go through with both? I guess it's just not ideal, and also has the drawback of being an exception to the standard way of manipulating things. There could be explanatory text, but that's not very nice from a UI perspective. In any case, I'll see what I can do about this one in a few days.
|
|
|
Post by Kyzrati on Jun 23, 2013 2:55:23 GMT -5
Was just looking into this, and your SA setup wouldn't by any chance happen to be mutating ents or converting props, would it? I'm not sure exactly how you've implemented it so I'm not sure if the changes I'll be making would solve the issue. The game must handle SA execution sequentially--it'd be impossible to do two simultaneously, which would be required if any necessary related objects are destroyed as soon as the first is triggered. If you're using traits or some other method then it'd be okay. Need to find out how you're doing first.
|
|
|
Post by strangeguy on Jun 23, 2013 12:42:05 GMT -5
I have been mutating and converting, though I could use traits for the prop, only been converting so its name shows whether it is currently being used but you should be able to find that out by looking at entities nearby anyway so not a big loss. For entities changing it from mutate would be a lot harder, drop equipment, new weapon, remove endurance (though that doesn't stop them moving when panicked), provide protection to front with armour, and a trait. Might still be doable, not sure as I've just use mutate in similar situations.
|
|
|
Post by Kyzrati on Jun 23, 2013 22:44:24 GMT -5
Figured you were using that method... I think it should be possible to fix this as long as the manipulated prop isn't destroyed (since it's the one holding the abilities), I'd just have to internally always check for and execute the '2' version SA first, i.e. manipulate prop -> prop changes state (not destroyed) -> entity mutates.
You can really achieve this whole gun-manning thing by entity mutation without any other side effects when returning them to normal?
|
|
|
Post by strangeguy on Jun 24, 2013 5:54:51 GMT -5
I haven't noticed any side effects (except stats and gender being rerandomised each time you change). What sort of things would you expect? I could easily be missing something.
I'm also beginning to wonder if I actually could get it working with that, with traits I'd need two PROP_MANIPs one for mounting and one for dismounting with mounting requiring the trait present/not present.
|
|
|
Post by Kyzrati on Jun 24, 2013 6:32:59 GMT -5
Well, stats being re-randomized is a pretty big thing, isn't it? The entity is no longer the same anymore! That's the main one I was thinking at first--seemed pretty important to me.
I think you could probably still do it with the change in, but maybe we should, um, skip this one for now... it seems to have the potential to be quite unstable, or at best unfriendly for scripting.
|
|
|
Post by strangeguy on Jun 24, 2013 6:50:45 GMT -5
I'm fine with skipping it, it was never a major feature. I have been using mutating elsewhere with randomising stats, though currently only on mechs which have fixed 'physical' stats (like strength or time units) and only a 10 or 20 point variance in other stats, it's not too big a deal though I do admit its a problem.
|
|
|
Post by Kyzrati on Jun 24, 2013 7:49:38 GMT -5
I was thinking more on this and the capability to do this would probably eventually be added as a unique feature anyway, just not... now. Entities should be able to mount props and/or other entities, e.g. riding in/on vehicles or animals.
|
|
|
Post by 10101 on Jun 28, 2013 0:15:20 GMT -5
Thought about that. I'm not sure how difficult that would be to implement, but what about something like SWITCH_ACTORS? That way you could create a SA and then add a line with + SWITCH_ACTORS, which then exchanges actor and target (so actor becomes target and vice versa).
|
|
|
Post by Kyzrati on Jun 28, 2013 0:25:26 GMT -5
I must admit: That... would make my head explode.
(Above comment is a comical reflection of the feasibility of said solution, given the way everything's implemented.)
|
|
|
Post by strangeguy on Jun 28, 2013 17:22:05 GMT -5
I'm using mutating for something else, and I've noticed a problem in that inventories don't appear to be transferring despite using TRANSFER_FULL, probably because it's all weapon modules rather than actual droppable inventory. This mean at the moment you are unarmed when changing, and even if I fix that you'll get a free ammo refill. Not a massive issue for that particular weapon, but still something I want to avoid.
Also wondering how MUTATE_DELAYED since I'm not sure if I want you to be able to change instantly. Thinking of adding a special ability triggering next turn that mutates, be wondering if there is an easier solution (or whether I need to do so at all, main reason is it is changing shield types with kinetic included so you could get infinite kinetic shields to protect from reaction fire).
|
|
|
Post by Kyzrati on Jun 28, 2013 20:36:17 GMT -5
I originally designed the weapon inventory slots as holding non-removable items, so even TRANSFER_FULL will destroy their contents on mutating. You can change this behavior by changing the appropriate slot's Remove value from "No" to "Assist" (in mechanics/inventory.xt), which I added a long time ago as a way to enable machine parts to be removed with the assistance of another entity (like a soldier swapping out a tank module in the field, for example), but I haven't actually used it yet. Hm, the only problem I see with that change is it will drop those modules/items to the ground when the entity dies... I guess one way around that is to add an SA to each of those items that automatically destroys them when they fall to the ground. Pretty sure that will have you covered. Mutating was always intended to be permanent, so I never really ran into these problems before.
While it has a generic name, MUTATE_DELAYED was really intended to handle all the peculiarities surrounding the chryssalid's zombification attack. It's not useful for much else due to the way it "delays" the effect, among other things (ex: it will only trigger on AI-controlled entities). To delay an effect you'd be better off adding a new SA to the target that will automatically trigger at the right time, if possible.
By the way, check out the new private thread to download R9.2a, which includes some of the fixes you asked for a while back.
|
|
|
Post by strangeguy on Jul 19, 2013 13:55:08 GMT -5
Been a while but I've only just decided to do a bit more for my mod. Tried out switching it to assist, it definitely worked since they drop their weapons on death, but they are unarmed when mutating so the bit I actually wanted doesn't work. Probably just give up and switch it to having weapons for each one, I don't really care if they have unlimited ammo for that weapon, still I think you should know it didn't work.
|
|