[ACS] Doom 64 style fading spawning things (updated 4/25/17)

Sprites, textures, sounds, code, and other resources belong here. Share and share-alike!
Forum rules
Before posting your Resource, please make sure you can answer YES to any of the following questions:
  • Is the resource ENTIRELY my own work?
  • If no to the previous one, do I have permission from the original author?
  • If no to the previous one, did I put a reasonable amount of work into the resource myself, such that the changes are noticeably different from the source that I could take credit for them?
If you answered no to all three, maybe you should consider taking your stuff somewhere other than the Resources forum.

Consult the Resource/Request Posting Guidelines for more information.

Please don't put requests here! They have their own forum --> here. Thank you!
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

[ACS] Doom 64 style fading spawning things (updated 4/25/17)

Post by Nevander »

Doom 64 Style Thing Spawn Fading! (version 5, last updated 4/25/17)

In case anyone else wants to utilize this code. I have completely refactored the code and it now provides four functions instead of two. You can now fade in only, fade out only, fade and spawn, and fade and spawn forced for those tricky places where something would fail to spawn. In my code you can also see I do specific checks to certain actor classes to get the target alpha. This will need to be taken into consideration when spawning your own monsters. In classic Doom, the Spectre and Lost Soul are the only two to consider. The Spectre always has a default alpha of 0.5 and the Lost Soul can vary depending on the transsouls CVAR. These scripts take both into consideration.

This source is set up for use in vanilla Doom. Adding new condition checks should be obvious to any experienced ACS coder. Basically where the script is checking actor classes, you will need to change these checks to reflect your custom monsters. You can also control the length of the fade effect by changing the FADE_TICS constant. Currently the script is set up by default to take one second (or 35 tics) to fade in. The fading is completely secondary to the spawning, so nothing waits on the fade to finish. All important actions happen before the fading begins, so killing monsters early should not cause problems.

NOTE: There is an issue with Spectres that cannot be solved and thus is forced in the script. If you use a fuzz renderstyle for them in your preferences the fading will NOT work, ever. If the style is set to anything other than Translucent, the Spectre will simply instantly appear. So, to counter this the script always forces the renderstyle to translucent and then returns it to your setting for OptFuzzy upon finishing. For a smooth effect, it is suggested that you set "use fuzz effect" to translucent!


DOWNLOADS:

SOURCE TEXT DOWNLOAD:
d64_fade_things_v5_base.txt
(4.33 KiB) Downloaded 98 times
EXAMPLE WAD (UDMF, Doom 2):
fade_spawn_example.wad
(19.86 KiB) Downloaded 100 times
SOURCE:

Code: Select all

/* --- FADING THINGS IN AND OUT V5 ------------------------------------------------------------- */

/* USAGE AND EXAMPLES:

IMPORTANT NOTE: It is critical that you separate out newTIDs between actors with different alpha
values or renderstyles. You will get undesirable results if you try to spawn things with a preset
alpha value with the same newTID of a thing with a normal renderstyle. The last thing to spawn
will get priority and all previous actors sharing the same newTID will be affected. This means
that you should always give different newTIDs to things which have different renderstyles/alphas.

USAGE:
{
	Thing_FadeIn(int tid);
		tid = thing ID of any thing to fade in, usually one previously faded out
		
	Thing_FadeSpawn(int spotTID, int spawnID, int newTID);
		spotTID = MapSpot or TID of the thing to spawn the new thing at
		spawnID = the spawnID or T_ name identifier of the thing to spawn
		newTID = the new TID to give the spawned thing, if 0 a unique TID is assigned
		
	Thing_FadeSpawnForced(int spotTID, str className, int newTID);
		spotTID = MapSpot or TID of the thing to force spawn the new thing at
		className = the class name of the actor to be spawned
		newTID = the new TID to give the spawned thing, if 0 a unique TID is assigned
		
	Thing_FadeOut(int thingID, bool keepThing);
		thingID = the TID of the thing to fade out
		keepThing = set to 1 to only fade out the thing, 0 will also remove the thing
}

EXAMPLES:
{
	Thing_FadeIn(1);
		Fades in any thing with a TID of 1, should be used on a thing with TID of 1 that was faded out
	
	Thing_FadeSpawn(1, T_IMP, 0);
		Fades in a normal Imp at MapSpot 1, then assigns a unique newTID to the spawned thing
		
	Thing_FadeSpawnForced(1, "DoomImp", 42);
		Fades in a normal Imp at MapSpot 1 with a preset newTID of 42
		
	Thing_FadeOut(42, 0);
		Fades out the Imp that would have been faded in from above and then removes it from the map
}
*/

