+- Frictional Games Forum (read-only) (https://www.frictionalgames.com/forum)
+-- Forum: Amnesia: The Dark Descent (https://www.frictionalgames.com/forum/forum-6.html)
+--- Forum: Custom Stories, TCs & Mods - Development (https://www.frictionalgames.com/forum/forum-38.html)
+---- Forum: Development Support (https://www.frictionalgames.com/forum/forum-39.html)
+---- Thread: Well, fuck me. (/thread-19996.html)
RE: Well, fuck me. - FlawlessHappiness - 01-20-2013
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?
RE: Well, fuck me. - i3670 - 01-20-2013
I had trouble reading your script with the names. But I too would say that you have to use alState.
RE: Well, fuck me. - FlawlessHappiness - 01-20-2013
(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
RE: Well, fuck me. - TheGreatCthulhu - 01-20-2013
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)
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:
AddEntityCollideCallback("Player", "area_2", "callback_name", false, 0);
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:
bool isPlayerInArea2 = false;
void callback_name(string &in asParent, string &in asChild, int alState)
{
isPlayerInArea2 = (alState == 1); // will be true if they intersect, false if not
}
Then you can just go:
PHP Code:
if (isPlayerInArea2)
{
//whatever
}
else
{
//whatever else
}
RE: Well, fuck me. - FlawlessHappiness - 01-20-2013
Thank you Cthulu.
I'm a little lazy tonight
RE: Well, fuck me. - TheGreatCthulhu - 01-20-2013
Sure, no problem
(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.)
RE: Well, fuck me. - Your Computer - 01-21-2013
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.
RE: Well, fuck me. - TheGreatCthulhu - 01-21-2013
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.
RE: Well, fuck me. - Your Computer - 01-21-2013
(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.
RE: Well, fuck me. - TheGreatCthulhu - 01-21-2013
(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:
// earlier (note which area): AddEntityCollideCallback("Player", "area_1", "umadbro", true, 0);
void umadbro(string &in asParent, string &in asChild, int 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", false, 1);
}
The problem was that GetEntitiesCollide() doesn't support "Player". What I'm saying is for him to do this:
PHP Code:
// earlier
// AddEntityCollideCallback("Player", "area_2", "OnCollideWithArea2", false, 0);
// AddEntityCollideCallback("Player", "area_1", "umadbro", true, 0);
bool isPlayerInArea2 = false;
void OnCollideWithArea2(string &in asParent, string &in asChild, int alState)
{
isPlayerInArea2 = (alState == 1); // will be true if they intersect, false if not
}
void umadbro(string &in asParent, string &in asChild, int 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.