[Can't fix] [4.6.1]spawn randomspawner+immediate Thing_SetGoal

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

[4.6.1]spawn randomspawner+immediate Thing_SetGoal

Postby Matt » Tue Aug 17, 2021 4:03 pm

Working example attached.

Go to map01.

Expected: the demon replacing the imp moves counterclockwise along the pentagon.

Actual: the demon stays in idle state.

If you remove the randomspawner replacement, or replace the imp class with a monster directly, it will function as expected.
You do not have the required permissions to view the files attached to this post.
Last edited by Matt on Fri Aug 20, 2021 1:05 pm, edited 3 times in total.
User avatar
Matt
Putting the XD into *xdeath since 2007
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: [4.6.1]Randomspawners don't transfer specials

Postby Blue Shadow » Tue Aug 17, 2021 8:10 pm

This could be an order problem; RandomSpawner does the spawning in PostBeginPlay() which is called after OPEN scripts. Try putting a small delay before calling Thing_SetGoal.
User avatar
Blue Shadow
 
Joined: 14 Nov 2010
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: [4.6.1]Randomspawners don't transfer specials

Postby Matt » Tue Aug 17, 2021 8:18 pm

EDIT: This gives the desired result:
Code: Select allExpand view
#include "zcommon.acs"
script 1 OPEN {
   HudMessageBold(s:"GOGOGO";HUDMSG_FADEOUT|HUDMSG_LOG,2,CR_ORANGE,0.5,0.25,3.0,1.0);
      SpawnSpot("Doomimp",50,230);
      delay(1);
      Thing_SetGoal(230,53,0,0);
}
but this does not:
Code: Select allExpand view
#include "zcommon.acs"
script 1 OPEN {
   HudMessageBold(s:"GOGOGO";HUDMSG_FADEOUT|HUDMSG_LOG,2,CR_ORANGE,0.5,0.25,3.0,1.0);
      delay(1);
      SpawnSpot("Doomimp",50,230);
      Thing_SetGoal(230,53,0,0);
}


Given the comments I'm seeing in the BeginPlay versus PostBeginPlay in the RandomSpawner definition, this difference may be unavoidable.


I do wonder how many maps do something like this, though...



EDIT: i've attempted to move all the postbeginplay spawning/transferring stuff into this randomspawner's beginplay (and have its postbeginplay call actor.postbeginplay instead), and there's no difference.


EDIT: If i change that spawnspot to an imp with TID 230, the Thing_SetGoal with no delay works fine. Is it that the rest of the undelayed ACS script is being called before any spawned actor can call BeginPlay?
User avatar
Matt
Putting the XD into *xdeath since 2007
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: [4.6.1]SpawnSpawn randomspawner+immediate Thing_SetGoal

Postby NicoTheGoat » Wed Aug 18, 2021 9:44 am

This doesn't work because the actor is spawned in the RandomSpawner's PostBeginPlay method, which, due to being spawned after the ACS VM, isn't called until after the ACS VM is done ticking.
As Blue Shadow said, you'll have to delay the Thing_SetGoal call.

Matt wrote:EDIT: i've attempted to move all the postbeginplay spawning/transferring stuff into this randomspawner's beginplay (and have its postbeginplay call actor.postbeginplay instead), and there's no difference.
EDIT: If i change that spawnspot to an imp with TID 230, the Thing_SetGoal with no delay works fine. Is it that the rest of the undelayed ACS script is being called before any spawned actor can call BeginPlay?

Moving the spawn to BeginPlay doesn't work because BeginPlay is called immediately after the actor is spawned, before its TID can be changed by ACS, so the RandomSpawner ends up spawning its actor with a TID of 0.
User avatar
NicoTheGoat
 
Joined: 29 Dec 2019
Discord: emmy#4389
Github ID: nicothegoat
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)

Re: [4.6.1]SpawnSpawn randomspawner+immediate Thing_SetGoal

Postby Matt » Fri Aug 20, 2021 1:05 pm

Thanks for the explanation!

Yeah this definitely seems unavoidable as a matter of some pretty deep game logic... I think this can be closed.
User avatar
Matt
Putting the XD into *xdeath since 2007
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia


Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 4 guests