#define FADE_TICS 35
#define FADE_AMOUNT (1.0 / FADE_TICS)

// Script for fading in any thing
script 998 (int tid)
{
	int targetAlpha = 0.0;
	int currentAlpha = 0.0;
	int renderStyle = 0;
	
	if(CheckActorClass(tid, "Spectre")) targetAlpha = 0.50;
	else if(CheckActorClass(tid, "LostSoul")) targetAlpha = GetCVar("transsouls");
	else targetAlpha = 1.0;
	
	int fadeStep = FixedMul(FADE_AMOUNT, targetAlpha);
	
	Thing_Activate(tid);
	SoundSequenceOnActor(tid, "SpawnThing");
	SetActorProperty(tid, APROP_RenderStyle, STYLE_Translucent);
	SetActorProperty(tid, APROP_Alpha, currentAlpha);
	
	for(int counter = 0; counter < FADE_TICS; counter++)
	{
		currentAlpha += fadeStep;
		if(targetAlpha < currentAlpha) currentAlpha = targetAlpha;
		
		SetActorProperty(tid, APROP_Alpha, currentAlpha);
		Delay(1);
	}
	
	if(CheckActorClass(tid, "Spectre")) renderStyle = STYLE_OptFuzzy;
	else if(CheckActorClass(tid, "LostSoul")) renderStyle = STYLE_SoulTrans;
	else renderStyle = STYLE_Normal;
	
	SetActorProperty(tid, APROP_Alpha, targetAlpha);
	SetActorProperty(tid, APROP_RenderStyle, renderStyle);
}

// Script for fading out any thing and optionally removing it
script 999 (int thingID, int keepThing)
{
	int currentAlpha = GetActorProperty(thingID, APROP_Alpha);
	int fadeStep = FixedMul(FADE_AMOUNT, currentAlpha);
	int targetAlpha = 0.0;
	
	Thing_Deactivate(thingID);
	SetActorProperty(thingID, APROP_RenderStyle, STYLE_Translucent);
	
	for(int counter = 0; counter < FADE_TICS; counter++)
	{
		currentAlpha -= fadeStep;
		if(targetAlpha > currentAlpha) currentAlpha = targetAlpha;
		
		SetActorProperty(thingID, APROP_Alpha, currentAlpha);
		Delay(1);
	}
	
	SetActorProperty(thingID, APROP_Alpha, targetAlpha);
	if(keepThing == 0) Thing_Remove(thingID);
}

// Functions for fading in and out
function void Thing_FadeIn (int tid)
{
	ACS_ExecuteWithResult(998, tid);
}
function void Thing_FadeSpawn (int spotTID, int spawnID, int newTID)
{
	if(newTID == 0) newTID = UniqueTID();
	Thing_SpawnFacing(spotTID, spawnID, 1, newTID);
	ACS_ExecuteWithResult(998, newTID);
}
function void Thing_FadeSpawnForced (int spotTID, str className, int newTID)
{
	if(newTID == 0) newTID = UniqueTID();
	SpawnSpotFacingForced(className, spotTID, newTID);
	ACS_ExecuteWithResult(998, newTID);
}
function void Thing_FadeOut (int thingID, int keepThing)
{
	ACS_ExecuteWithResult(999, thingID, keepThing);
}
The other thing you will need is to set up the sound sequence for their spawn sound. Note that if you do not have one, there are no errors or anything and the spawn just ends up being silent so it's optional but I am not providing you with a sound since I'd imagine you'd want to use your own. All you need to do is set up the sound sequence in SNDSEQ and then define your sound in SNDINFO if it's not a built in sound. Here's an example of a SpawnThing sound sequence that uses the normal teleport sound. This code goes into a SNDSEQ lump and the script takes care of the rest. Tweak attenuation to preference.

