Facebook Twitter YouTube Frictional Games | Forum | Privacy Policy | Dev Blog | Dev Wiki | Support | Gametee


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Well, fuck me.
FlawlessHappiness Offline
Posting Freak

Posts: 3,980
Threads: 145
Joined: Mar 2012
Reputation: 171
#1
RE: Well, fuck me.

Player does not work with "ifGetEntitiesCollide".

What you can do is use: if(alState == 1) and if(alState == -1) at the areas.


I must compliment you for your great creativity to give your functions a relevant name.

Don't you have trouble remembering which function is which?

Trying is the first step to success.
01-20-2013, 05:53 PM
Find
i3670 Offline
Posting Freak

Posts: 1,308
Threads: 74
Joined: Oct 2011
Reputation: 36
#2
RE: Well, fuck me.

I had trouble reading your script with the names. But I too would say that you have to use alState.

"What you think is irrelevant" - A character of our time

A Christmas Hunt
01-20-2013, 06:12 PM
Find
FlawlessHappiness Offline
Posting Freak

Posts: 3,980
Threads: 145
Joined: Mar 2012
Reputation: 171
#3
RE: Well, fuck me.

(01-20-2013, 10:20 PM)Robosprog Wrote: I have no problems with the functions, and I know this may sound noobish but would I have too have an entitycollidecallback with the alstates or?

Yes.

