ScriptedEffect experimental builds
Moderators: Enjay, Dev Builds Team
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: ScriptedEffect experimental builds
I can always add a BUMPEDSPECIAL flag which has the bumped object as the activator of the script. It's like ten seconds of work and there's still plenty of space in flags6!
-
- Hosted
- Posts: 37
- Joined: Tue Dec 16, 2008 3:26
- Contact:
Re: ScriptedEffect experimental builds
If you could make that flag have the bumped thing set its target to the bumper before it does the special, I think this would be immensely useful in combination with ActivateTarget.Gez wrote:I can always add a BUMPEDSPECIAL flag which has the bumped object as the activator of the script. It's like ten seconds of work and there's still plenty of space in flags6!
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: ScriptedEffect experimental builds
Would this be to your liking?
Or maybe a different system with other flags which affect the behavior of BUMPSPECIAL. For instance
Code: Select all
// Check for actors touching a thing with MF6_BUMP*ED*SPECIAL
// Differences with the previous include not caring about whether the bumper is a player,
// the bumpee being the activator of the special, and a target switching system as the
// bumpee changes its target to the bumper.
else if ((thing->flags6 & MF6_BUMPEDSPECIAL) && thing->special)
Or maybe a different system with other flags which affect the behavior of BUMPSPECIAL. For instance
- BUMPEDACTIVATOR, if set, has the bumped actor as the activator, otherwise it's the bumper
- BUMPTARGETSWITCH, if set, makes the activator changes its target to the other (is it okay to change a player's target? waiting for Graf's input on that one)
- BUMPANYTHING, if set, let actors other than player trigger the BUMPSPECIAL logic
-
- Hosted
- Posts: 37
- Joined: Tue Dec 16, 2008 3:26
- Contact:
Re: ScriptedEffect experimental builds
Looks pretty fucking sweet to me =)
Hey, if you do it that way, how much trouble would it be to add USEDACTIVATOR and USEDTARGETSWITCH while you're at it?
re: is it ok: if not, it could just be inactive if BUMPACTIVATOR is not present. The player's target seems totally arbitrary to me, I don't really get what it's for but I'm sure you guys know more about that than I do.
edit - dumb ass typo
Hey, if you do it that way, how much trouble would it be to add USEDACTIVATOR and USEDTARGETSWITCH while you're at it?
re: is it ok: if not, it could just be inactive if BUMPACTIVATOR is not present. The player's target seems totally arbitrary to me, I don't really get what it's for but I'm sure you guys know more about that than I do.
edit - dumb ass typo
Last edited by baghead on Tue Jun 09, 2009 22:31, edited 1 time in total.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: ScriptedEffect experimental builds
Gez wrote:Would this be to your liking?Code: Select all
// Check for actors touching a thing with MF6_BUMP*ED*SPECIAL // Differences with the previous include not caring about whether the bumper is a player, // the bumpee being the activator of the special, and a target switching system as the // bumpee changes its target to the bumper. else if ((thing->flags6 & MF6_BUMPEDSPECIAL) && thing->special)
Or maybe a different system with other flags which affect the behavior of BUMPSPECIAL. For instanceThat gives a total of four flags, which can be combined together in many different ways.
- BUMPEDACTIVATOR, if set, has the bumped actor as the activator, otherwise it's the bumper
- BUMPTARGETSWITCH, if set, makes the activator changes its target to the other (is it okay to change a player's target? waiting for Graf's input on that one)
- BUMPANYTHING, if set, let actors other than player trigger the BUMPSPECIAL logic
Too many flags if you ask me. Even if you did them they should also work with USESPECIAL then. Better invent a new property instead of using multiple flags.
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: ScriptedEffect experimental builds
Still it's an innately bitfieldesque thing.
So, baghead, you'll find a bumpextended patch on the archive -- I didn't bother uploading a build since you use Linux. Actors now have a new property, activation, which takes a string. I wanted to make it an int, but unfortunately my tests told me that the thingdef property parser rejected constants and expressions used in properties. So I made it a string. That string is checked for keywords, so it's a sort of flag system.
Keywords include:
And if you make an actor that inherits from another, you can prefix a keyword with a minus sign, i.e. -ThingActs, to clear that flag.
Both BUMPSPECIAL and USESPECIAL are affected, however I didn't extend USESPECIAL to bother with non-player triggers, since as far as I know only players can call P_UseTraverse(), which is where the USESPECIAL checks are done.
If you could test it and tell me if whether it works great or break stuff, I'd appreciate it. The string-with-keyword thing is a bit hacky, but at least it works, so it gives you a way to test the important parts -- I'm more concerned by the changes to the game logic in p_map.cpp.
So, baghead, you'll find a bumpextended patch on the archive -- I didn't bother uploading a build since you use Linux. Actors now have a new property, activation, which takes a string. I wanted to make it an int, but unfortunately my tests told me that the thingdef property parser rejected constants and expressions used in properties. So I made it a string. That string is checked for keywords, so it's a sort of flag system.
Keywords include:
- ThingActs -- the thing is the source of the activation
- ThingTargets -- the thing targets the trigger
- TriggerTargets -- the trigger targets the thing
- MonsterTrigger -- monsters (as defined by the MONSTER flag) are allowed to be triggers
- MissileTrigger -- missiles (as defined by the MISSILE flag) are allowed to be triggers
Code: Select all
Actor Test
{
activation "+ThingActs +ThingTargets +TriggerTargets +MonsterTrigger +MissileTrigger and what's the point of this 'cuz I don't even have a BLAHSPECIAL flag anyway"
}
Both BUMPSPECIAL and USESPECIAL are affected, however I didn't extend USESPECIAL to bother with non-player triggers, since as far as I know only players can call P_UseTraverse(), which is where the USESPECIAL checks are done.
If you could test it and tell me if whether it works great or break stuff, I'd appreciate it. The string-with-keyword thing is a bit hacky, but at least it works, so it gives you a way to test the important parts -- I'm more concerned by the changes to the game logic in p_map.cpp.
-
- Hosted
- Posts: 37
- Joined: Tue Dec 16, 2008 3:26
- Contact:
Re: ScriptedEffect experimental builds
This looks great, I'll take a look at it right now =)
Edit - This patch doesn't want to be applied for some reason; tried adjusting fuzz factor, ignoring whitespace, etc., nothing worked (not sure why, it looks fine to me) =/ Anyway, I applied it by hand, compiled it, left, and came back to find it compiled ok. I did a little testing in zokoban, everything I've tested so far seems to work but I still need to test some more. Thanks, Gez, this is great stuff!
Edit - This patch doesn't want to be applied for some reason; tried adjusting fuzz factor, ignoring whitespace, etc., nothing worked (not sure why, it looks fine to me) =/ Anyway, I applied it by hand, compiled it, left, and came back to find it compiled ok. I did a little testing in zokoban, everything I've tested so far seems to work but I still need to test some more. Thanks, Gez, this is great stuff!
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: ScriptedEffect experimental builds
Cool. Let me know if you find any problem.baghead wrote:Anyway, I applied it by hand, compiled it, left, and came back to find it compiled ok. I did a little testing in zokoban, everything I've tested so far seems to work but I still need to test some more. Thanks, Gez, this is great stuff!