Code: Select all

:SpawnThing
	play misc/teleport
	nostopcutoff
	attenuation normal
end

NOTES:
There is only one major drawback to this and it should be obvious like it is to me now, if you plan to use new TIDs you will need to manually separate those out when doing the spawning. So spawning a translucent monster with a newTID of 33 and then spawning something like a ZombieMan with the same newTID will cause the translucent monster to have their alpha moved up to the wrong value. They will need different newTIDs. If you are using a map where you need to do a ThingCount, you will need to do an additive count like so:

Code: Select all

While((ThingCount(T_NONE, 1) + ThingCount(T_NONE, 2) + ThingCount(T_NONE, 3)) > 0)
//do stuff
I would suggest doing something like this below so that you never have to worry about remembering the TID, only the variable for it (which will also always keep a TID unique):

Code: Select all

script 1 (void)
{
	int s1tid1 = UniqueTID();
	int s1tid2 = UniqueTID();
	int s1tid3 = UniqueTID();
	
	Delay(5);
	
	Thing_FadeSpawn(1, T_IMP, s1tid1);
	Thing_FadeSpawn(2, T_SPECTRE, s1tid2);
	Thing_FadeSpawn(3, T_LOSTSOUL, s1tid3);
	Delay(10);
	
	While((ThingCount(T_NONE, s1tid1) + ThingCount(T_NONE, s1tid2) + ThingCount(T_NONE, s1tid3)) > 0) Delay(10);
	Delay(35);
	
	Door_Open(16, 64, 0);
}
As you can see, since an Imp, Spectre, and Lost Soul are have different alphas and renderstyles they will ALL need their own TID so the function doesn't mess up the alpha of the others. Using a UniqueTID guarantees you don't accidentally use the same one twice. We need the variables so that we can use the exact unique TIDs in a ThingCount to control map progression as shown in the script above. Also note the naming convention for easy remembering: s[script num]tid[num], so s1tid1 is "script 1, tid 1."

There may be another special case where you fade in and spawn some things with newTID of 255 for example. This is all good and fine but what if you want to spawn more with the same newTID to use for a ThingCount before the previous 255's are all dead? What will happen is the others you spawned first will still be set at 255 since things don't lose their TIDs when they die and they will re-fade in again. They won't spawn again since the spot they spawn and their new TID are always separate, but they will fade in again. In this case, you will need to use separate newTIDs even if they should be the same, and then do an additive ThingCount as shown above.

After the ThingCount condition has passed and the actors with those newTIDs are no longer needed, you could do something like this after all is said and done, that is if you plan to spawn more later with the same newTID yet again:

Code: Select all

Thing_ChangeTID(255, 0);
Please note you should never change the TID within the amount you have set for FADE_TICS because the thing will stop fading in too early and will be too translucent. I would always delay by one tic higher than the value you have set for FADE_TICS. So if your FADE_TICS constant is set at 35, delay by 36 tics before changing the TID if you decide to do so.


CREDITS:
- Kaiser and Agent Spork for the original fade in version
- Me for the original fade out version
- Original code taken from Scalliano's TOP mod
- Thanks to KeksDose for helping build this better version
- Example map made by me
Last edited by Nevander on Tue Apr 25, 2017 3:06 am, edited 26 times in total.
User avatar
Enjay
 
 
Posts: 26516
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: [ACS] Doom 64 style fading for spawning things

Post by Enjay »

Nevander wrote:The only other thing I might would change is to use SpawnSpotFacingForced instead of Thing_SpawnFacing, but then it would require you to a) know or look up the class names...
Which, for me, has always been easier than knowing spawn ids. For example, I probably know all the stock Doom enemy actor names (and quite a few of the other actors too) off by heart but I don't think I know any of the spawn ids and would have to look them up. Using spawn ids is generally regarded as old fashioned and less convenient. e.g. any and every new actor created in DECORATE/ZScript has an actor/class name. None of them have a spawn id unless it has been specifically given to the actor.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: [ACS] Doom 64 style fading for spawning things

Post by Nevander »

