Pathnoding like Unreal Engine 1.0 (and Translocators)
Moderator: GZDoom Developers
- NewGustavo6046
- Posts: 111
- Joined: Tue Oct 28, 2014 7:26 pm
Pathnoding like Unreal Engine 1.0 (and Translocators)
Yes, it's just what the subject implies, unless you don't know what it means.
It means putting many path nodes (or pathpoints) to guide the bots, using also a lot of different kinds for performing different actions (like JumpPoint's, TranslocatorPoint, RocketJumpPoint, SnipePoint, AmbushPoint, DefensePoint, LiftStart, LiftEnd, etc.)
Also, for instance, the Translocator link just does links to the Liandri Archives, an Unreal Tournament wiki. I doubt people could make an Translocator-like weapon, something that shoots an projectile that don't "dies", and that you can alt-fire later to teleport into the projectile's location, or clicking to return it into the weapon once it is empty and the projectile/disc is too far to grab normaly...
			
			
									
						
										
						It means putting many path nodes (or pathpoints) to guide the bots, using also a lot of different kinds for performing different actions (like JumpPoint's, TranslocatorPoint, RocketJumpPoint, SnipePoint, AmbushPoint, DefensePoint, LiftStart, LiftEnd, etc.)
Also, for instance, the Translocator link just does links to the Liandri Archives, an Unreal Tournament wiki. I doubt people could make an Translocator-like weapon, something that shoots an projectile that don't "dies", and that you can alt-fire later to teleport into the projectile's location, or clicking to return it into the weapon once it is empty and the projectile/disc is too far to grab normaly...
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact:
Re: Pathnoding like Unreal Engine 1.0 (and Translocators)
The Translocator is something that can (and should) be done with an external mod, not something that should be directly added to the ZDoom engine. I'm not sure what pathnoding you're talking about, though.
			
			
									
						
										
						Re: Pathnoding like Unreal Engine 1.0 (and Translocators)
I'm gonna say, don't hold your hopes up and read the wiki page on [wiki]bots[/wiki]. Especially the red and yellow box at the top.
Mind that this is for actual bots. What you're using are fake bots created with friendly monsters. Friendly monsters are like all other monsters, they're basic actors and actor processing is already the biggest limiting factor in ZDoom performances, so normal actors are unlikely to get extra pathoding capabilities that would make them have even more of a chokehold on processing speed.
			
			
													Mind that this is for actual bots. What you're using are fake bots created with friendly monsters. Friendly monsters are like all other monsters, they're basic actors and actor processing is already the biggest limiting factor in ZDoom performances, so normal actors are unlikely to get extra pathoding capabilities that would make them have even more of a chokehold on processing speed.
					Last edited by Gez on Sun Nov 16, 2014 1:04 pm, edited 1 time in total.
									
			
						
										
						- Graf Zahl
- Lead GZDoom+Raze Developer 
- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Pathnoding like Unreal Engine 1.0 (and Translocators)
Find someone willing to invest the work and we are good to go. But since I believe that this is not going to happen I'll peemptively 'no' it right now.
			
			
									
						
										
						- NewGustavo6046
- Posts: 111
- Joined: Tue Oct 28, 2014 7:26 pm
Re: Pathnoding like Unreal Engine 1.0 (and Translocators)
Look these links:
1 - 2 - 3 - 4
Okay, these shows that I could just make another kind of REAL bot with a different script. One that would seek for those "nodes" or whatever I can call them. Just... if it won't work with ACS, I think we may use an slightly-modified version of ACS that include the functions:
- A_SeekActors(string actor, int radius, bool seeknofollow) // Will seek actor, while with an radius margin of error. The seeking speed of movement and of turning (the angle so it leans to actor, like in A_SeekerMissile) will be defined by the actor's properties ActorSeekSpeed (default to the speed of an A_SkullAttack) and ActorSeekTurning (default to the turning speed of A_RevenantTracer). If seeknofollow is 1, then it will not follow actor if it has the +AIP_DONT-FOLLOW.
- A_SeekActorsAsPath(string actor, int radius, int range, int followchance, bool oneway) // Same as SeekActors, except the engine will create an path between actor and the next actor (of same class) that be within range units of range. It will parse the following: the closest actor of same class to actor that be found will have followchance of chance (from 1 to 255) for the calling actor to follow that actor after actor. If this chance don't 'hit' (or whatever term that designs "when, in a chance, it results in true"), then it will try again at the next closest actor. If one of they actually "hit", the calling actor (like a bot) will proceed to that actor (and, therefore, repeat the state See.AIPath which is the one for bot pathing in this modified ACS)... If the farthest actor from actor within range don't "hit" as well, then the parsing will loop at the closest again... So... if oneway is 1 or true, then once it "followed" from actor to the next actor that is chosen to follow during the followchance parsing, then the previous four actors (of same class than actor) will be automarked with the hidden flag +AIP_DONT-FOLLOW which will make it be ignored by the followchance parsing (and therefore will not be followed into), however still can be followed by SeekActors (with exceptions).
- A_GrabWeapon (int rangeradius) // Will seek and grab into the inventory any class that be child of Weapon and that is within the rangeradius.
- A_Grab (int rangeradius, [string actor]) // Will seek and grab into the inventory any class that be child of Inventory and that is within the rangeradius. It may follow a specific actor (or any child of it), if it is specified. Warning: The code, if actor don't be child of Inventory, then ZDoom will reject to load it, saying that
"A_Grab were set to seek a non-child of Inventory".
- A_PathBehavior ([int translocthreshold, [int transloc_horzangle, int transloc_vertangle]])
// Note that, depending on the special path nodes added to the list of actors, there may be more function properties.
// Bot and its childs will automatically do this 7 ticks after calling A_SeekActors/A_SeekActorsAsPath and get into a special path node like JumpSpotStart or TranslocStart. It will execute the very same actions in the special path node's state "PathBehavior" unless the calling actor has flag +AIP_NoSpecialBehavior .
For example, TranslocStart will make the seeking actor (or bot) to select Translocator from inventory, and shoot its altfire (TranslocDisc) at the target (TranslocEnd). It wil detect when TranslocDisc hit TranslocEnd because TranslocDisc itself will add the flag +TRANSLOC_DISCHITDEST to its owner (owner is an actor property of TranslocDist, it is the TID of the actor that altfired Translocator...) once TranslocDisc stop at a TranslocEnd. It will transmit -TRANSLOC_DISCHITDEST if it bounces off the TranslocDest or otherwise. Once the bot or whatever is using the translocator has waited translocthreshold ticks after getting +TRANSLOC_DISCHITDEST it will Fire Translocator (as Translocator will not anymore be holding TranslocDisc, Firing it will teleport its current owner to TranslocDist and teleport any Monster or Enemy that be near TranslocDist) and teleport. If they get -TRANSLOC_DISCHITDEST before translocthreshold ticks has been waited, then the function will be halted, the aim at TranslocDest will be changed randomly, within transloc_horzangle° horizontal and transloc_vertangle° vertical, and the calling actor will try and shoot TranslocDist again at the resulting aim.
//Later there may be more functions, someone good at scripting may try and/or make for me the final code for that... I will lead and develop easy things, as well as assist those who can't understand well the plans...
Of course, these are only suggestions. Problems, helping or whatever, just reply. That's the most important.
P.S.: Is it good my new avatar?
			
			
									
						
										
						1 - 2 - 3 - 4
Okay, these shows that I could just make another kind of REAL bot with a different script. One that would seek for those "nodes" or whatever I can call them. Just... if it won't work with ACS, I think we may use an slightly-modified version of ACS that include the functions:
- A_SeekActors(string actor, int radius, bool seeknofollow) // Will seek actor, while with an radius margin of error. The seeking speed of movement and of turning (the angle so it leans to actor, like in A_SeekerMissile) will be defined by the actor's properties ActorSeekSpeed (default to the speed of an A_SkullAttack) and ActorSeekTurning (default to the turning speed of A_RevenantTracer). If seeknofollow is 1, then it will not follow actor if it has the +AIP_DONT-FOLLOW.
- A_SeekActorsAsPath(string actor, int radius, int range, int followchance, bool oneway) // Same as SeekActors, except the engine will create an path between actor and the next actor (of same class) that be within range units of range. It will parse the following: the closest actor of same class to actor that be found will have followchance of chance (from 1 to 255) for the calling actor to follow that actor after actor. If this chance don't 'hit' (or whatever term that designs "when, in a chance, it results in true"), then it will try again at the next closest actor. If one of they actually "hit", the calling actor (like a bot) will proceed to that actor (and, therefore, repeat the state See.AIPath which is the one for bot pathing in this modified ACS)... If the farthest actor from actor within range don't "hit" as well, then the parsing will loop at the closest again... So... if oneway is 1 or true, then once it "followed" from actor to the next actor that is chosen to follow during the followchance parsing, then the previous four actors (of same class than actor) will be automarked with the hidden flag +AIP_DONT-FOLLOW which will make it be ignored by the followchance parsing (and therefore will not be followed into), however still can be followed by SeekActors (with exceptions).
- A_GrabWeapon (int rangeradius) // Will seek and grab into the inventory any class that be child of Weapon and that is within the rangeradius.
- A_Grab (int rangeradius, [string actor]) // Will seek and grab into the inventory any class that be child of Inventory and that is within the rangeradius. It may follow a specific actor (or any child of it), if it is specified. Warning: The code, if actor don't be child of Inventory, then ZDoom will reject to load it, saying that
"A_Grab were set to seek a non-child of Inventory".
- A_PathBehavior ([int translocthreshold, [int transloc_horzangle, int transloc_vertangle]])
// Note that, depending on the special path nodes added to the list of actors, there may be more function properties.
// Bot and its childs will automatically do this 7 ticks after calling A_SeekActors/A_SeekActorsAsPath and get into a special path node like JumpSpotStart or TranslocStart. It will execute the very same actions in the special path node's state "PathBehavior" unless the calling actor has flag +AIP_NoSpecialBehavior .
For example, TranslocStart will make the seeking actor (or bot) to select Translocator from inventory, and shoot its altfire (TranslocDisc) at the target (TranslocEnd). It wil detect when TranslocDisc hit TranslocEnd because TranslocDisc itself will add the flag +TRANSLOC_DISCHITDEST to its owner (owner is an actor property of TranslocDist, it is the TID of the actor that altfired Translocator...) once TranslocDisc stop at a TranslocEnd. It will transmit -TRANSLOC_DISCHITDEST if it bounces off the TranslocDest or otherwise. Once the bot or whatever is using the translocator has waited translocthreshold ticks after getting +TRANSLOC_DISCHITDEST it will Fire Translocator (as Translocator will not anymore be holding TranslocDisc, Firing it will teleport its current owner to TranslocDist and teleport any Monster or Enemy that be near TranslocDist) and teleport. If they get -TRANSLOC_DISCHITDEST before translocthreshold ticks has been waited, then the function will be halted, the aim at TranslocDest will be changed randomly, within transloc_horzangle° horizontal and transloc_vertangle° vertical, and the calling actor will try and shoot TranslocDist again at the resulting aim.
//Later there may be more functions, someone good at scripting may try and/or make for me the final code for that... I will lead and develop easy things, as well as assist those who can't understand well the plans...
Of course, these are only suggestions. Problems, helping or whatever, just reply. That's the most important.
P.S.: Is it good my new avatar?
- Kinsie
- Posts: 7402
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Pathnoding like Unreal Engine 1.0 (and Translocators)
What the hell?
			
			
									
						
										
						Re: Pathnoding like Unreal Engine 1.0 (and Translocators)
Okay.NewGustavo6046 wrote:just reply.
- Graf Zahl
- Lead GZDoom+Raze Developer 
- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Pathnoding like Unreal Engine 1.0 (and Translocators)
Ouch...
/me presses the 'flush' button...
			
			
									
						
										
						/me presses the 'flush' button...