You put these inside the function, instead of if(GetEntitiesCollide

Trying is the first step to success.
01-20-2013, 10:31 PM
Find
TheGreatCthulhu Offline
Member

Posts: 213
Threads: 10
Joined: Oct 2010
Reputation: 32
#4
RE: Well, fuck me.

EDIT: BeeKayK beat me to it, but, here's some explanations nevertheless.

About the functions:
When scripting/programming, it's a good practice to give your functions descriptive names (descriptive in the sense that they tell you what the function does) - not only it will help other people understand your code when asking questions on forums, or when you release a CS/FC when other people might try to learn from your source code, but it can even help you, especially if you decide to put the project on hold and maybe work on something else for a while - when you come back to the projject, say, a few weeks later, descriptive names will help you get back on track more quickly.
But, it's your choice.

About the "alState":
The alState parameter is an input variable to this callback (which you've allready hooked up):
void umadbro(string &in asParent, string &in asChild, int alState)

When a collision is detected, umadbro() is called. Now, the value of alState is passed in by the engine when a collision is detected, and it has the following meaning:
  • 1 --> means that the two entities just started to intersect (enter event)
  • -1 --> means that the two entities just stopped intersecting (leave event)
You can check the parameter to see which event has occurred. So, you already have all that you need, and the last param to the hookup method, 0, means that the umadbro callback should be called on both (enter) and (leave). So, that's OK too.
What BeeKayK is suggesting is to simply check the value of that parameter, instead of using
GetEntitiesCollide(). You don't have to add a new entity collide callback. Edit: Oh, you want to check for collisions with "area_2" - then yes, add a new callback!

P.S. But make sure that the fourth parameter is false( == don't delete callback on first collision detected):
PHP Code: (Select All)
AddEntityCollideCallback("Player""area_2""callback_name"false0); 

This is so that every enter/leave event can be detected; one way to connect it back to the umadbro() callback is to simply have an indicator variable set inside the callback_name() callback, that will record if the player is inside area_2 or not, and then check that variable from inside the umadbro() function.

PHP Code: (Select All)
bool isPlayerInArea2 false;
void callback_name(string &in asParentstring &in asChildint alState)
{
        
isPlayerInArea2 = (alState == 1);  // will be true if they intersect, false if not


Then you can just go:
PHP Code: (Select All)
if (isPlayerInArea2)
{
    
//whatever
}
else
{
    
//whatever else

(This post was last modified: 01-20-2013, 11:04 PM by TheGreatCthulhu.)
01-20-2013, 10:46 PM
Find
FlawlessHappiness Offline
Posting Freak

Posts: 3,980
Threads: 145
Joined: Mar 2012
Reputation: 171
#5
RE: Well, fuck me.

Thank you Cthulu.
I'm a little lazy tonight

Trying is the first step to success.
01-20-2013, 10:59 PM
Find
TheGreatCthulhu Offline
Member

Posts: 213
Threads: 10
Joined: Oct 2010
Reputation: 32
#6
RE: Well, fuck me.

Sure, no problem Big Grin
(Note that he needs to check if player collides with "area_2", while the original callback checks for collisions with "area_1" - so I had to expand a bit.)
(This post was last modified: 01-20-2013, 11:07 PM by TheGreatCthulhu.)
01-20-2013, 11:06 PM
Find
Your Computer Offline
SCAN ME!

Posts: 3,456
Threads: 32
Joined: Jul 2011
Reputation: 235
#7
RE: Well, fuck me.

If the parent is going to be "Player" (and the state is 0) for all the callbacks, then just use one callback for all of those collisions.

Tutorials: From Noob to Pro
(This post was last modified: 01-21-2013, 01:07 AM by Your Computer.)
01-21-2013, 01:05 AM
Website Find
TheGreatCthulhu Offline
Member

Posts: 213
Threads: 10
Joined: Oct 2010
Reputation: 32
#8
RE: Well, fuck me.

Yeah, but if he needs to track if the player is within "area_2", and have separate logic (which uses this information) for when "Player"/"area_1"-collision is detected, than mixing these logically separate functionalities into one function creates unnecessary complexity and confusion in terms of code structure - it's just bad design. It's better to separate code that does two distinct jobs into two functions.
(This post was last modified: 01-21-2013, 02:11 AM by TheGreatCthulhu.)
01-21-2013, 02:09 AM
Find
Your Computer Offline
SCAN ME!

Posts: 3,456
Threads: 32
Joined: Jul 2011
Reputation: 235
#9
RE: Well, fuck me.

(01-21-2013, 02:09 AM)TheGreatCthulhu Wrote: Yeah, but if he needs to track if the player is within "area_2", and have separate logic (which uses this information) for when "Player"/"area_1"-collision is detected, than mixing these logically separate functionalities into one function creates unnecessary complexity and confusion in terms of code structure - it's just bad design. It's better to separate code that does two distinct jobs into two functions.

I don't see it as multiple and differing jobs, nor do i see it as any more complex than his current code. Player enters area -> activate monster in the area. Player leaves area -> probably do something different. That's his current code. Even if there is one part of his code that is unique in comparison to the other callbacks that deal with the same thing, that can still be handled within one callback (with a local map variable and a conditional statement). Wrapping the same sequence of code into a separate function i see no significant difference in logic.

Tutorials: From Noob to Pro
01-21-2013, 03:44 AM
Website Find
TheGreatCthulhu Offline
Member

Posts: 213
Threads: 10
Joined: Oct 2010
Reputation: 32
#10
RE: Well, fuck me.

(01-21-2013, 03:44 AM)Your Computer Wrote: I don't see it as multiple and differing jobs, nor do i see it as any more complex than his current code. Player enters area -> activate monster in the area. Player leaves area -> probably do something different. That's his current code. Even if there is one part of his code that is unique in comparison to the other callbacks that deal with the same thing, that can still be handled within one callback (with a local map variable and a conditional statement). Wrapping the same sequence of code into a separate function i see no significant difference in logic.

No, the relevant bit of the code is: player enters area_1, things start to happen, and then if player is also inside area_2 one set of patrol nodes is added, and if not, another.

Look at his code:
PHP Code: (Select All)
// earlier (note which area): AddEntityCollideCallback("Player", "area_1", "umadbro", true, 0);


void umadbro(string &in asParentstring &in asChildint alState)
{
    
SetEntityActive("enemy_super_suitor_3"true);
    
AddEnemyPatrolNode("enemy_super_suitor_3""PathNodeArea_22"0"");
    
AddEnemyPatrolNode("enemy_super_suitor_3""PathNodeArea_23"1"");
    
    if(
GetEntitiesCollide("Player""area_2") == true)  // NOTE the area
    
{
        
AddEnemyPatrolNode("enemy_super_suitor_3""PathNodeArea_24"0"");
        
AddEnemyPatrolNode("enemy_super_suitor_3""PathNodeArea_25"0"");
    }
    else if(
GetEntitiesCollide("Player""area_2") == false)   // NOTE the area
    
{
        
AddEnemyPatrolNode("enemy_super_suitor_3""PathNodeArea_26"0"");
    }
    
    
AddEntityCollideCallback("enemy_super_suitor_3""ScriptArea_1""cake4"false1);


The problem was that GetEntitiesCollide() doesn't support "Player". What I'm saying is for him to do this:
PHP Code: (Select All)
// earlier
// AddEntityCollideCallback("Player", "area_2", "OnCollideWithArea2", false, 0);
// AddEntityCollideCallback("Player", "area_1", "umadbro", true, 0);

bool isPlayerInArea2 false;
void OnCollideWithArea2(string &in asParentstring &in asChildint alState)
{
    
isPlayerInArea2 = (alState == 1);  // will be true if they intersect, false if not


void umadbro(string &in asParentstring &in asChildint alState)
{
    
// do umadbro() stuff as before

    
if(isPlayerInArea2)   // <-----  use this instead
    
{
        
AddEnemyPatrolNode("enemy_super_suitor_3""PathNodeArea_24"0"");
        
AddEnemyPatrolNode("enemy_super_suitor_3""PathNodeArea_25"0"");
    }
    else
    {
        
AddEnemyPatrolNode("enemy_super_suitor_3""PathNodeArea_26"0"");
    }
    
    
// rest of the code omitted...


That's all. Now, sure, he could throw the code from OnCollideWithArea2() inside his umadbro() - I'm saying he shouldn't.
(This post was last modified: 01-21-2013, 05:04 AM by TheGreatCthulhu.)
01-21-2013, 05:01 AM
Find




Users browsing this thread: 2 Guest(s)