Well I prefer the built in SpawnIDs because of the autocomplete in GZDB. If you start to type T_ something you get a list. However, you don't get a class name list unless you go to the wiki, know them already, or go into things mode and check the list.
User avatar
Enjay
 
 
Posts: 26516
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: [ACS] Doom 64 style fading for spawning things

Post by Enjay »

Nevander wrote:If you start to type T_ something you get a list.
But a completely new actor won't be on that list unless it has also had a T_ name defined. ;)
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: [ACS] Doom 64 style fading for spawning things

Post by Nevander »

True, which is why I actually have a TXT file of all the default spawn IDs as well as new ones I have added. Luckily I only ever need to use 155 frequently for Nightmare Imps and everything else has identifiers. Is there an easy and compatible way to define new T_ names and have GZDB recognize them? I'd imagine you could #include some kind of .acs file with just #DEFINE in it with your name and number.
User avatar
KeksDose
 
 
Posts: 595
Joined: Thu Jul 05, 2007 6:13 pm
Contact:

Re: [ACS] Doom 64 style fading for spawning things

Post by KeksDose »

You called the function Thing_FadeIn, but it does a lot more than that. I would decouple the fading into another script to work on some tid and then write "convenience functions" that spawn or activate groups of monsters that simply call the script after doing something else, like spawning or activating. You could write one function that uses a spawn id, Enjay could write one using classes, etc.

I also would not wrap a script call in a function. In this case it does not really matter because you would call this every once in a while, but if you had a loop of those every tic for some reason along with many other scripts, you would check that out.

The script will actually not work as intended with translucent things, by the way. You can help this issue by multiplying fader by the actor's alpha and setting translucent renderstyle only if it was normal (think of a spectre). The same goes for the fade out script. Use get the actor's alpha and go from there.

You may also want to use constants for the fade step amount and tics for the sake of complete and easy control.

[Edit]Just saw you edited the post, whoops. Lemme just come up with something here.

[Edit again]

Code: Select all

#define FADE_TICS 10
#define FADE_AMOUNT (1.0 / FADE_TICS)

// And in the script (this is fade in, fade out is basically the same)
int targetalpha = GetActorProperty(tid, APROP_ALPHA);
int renderstyle = GetActorProperty(tid, APROP_RENDERSTYLE);
if(renderstyle == STYLE_NORMAL)
   SetActorProperty(tid, APROP_RENDERSTYLE, STYLE_TRANSLUCENT);

int alpha = 0;
int fadestep = FixedMul(FADE_AMOUNT, targetalpha);
for(int t = 0; t < FADE_TICS; t++)
{
   alpha += fadestep;
   if(targetalpha < alpha)
      alpha = targetalpha;
   
   SetActorProperty(tid, APROP_ALPHA, alpha);
   Delay(const:1);
}

SetActorProperty(tid, APROP_RENDERSTYLE, renderstyle); 
Should work for practically any actor. This is also untested but it looks okay. It scales the fade amount per tic by the actor's alpha, which is conveniently between 0 and 1, so if the actor had half the alpha, we want half the alpha increase per tic and it hits the target alpha correctly (as it is normalised to 1.0).

It also makes sure the target alpha is hit exactly since fixed point shenanigans are a thing sometimes. Not that anybody would notice an epsilon tic of a difference.

If you spawn the monster groups (by class) separately, then the alpha will not be an issue. Another good reason to decouple and assign different new tids to the actors that are spawned (using UniqueTid, spawning, then calling the script on them). [Edit]Fixed reset to wrong renderstyle.

But one thing I am not sure about is the interaction between alpha and the SoulTrans renderstyle, so if somebody looked into that that would neat.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: [ACS] Doom 64 style fading for spawning things

Post by Nevander »

There's still a problem of new TIDs. If I ran that script with Lost Souls, Cacodemons, and Nightmare Imps (or any already translucent actor), it would get the targetalpha and renderstyle of each next call and then change the ones spawned prior. So if I spawned a normal Imp and alpha 1.0 and normal renderstyle with a new TID of 33, then spawned Nightmare Imps right after with the same new TID of 33, it would change the normal Imps properties too.

