AI not following waypoints

Hi again,
I previously followed Mdogs tutorials to create the sniper mission, and all worked fine, however since installing EDx, (from the new link recently posted) and following the tutorial again, the AI no longer follow the waypoints. They now remain stationary at their spawn point, only responding when I fire. Any suggestions as to what I may have missed or do waypoints now work differently in EDx?
Thanks
Humflebert

Hi Humflebert!

If you are trying to use the waypoint connection method, that was removed due to conflict with the EDX.

Try this:

In the missions script and whereever the function is ie:

Code:



function onMissionStart()
OFP:move("plaech","waypointp","ADDTOFRONT")
end



note: where I have written the first two strings you would edit to suit your units and waypoint path names.

This got me too when I first started using the EDX. Not sure if its in the docs, but definitely worth a mention.

I know the standard mission editor uses all the XML files in the 'ScriptGeneration2' directory to generate code for 'waypoints.lua'. It seems possible to adapt that functionality to the EDX, but tvig probably had reasons for not doing so. Anyone know if this was ever attempted? Not even implement all the original waypoint functionality, but at least generate a move() command for linked entities.

I have been experimenting with the OFP:move() and OFP:patrol() functions, but in both cases the patrols stop at the last waypoint. Figuring how to loop either of these functions will solve the problem.
Bear in mind that I am new to editing so will keep trying and post a solution when I get it right, or more likely another member will show us first .
At this point I am still experimenting and learning so it is not too urgent, but I will need a working "marching up and down the square" function for my planned project.

Might be worth noting, if it ain't broke don't fix it. Afaik the EdX is fine as is and that this issue with waypoint connecting will always crop up I think, sort of the lazy coders path maker.

In any case if you decide to modify your EdX be aware that Tvig took out the function for a specific reason, I'm not sure what that is but I will not be updating the newly released state of the EDx.

Basically if you break your copy, it's ya own fault. Lol!

A few hours later and this works:
Create your waypoint path as usual, but do not link last to first.
use

Code:

 OFP:patrol ("unitname","waypoint path name", "ECYCLIC")

to have a patrol walk a perimeter continuously. To patrol back and forth along a path of waypoints, use "EBACKANDFORTH".
A third option, "ESINGLE" I have not tried yet, but I assume the patrol will then stop at the last point.
ps: I have no intention of altering EDx, I just need to learn how to use the commands correctly

Regg wrote:This got me too when I first started using the EDX. Not sure if its in the docs, but definitely worth a mention.

I know the standard mission editor uses all the XML files in the 'ScriptGeneration2' directory to generate code for 'waypoints.lua'. It seems possible to adapt that functionality to the EDX, but tvig probably had reasons for not doing so. Anyone know if this was ever attempted? Not even implement all the original waypoint functionality, but at least generate a move() command for linked entities.

As stated, the code generated for 'waypoints.lua', only worked for entities linked to paths that where in the same entityset. This meant that you could not spawn an entity and link it to a path in another set. The path and the linked entity had to be spawned in the same set. All other instances had to be coded.
It was also discovered that there was a hard limit as to how many waypoints could be added to your mission (approx 800), because of the generated code. Removing the linking feature frees up memory overhead, also I know of no-one discovering a limit with waypoints ( I am sure there is one) using the EDX.
By removing the auto code generated for the waypoints, Tvig was able to use that freed memory and the script to code in all the functionality required to enable secondary scripts to handle events... something CM never enabled.
The ability to share and blend scripts and code between users was almost impossible without intimate knowledge of authors style prior to the EDX. EDX allows modulation at the cost of removing linking entities to paths from within the editor. A small price to pay. ohh... 'the old days' of God codes.

Humflebert wrote:A few hours later and this works:
Create your waypoint path as usual, but do not link last to first.
use

Code:

 OFP:patrol ("unitname","waypoint path name", "ECYCLIC")

to have a patrol walk a perimeter continuously. To patrol back and forth along a path of waypoints, use "EBACKANDFORTH".
A third option, "ESINGLE" I have not tried yet, but I assume the patrol will then stop at the last point.
ps: I have no intention of altering EDx, I just need to learn how to use the commands correctly

This is correct!

ECYCLIC makes the units patrol continuously round the path.

EBACKANDFORTH makes them get the the last point and retrace there steps back to the beginning.

ESINGLE makes them walk the path once and stop at the end.

if
you use the random spawn Module Tj has made it so that you can spawn in
a path and you designate what type of patrol you want them to do using
the tables in the code. You don't need to link, assign or connect any
units you just place a recon point right next to the path and name it
one of two things, "pbaf" for patrol back and forth, "pcyc" patrol
cyclic, exactly what it means. He didn't apply a "psingle" because there
wasn't really a definate use for it.

I will put up a tut for this module soon, its on the list of the many things I have yet to do.

tjdagger wrote:As stated, the code generated for 'waypoints.lua', only worked for entities linked to paths that where in the same entityset. This meant that you could not spawn an entity and link it to a path in another set. The path and the linked entity had to be spawned in the same set. All other instances had to be coded.
It was also discovered that there was a hard limit as to how many waypoints could be added to your mission (approx 800), because of the generated code. Removing the linking feature frees up memory overhead, also I know of no-one discovering a limit with waypoints ( I am sure there is one) using the EDX.
By removing the auto code generated for the waypoints, Tvig was able to use that freed memory and the script to code in all the functionality required to enable secondary scripts to handle events... something CM never enabled.
The ability to share and blend scripts and code between users was almost impossible without intimate knowledge of authors style prior to the EDX. EDX allows modulation at the cost of removing linking entities to paths from within the editor. A small price to pay. ohh... 'the old days' of God codes.

As I said, I was sure tvig had his reasons. Adding a move() or patrol() command to the mission is trivial, and like MDog said, both random spawn modules available allow for automatic patrols. I won't mess up my EDX!