New TIDs are very important in this script because I use them for ThingCounts for map progression and knowing when to trigger scripted events, which rely on monsters being spawned. Am I right or am I severly misunderstanding your code? It's my thinking that I'd need to have different new TIDs per renderstyle (i.e. translucent actors get new TID 34, while normal actors get 33 so they are never mixed) then do a additive ThingCount of 33 AND 34 > 0 before continuing a map script.

EDIT: And I can't use UniqueTID because that will break any ThingCounts since a thing with the old TID being checked will no longer exist... god this is such a pain in the ass.

EDIT 2: FUCK. Another major problem: if I spawn a thing at a mapspot 4 for example with no new TID, then fade more in later at the same spot, I end up with duplicates spawning at 4 again since monsters dont lose their TID when dying and they are treated as a mapspot to the engine. Great. How am I going to fix this one.

EDIT 3: Okay... I think it was an easy fix, I just gave the thing to be spawned its own UniqueTID prior to being spawned but ONLY if newTID was zero, before with the old code it was getting its newTID to do the other stuff from the spawn spot ID. Big no-no apparently. I've decided to just handle these scripts by using different newTIDs for each renderstyle type. Nightmare Imps will always get their own newTID, then be added into ThingCount checks by doing ThingCount(0, tid of renderstyle normals) + ThingCount(0, tid of renderstyle translucent with alpha) > 0.

Oh by the way, it seems to respect the SoulTrans renderstyle with the way I have it coded now. It's possible the internal alpha reports as 1.0 even though in-game it shows them as translucent, so we're all good there. But I know I might run into more problems...

I do like the way you did the retrieval of alpha and renderstyle, then used the constants and fixedmul to do the fading. I will probably have to borrow that.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: [ACS] Doom 64 style fading for spawning things

Post by Nevander »

Ok I need some serious help here, I need to see or know how you could go about decoupling the original script so that I can have complete control over if I want to fade in, fade in and spawn, fade out, or fade out and remove. The problem I am having is when new TIDs come into play. Fading a thing period is simple, but when there's a new TID how would I approach it since the script above is only set up to take one TID. This thing is kicking my ass and I need to get this right before I do this on all my maps.

In some places I need to only fade the thing in and make the sound but don't change TIDs at all, then fade it out and move it, then repeat.

EDIT: I tried doing the best I could, here's what I got so far... no errors, about to test it on a map with lots of different spawning going on:

EDIT: Check OP for latest code

With that now I can potentially (like I said, not yet tested) control if I want to only fade in, fade in and spawn, fade in and spawn forced using a classname, or fade out and optionally remove.

EDIT 2: It's working but now they spawn and are at 1.0 alpha for a split second and then fade in using Thing_FadeSpawn. Wtf.
Yea... idk how I'm gonna fix this one. Everything seems right now except this, wtf do I do here?

EDIT 3: Omfg there's another problem too, even in your original code. If you fade a thing out, then fade it back in using that code, it will never fade because it gets the alpha of the thing to fade in first which is 0 because of fading it out first which obviously results in the fading in not actually fading because 0 * anything is 0. :x
Last edited by Nevander on Tue Apr 11, 2017 10:05 pm, edited 1 time in total.
User avatar
KeksDose
 
 
Posts: 595
Joined: Thu Jul 05, 2007 6:13 pm
Contact:

Re: [ACS] Doom 64 style fading for spawning things

Post by KeksDose »

That is just how getactorproperty works: On one tid, can only return one value. You had to group the monsters by tid and then either change all their tids to the same one when the script is over (delay by FADE_TICS), or check for all the tids.

Counter should start at 0, not 1, else you have 15 steps instead of 16 which results in a little bit of translucency left (like 15/16 alpha).

Also, the reason you get the tic of full alpha (that is the same problem as your other thread with the small delay!) is because you call ACS_NamedExecuteAlways. If you call a script this way, it will only take place a tic later. If you call ACS_NamedExecuteWithResult, it will be instantaneous.

The script is already decoupled.

Fade in problem is actually funny as hell. ACS cannot get base properties, so that is a problem you have to cut corners in so you are comfortable with it, like keeping an array of monster classes you would actually want to spawn and their base alpha / render style.

As a whole, in ACS, trying to have a generic solution is an insidious problem because this idea as a whole touches like everything ACS sucks at.

If you teleport things instead of activating, you can use SetActorTeleFog with a custom teleport fog. Teleport fogs store the teleported actor in their target pointer, so you can affect their alpha from there and moved the entire problem to Decorate / Zscript. With that in mind, you do not have to worry about changing tids, only keeping the correct alpha.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: [ACS] Doom 64 style fading for spawning things

Post by Nevander »

Thanks for your help with this by the way, you gave me lots of ideas already and the final library I will use will be perfect for my mod. For the alpha base property problem I ended up doing something like you suggested, I am simply getting the actor class of the TID prior to fading to determine the ending alpha. Luckily the only monster in my mod that is really affected by this is the Nightmare Imp. I need to do more testing with Lost Souls and Spectres though.

EDIT: Is there a way to get the alpha value from the transsouls cvar? I tried doing GetCVar("transsouls") but no good.

EDIT 2: For. Fucks. Sake. Another problem. I don't even know what to say. Why isn't this working now?! If I spawn a Nightmare Imp, it works. If I spawn anything else, the thing that spawns appears instantly and doesn't fade. This is getting really weird. I took out everything so it's just the fading to 1.0, ignoring all actor class checking. Spawning a Nightmare Imp works, spawning anything else and it instantly appears.

EDIT 3: I must be [censored word], I forgot to set the renderstyle to translucent before fading for some reason. I had it there before -_-
The nightmare imp was working because he is already translucent...
well after all that fail, I think I have a perfect version now, it even seems to be repsecting the transsouls cvar when fading and can even be modified after spawning

EDIT: check OP for latest code

Note this is tailored to my mod, but you could do this for the normal Doom classes too actually, just include the spectre and his renderstyles after the fade is done or just leave it at translucent for continuity.
Last edited by Nevander on Tue Apr 11, 2017 10:06 pm, edited 1 time in total.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: [ACS] Doom 64 style fading for spawning things (updated)

Post by Nevander »

New and updated method in OP.
User avatar
scalliano
Posts: 2848
Joined: Tue Jun 21, 2005 1:16 pm
Location: Ireland

Re: [ACS] Doom 64 style fading spawning things (updated 4/13

Post by scalliano »

This is stellar work and the solution for translucent enemies is much more elegant than mine. Might have to nick it ... :P
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: [ACS] Doom 64 style fading spawning things (updated 4/13

Post by Mav3r1ck »

I did a little adjustment of my own.

Add NoiseAlert(0, 0); after Thing_Activate in the code in order to spawn monsters in an alert state. This same behavior is present in Doom 64. :D

It should work for your's Nevander. I'm using the FadeIn code that Scalliano provided me a little while back.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: [ACS] Doom 64 style fading spawning things (updated 4/13

Post by Nevander »

Mav3r1ck wrote:I did a little adjustment of my own.

Add NoiseAlert(0, 0); after Thing_Activate in the code in order to spawn monsters in an alert state. This same behavior is present in Doom 64. :D

It should work for your's Nevander. I'm using the FadeIn code that Scalliano provided me a little while back.
Actually in the original game spawned monsters get alerted automatically only if they aren't set to be ambush monsters. The spawner spawns things that are spawned with the same flags as the spawner. So if you placed a thing to be a spawner and gave it the deaf flag, any thing spawned from that will be deaf. Those not set to be deaf are auto alerted due to the engine keeping track of which sectors noise was heard in. By default ZDoom stops this behavior so sound only alerts each time there is sound.

This is why in my own scripts I always do a fade in and then a manual noisealert after if they should be alerted, but there may be times where I don't want them to be alerted or shouldn't be.
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: [ACS] Doom 64 style fading spawning things (updated 4/13

Post by Mav3r1ck »

Oh, so it wasn't how I thought.

I'm having a bit of trouble. I tried using the fadein code in a unique way.

I had a script set up to where when you crossed a line it would fadein monsters and I had thing count so that after the monsters that fadein where killed more would fade in. Though for some reason the monsters that were suppose to fadein after killing the previous fadein monsters never fadein like they were suppose to in the script setup.

Any reason to why this is?
Post Reply

Return to “Resources”