Explosive relations and results (wepon scripting) dos\win

[lgb3d]

Explosive relations and results:

Explosive relations between Animated objects,
Solids and Weapons dos/windows

In this tutorial I'm going to discuss explosions,
and how to get unique responses from animated objects.
This can be an explosion generated by an animated object
or by a player's weapon.



By the end your gameplay explosion visuals might come out like this, hopefully your player doesn't need God mode
youtube.com/shorts/08p8euCFq94?feature=share



Or maybe something like this

youtube.com/shorts/AIM6nblXUy0?feature=share

I have already covered some aspects that are implemented in this
in other tutorials I strongly suggest checking them out.

As well I already covered the "solid" species enemy "4th guards"
in two separate tutorials. One that caters the windows engine
and has some aspects applicable in dos, and one that specifically
caters directly with the Dos engine and application of the
technique there.

"How to gib enemies "
This is more useful for the first release in windows
gcsarchive.proboards.com/thread/53/gib-enemies-grenade-dos-windows?page=1#post-427

"Kick him when he's down"
This caters specifically to the Dos engine and covers pygmy.ini
the AI script for enemies
gcsarchive.proboards.com/thread/60/kick-when

So in this one solid species 4th guards will be a much shorter topic,
only discussing how to send messages to them with animated objects.

In this tutorial I'm going to go step by step explaining various
pieces of the puzzle and how to tie them together.

I will use videos as reference to events and actions,
and text to explain how to implement these functions....

Although what I demonstrate here could simply be repeated..
thinking outside the box this unlocks a lot of doors
and potential with the GCS engine.

.....
.....
*****
*****
1
*****
*****
.....
.....

Let's start by getting animated object FLD to communicate
and Trigger one of the unique death sequences with a
solid species 4th guard.. as this is the most simplistic easy part.

In this example it's going to be an explosive Barrel
so I'm utilizing what I have defined in my project
as the death attribute for gibbing enemies..

So we're all familiar with Branch when shot followed by
invisible blast and a radius..

if you want an invisible blast to trigger one of the various
guard death sequences,

when it ask you for a radius instead of thanking distance
put in the death attribute number you want to achieve..
but put it in as a negative number.

For example the way I have set up my guards script
"8" is the attribute for gib death..
so I put "-8" as my radius..

when using a unique death attribute the radius is predetermined to be 500 units..
you have to get pretty creative and use other
animations and techniques to extend that radius,
we will discuss that later..

but imagine the typical fourth guard is standing near the barrel
and you shoot it, it is going to trigger
the death attribute you put in the radius.

youtu.be/2rapEhVm4-8

Here is another example with a different application where FLD animated object
sends a unique signal to a fourth scripted guard..
this example is a traveling projectile created using frame position.

youtube.com/shorts/-pWmwU154MA?feature=share

............

* The player will not react to a invisible blast with an attribute other than normal.
As well other fld animations will not react to this type signal.

So if you're expecting that Barrel to set off a chain reaction of barrels exploding,
or to have any impact on other animations.. or damage the player,
you need to follow that command with an invisible blast
with a defined radius of a positive number.

I like this because it gives the opportunity for the barrel to express to different
death sequences, so let's imagine we set the second invisible blast at a radius of 1,000 units..
any fourth guard within 500 units will gib,.
But any typical guard within a thousand units is going to have his normal
fall over dead animation as if he was hit by a Shockwave ..

.......

As well this second invisible blast is important to send signals to other animations
which we configure in their scripting to receive the specific message.

Now it gets a little more tricky but nothing too complicated.

Pick a universal register and value. In my project as an example for fld animations
that send the message of a Gib explosion to other fld animations.. I use register 5 value 1.

What I typically do in the example of an explosive Barrel once it is shot and it branches
I assign register 5 value 1, then the negative radius attribute invisible blast
to communicate with the 4th guard,.. followed by an invisible blast with a radius
that defines the range of the second blast this is "other than deadly force"
a signal which is received as a shot by other animations.

But they don't have to treat it as a shot for some animations this can simply be a signal.
Then after the signal is sent I assign register 5 back to Value 0..

.....

Let's say the second animation I want to receive this signal is FLD animated object
of a human guard who stands and shoots. I want him to gib as well just like the solid 4th guard.
The signal sent by the universal register in combination with the second normal radius type
invisible blast from the barrel animation is going to do this.

So the human FLD animated object is in a loop waiting to Branch when shot.
After he is shot he skips to the next partition of his animation.
The first frame of this uses skip next if Universal register value is not equal
to "register 5 value 1".
The frame following this "which would be skipped over if the register value was not present"
would be unconditional branch to the desired frame number
which starts the partition of animation you assign for the Gib death..

Imagining the register value is not present the next frame could be the typical
I've been shot by a gun I fall over dead.

So had register 5 value 1 been assigned,
and the invisible blast hits the human FLD animated object he now will gib..
and if he was just shot by a gun and that Universal register value is not present
he's going to skip over that unconditional branch and demonstrate the typical death scenario.

In the next video clip, the tan enemy you see standing in front of the barrels is an FLD animated object
with no frame position he just stands and shoots.

youtube.com/shorts/VNmVBz4fjaQ?feature=share

............
******

Now there's something tricky about barrels that I left out thus far.
One standing alone no problem animated human object nearby it no problem..
but a chain reaction of exploding barrels a little different story.
I will explain and describe a fix..

The barrel starts and ends it removes itself at the end of its explosion.
When it is first shot it activates a universal register,
and after the explosion has concluded it assigns the register value back to zero.

The animated enemy is in a loop, and even after being shot branches to another type of loop.

When the first Barrel explodes and its second invisible blast is set off
it triggers the next Barrel to explode. Just about the time the second Barrel
hits the point that it activates Universal register 5 value 1,
the first Barrel is hitting the point that it is assigning a value of 0 to register 5 ..

So that invisible blast jumps the animation to the next phase
but sometimes based upon how the cookie crumbles it can be hit or miss
in a heartbeat one of the other animations that's concluding will change the value to 0..
and the human FLD animation either dies a normal death not a gib death or
does what not you have programmed to occur in lieu of register 5 carrying a value of 1...

youtube.com/shorts/F9x5RV7F9g0?feature=share

youtube.com/shorts/tVdcL7sc2nE?feature=share

............

I did quite a bit of experimentation with long and short lines of barrels and various numbers of FLD enemies.
And my best results came using this technique

There are only a few frames and a few commands that are needed to make a
explosive Barrel but that does not mean we cannot incorporate extra frames
and have them hang present longer or shorter than others.

Example:
Barrel is shot..
Assign register 5 value 1 delay 2
Invisible blast radius -8 delay zero
Assign register 5 value 1 delay 2
Invisible blast radius 1,000 delay zero
Assign register 5 value 1 delay 2
Frame with no graphic delay 10
Assign register 5 value 0.. delay zero
Remove animation

Although I assigned register 5 to Value 1
one of the barrels that exploded before it could at that moment be assigning register 5 to Value 0
so throughout the period that the explosive graphic is present at every opportunity
I assign register 5 to Value 1, as well after the graphic is gone I give it a pause
to really let register five value one hang out there as long as possible,
then a couple heart beats later as quick as possible I reset register 5 back to Value 0.

So if in some case of shuffling the cards multiple animations running at once
perhaps the guard is not just standing there waiting to be shot but he's running through a loop
attacking the player branch if shot comes once every four frames so there's a little of that
register five value one time lost in that alone, and then after the animation branches to what
potentially is going to be the death scene there's a little more time hanging out there
where a prior Barrel that exploded could potentially reset register 5 to Value 0..

So in some applications and based upon your FLD enemy script or level layout this might be all right..

In my case my FLD enemies Branch when shot Loop has a system utilizing a different Universal register
and adds value to register.. let's say it's register 30 and every time he lands in that Loop
it adds a value of 1 and then returns back to his standing guard or attacking..
at the end of his Branch when shot Loop I have a skip next unless register 30 value is equal to 6.
So he would have to land there six times to meet his normal demise..

So in this unique type scenario the barrels really need to hold on to that register 5 value 1 as long
and as often as possible. Although it's absolutely critical to reset it to zero.

Another example, let's say I shot a barrel register 5 is equal to Value 1
and then I aim a gun at a FLD guard who's far away from any Barrel currently exploding.
Since register 5 is carrying a value of 1.. anything that would cause him to Branch when shot
is going to result in his r5 v1 path..

So yes I am trying to get register five back to a value of zero as quick as possible
but not as often as possible, in consideration of the number of frames other animations
might be cycling through relying on that signal being true.

So yes barrels easy, fld guard receiving multiple death outcomes more or less easy.
But FLD guard requiring multiple shots for normal death,
and requiring a universal register signal to be present for a gib means in some cases
if the cards aren't stacked right he might be standing next to a barrel and not die..
or as mine is scripted too demonstrate a little pain and add one to the value that must total six before he falls.

.....


In the grand scheme of things this is not some big downfall or a broken game
if for some reason the explosive Barrel misfires sending it "value" signal to an FLD enemy
while in a chain reaction of barrels..

Regardless they work perfect Chain Reaction or standing alone with solid 4th guards..
and if for some reason you were specifically going to put an FLD guard next to a barrel
for visual effect storytelling or just to demonstrate to the player how the barrels work,
avoid putting him next to a long chain of barrels..

then some Barrel that exploded one or two seconds before is not going to be altering the
reg value necessary for the Gib portion of the animation.

And in the grand scheme of things thinking out side the box...

you could utilize solo "barrels" or what not to trigger other animations using the above describe technique
but not employing a chain reaction of barrels or explosives.

Let's say there's an animation of a brick wall with a branch when shot.
If Universal register 5 is not equal to 1 it has an unconditional Branch back to frame 0.
So shooting it with a gun the graphic is never going to change..
but you put a propane tank or a barrel "something that will explode"
and assign register 5 value 1 right next to that wall.

The player is not expecting the wall to explode and be able to walk through it
he has shot a guard and shot that wall behind the guard but when he turns at a different angle
and shoots the propane tank beside that wall.. then when the wall branches through its Loop reg val present
bricks falling and removes itself from the universe and the player can now walk through.

So yes the Chain Reaction explosions with the barrels works 99% of the time
and can be scripted to interact with other flds, but our Level design and planning
are critical to it being functional, and not coming off like why did that explosion not kill that guy?
As it killed everyone else?

..........
breather...
...........

So that is step one of this, scripting animations "explosions" to communicate with other..

Solid 4th species guards being triggered by a an invisible blast
with a negative death attribute number as a radius

And fld animations through the use of a universal register value and invisible blast as a signal

And trying to keep chain reaction explosive animations from overlapping
and at times canceling out the signal they send to FLD animations..
*I would say the best technique there is not employ a chain reaction of explosions
to determine the outcome of fld animation, Place both accordingly to their functionality

And as creative as we can get with animations making them appear disappear and do whatever is in our imagination,
this is definitely a really cool trick.

.....
.....
*****
*****
2
*****
*****
.....
.....

Although I already discussed it a little, let's look at FLD animation receiving signals..

The signal is the universal register carrying a value, and the messanger is an invisible blast.
Although we can send signals to FLD animations other creative ways
here we are imagining shooting blowing up catching on fire destructive things.
So the invisible blast is a great tool, it occurs and disappears.
When it occurs it can harm the player solidifying that there's some dangerous interaction occurring.

So those animations receiving the signal.. can be scripted utilizing a command saying
"skip next if the register value is not equal" to your defined signal utilizing skip next
"if not" that means anytime this is true it will encounter the next frame.
And here is where we place and unconditional branch that will direct the animation to the
frames that demonstrate what we desire to occur when the signal is received.

So as the animation starts, and any point in the animation where the animation could be shot,
we always use Branch with shot but to the first frame of the series of conditions and commands.
So our script can verify what conditions are present and react accordingly.

As the script needs to determine what the signal is relatively quick and run through a few lines to verify..
I like using delay time zero through this check and balance portion of the script that is encountered after
any branch when shot command.

So as described above I am using register 5 value 1 for a Gib death. But as my game is incorporating fire as well,
I'm utilizing register 5 value 2 to represent the signal for fire. If neither of these two conditions are true
the animation will carry on to images of either the guard being wounded by Bullet fire, or simply dying.
With my human type guards I'm utilizing a counter system so the player cannot kill these type
animations with a single shot from a bullet type gun.

Add value to register is employed. I typically place this after the script checked to see if a register
carries a value.. As example if I put that add value before it checked for what blast type "value",
The next FLD animated guard utilizing the same counter setup would already have one point against him.

In the following video you can see where I learned this lesson.

youtube.com/shorts/V_JHu4507j0?feature=share

So this enemy type when injured adds a value of 1 to register 30..
for him to die of bullet wounds, he would need register 30 to have a value of 6.

The first guard dies from bullet fire when he dies it resets register 30 to Value zero.

Then I throw a grenade two guards react to it, one who gibs.. so register 30 is now equal to 2..

I throw another grenade, guard reacts to it and Gibbs now register 30 is value 3

I throw another grenade, which must have been well placed because three guards react to it.
Two of whom gib.. but since there were three more reactions
and me placing add value to register at the start of the injury cycle before checking for Signal type..
register 30 is equal to 6, so the guard on the farthest right did not gib but fell dead as if he was shot by a gun.

As well at this point in the script development I believe they had a delay of 1 on every other frame
through the injury Loop, meaning a few of these animations were missing the instant Gib,
and continuing through their loop as they were not receiving the signal at the instant it was sent.
And in this way the third Guard from the left was able to add to points to the register value
from two separate grenade explosions..

This is the polar opposite of what we were trying to do with the barrel by continually
assigning register 5 value 1. We're not sending out a signal, we're trying to receive
it as quickly as possible so let those frame cycle as fast as possible..
that way when the correct condition is present you're 90% plus probable that your animation
is going to be catching the signal at the right frame.

I hope that Visual and me speaking from my experience helps others write their Scripts
tight so 90 plus percent of the time you will get your desired outcome.
...

in case of animations using add value to register so it requires multiple bullet shots to kill..

At the end of the injured guard Loop would be a condition again using skipnext if not equal.
The following frame would be unconditional branch to a partition that demonstrates the final
demise of a guard caused by Bullet fire. And if that frame is skipped it Loops back
either to the start of the animation or I prefer the attack portion as the guard has been alerted
and he is going to return fire.

Yada yada yada you get the point..

.....

With this specific human type FLD animated guard I went a couple steps further to flex GCS capabilities,
and make the game a little more visually stimulating or entertaining..

If the guard is standing you can shoot him, or you can blow him up.. or you can set fire to him.

If he is on his knees caught on fire you can still shoot him to death, as well you can still blow him up.

If he is shot to death and on the ground, you can still blow him up or catch him on fire.

If he is not on his knees,.. but lying dead on the ground and caught on fire. You can still shoot him to death or gib him..

If he is laying dead on the ground due to gunfire no further gunfire will affect him..

If his body has exploded and he's laying Gib puddle on the ground, no attack of any type will affect him.

The funny loophole in this design, when he is dead on the ground you can catch him on fire,
and then shoot him to death, and then catch him on fire again and shoot him to death..
not that people would intentionally be doing that or that it would stand out too horribly..

I did not include the ability to catch a gibbed body on fire, thats just a little too much
and by the end of this I only had one frame left using the GUI gcs animation maker..

The following video will demonstrate a FLD animation capable of receiving multiple signal types in various ways.
I think it comes off pretty slick.

youtu.be/FpJF3CZPSP4

That video is a little tease of what's coming up next here keep reading

.......

So we have discussed

FLD animations able to communicate death attribute type with solid 4th scripted enemies

FLD animations being scripted to send specific signals

FLD animations being scripted to receive specific signals



.....
.....
*****
*****
3
*****
*****
.....
.....


.......
now lets cover a different way to interact with all of the above based upon player input..
a little opener here to help explain what how and why
......

This section is going to be a bit different,
some of what I'm going to discuss has been visible in Prior videos in this thread.
The part that's not going to be different I'm going to get long winded trying to explain it..

...

I was trying to figure out how the fire extinguisher worked in terminal terror..
assuming I could send Universal register signals from weapons,
thus making each weapon potentially have a unique interaction with animated objects..

When "Chris" recently shared a document that is in reference to gcsp...

*I swear I've read some of this somewhere else, wish I could get my hands on the full text...
maybe I do, might be included in the final 3+ manuel*

Various parts of the document are easily applied to the original GCS dos engine..

There's a section in it that talks about how to script FLD animations,
not using the GUI but solely through text.

That section of this document absolutely Priceless to understanding what
all the unique numbers are in weapon FLD text documents..

In machine gun text, they give us a brief description of how the weapon FLD animation text works
and explain there's some special commands that can be put in the column which is typically
the frame wait time, and they say these numbers or commands ">255" are illegal delay times
which result in the delay function being used to send different types of commands.
Some which utilize the following column to control a specific variable in the command.
They refer to features of the machine gun text as well as shotgun text to demonstrate
different triggers loops and a couple of the illegal delay times..

Long story short, the GCS P text fills in about 99% of the blanks..

If anybody read my flamethrower thread I was real hung up on this illegal delay time of 515 or what not..
that 515 is a command for branch when shot the following column tells what frame number to jump to..

I'm still not able to fully grasp how they pull that off in terminal terror..
but I definitely have some ideas, and the applications they were employing were more
geared toward users of gcsp. If I ever do figure it out I will surely let you all know..

Moral of the story I discovered a lot about weapon scripting and how to pull off a very similar
technique with the stock dos GCS engine v 1.13.

As well since I took this breather from my Windows project and allowed myself
to get so sidetracked with the Dos GCS, fine-tuning my education on it..
I'm going to be able to employ a lot of this and make my windows game better
than it would be if I had not stepped back to the Dos GCS..

Here I go I'm going to spill the beans and try not to confuse anybody doing so

...............
...............

All of these features do not work with weapon animation such as the visual of your gun on the screen
or your kicking boot . Some do but not all.

So let's forget about those flds, for now..

Where these scripting techniques will be employed is in
the explosion that occurs after projectiles enter the 3D World.

The projectile is either the grenade the gas grenade or the rocket
and no we are not able to alter them..
although that gcsp txt gave a lot of information that made me feel
I was extremely close to that I'm yet to figure it out,

What we are going to be working with is the explosions that occurs and result from these projectiles..

Just like our animated FLD objects these explosions
are imported and occur at coordinates on the map.
But these are placed during gameplay by the player,
and land at their final destination based upon predetermined physics.
For example a rocket continues in a straight line until it hits a solid..

.......

Now I am going to go about telling you how to apply this,
and try to bring some Simplicity to the confusion of columns and rows of numbers.

I am going to use a variety of "my" FLD.txt Scripts to demonstrate and explain what is occurring,

If somebody wanted to use these simply by cutting and pasting, that would work..
but watch out for the handle numbers, some of them are associated with existing images
and have been set out of the normal sequence, and if I remember right I created a couple new handle numbers.
as well a portion of this thread will discuss spawning new animations, those handle numbers will only work for me..

So I guarantee these texts will work but if somebody's cutting and pasting them into their project
and if they have any problem I would gamble money the problem is a result of a conflict
with the handle numbers in my script compared to those present in your weapdef.txt or object.txt.

*********
.........
.........
Here is an outline of how the explosion FLD text should be read, what the separate columns represent...
.......
.......
********

; The format of the entry is the following columns The last animation
; frame MUST have a species type of -1. This marks the end of the animation
; file.
;
; Species - Use this species object this frame
; Handle - Use this handle object this frame
; Absolute x - add this constant to object's x coord this frame
; absolute y - add this constant to object's y coord this frame
; absolute z - add this constant to object's z coord this frame
; absolute theta - add this constant to object's th coord this frame
; ***command*256+waitcount - wait .08* this # seconds, merged with command***
; ***frame# - various parameters stored here, depending...***
; relative x - Amount to slip object away from observer this frm
; relative y - Amount object should slip to the right this frm


; Absolute x,y,z,th are used for objects which you want to move about in the
; universe like a buzzing fly. The motion of the object will remain the same
; regardless of position or viewing angle of the observer.

; relative x moves the object away from or closer to the observer, and
; relative y moves the object to the left and right as the observer looks.
; Thus if the player is looking north, then rel-y motion will make the
; animated object appear to move east.
; If the player is looking west, then the animated object will appear to
; move to the north.
; In both cases the animated object moves to the right as far as the
; player is concerned

************
************
************
...........
........

For this tutorial the important column is the command or wait count..
so we will mainly be focusing on the 7th and 8th columns,
here is a detailed description of command numbers which can be applied
in the 7th column. Utilizing this system we can do anything we could
with the GUI animation tool in the editor, but we can do a few more cool
tricks that we cannot in the editor. The important part about these
command numbers is that they are multiplied by 256 before we put them in
the 7th column.

Example if we want to use command number 2... we put 2x256="512"..
512 is the number that goes into 7th column,
and if there are further conditions or directions for that command
we place them in the 8th column..

......
......
*********
*********
*********

Waitcount specifies how long that frame should be displayed before
; moving on to the next frame. Waitcount can take on values from (0-255)
; A waitcount of 0 makes the animated object proceed to the next frame
; with no chance of repeating the current frame.
; A waitcount of 25 makes the computer repeat the current frame until
; approx 2 seconds have passed. This corresponds to 10 frames on a slow
; computer, and about 28 frames on a fast one. This shows that waitcount
; is reasonably machine independent. In general use waitcounts of 2-3,
; and longer ones for pauses in the motion. Use 0 if you really want the
; animation to proceed as fast as possible. Beware, though. Waitcounts
; zero make motion fly by too fast on Pentiums's!

; Command specifies if any special command should be executed. Command
; of 0 just means plod along to the next frame if waitcount is expired.
; Command of 1 means uncondition jump to another frame. Thus you can
; do cyclic loops by giving command 1, and frame# 0 to go back to the
; beginning of the frame list. Of course you can loop to any frame
; number you like.
; Command 2 means jump to the specified frame when shot at. For a
; soldier for instance, you want to be in a cyclic loop shooting or
; whatever you want the live guard to do. Then upon being shot at,
; then jump into the death sequence. Terminate the death sequence
; with an infinite loop which is stuck on the last frame of the death.
; Command 4 means xform us to a new type of object. In this case the
; frm# field contains the handle # of the fluid file to xform into.
; Command 8 means trigger an invisible blast on this frame. Guards
; with a radius of 800 units are killed, you are damaged if to close.
; you can leave a 0 in the frame #, which will give a 500 radius unit blast
; or you can put a positive number in there for blast radius
; or you can put a negative number in there for blast attribute
; The most common would be -8 for knockout blast or -2 for tear gas
; Command 16 means remove this object from the universe. 16*256= 4096
; Command 17 adds value to univ reg#. (4352) Very similar to command 81
; Command 18 jumps if human comes within a radius of 160 to the object's
; Drawing!
; Command 19 turns the lights on
; Command 20 allows the fluid's attribute status bits to change
; Command 21 Allows a fluid file to cause a warp to a different level
; Command 22 causes damage 0-319 in frame field irregardless of player's loc.
; Command 23 plays sound # in frame (5888)
; command 32 means to pulse the palette to the blues. Use this wherever
; you have electrice bolts near.
; command 33 skips the next frame if the reguster does *not* equal the value
; ( very close to command 82, except logical reverse ) (8448)
; Command 64 turns off generator sound (16384)
; Command 65 jump to frame if night
; Command 66 jump to frame if day
; Command 67 make generator sound (17152)
; frame# had constant sound # 0,1,2 for generator, helicopter, water
; Command 68 makes the fluid create another fluid object, with the
; the object handle of the new object to be created is taken from the
; frame number. The classic example of this is the smoke puffs created
; by the running generator.
; Command 69 jumps the specified frame if no living guards in universe (17664)
; Command 70 sets the remote control flag to the frame value
; Command 71 skips if the user is within abs() radius of the frame field
; Command 80 lets the player be invincible for FRAME# of seconds
; Command 81 sets the inter-univ communication register (20736)
; The frame number is used to specify the register and the value
; The register# * 256 + value. Reg and value are 0-255
; Command 81 sets a univ variable to a value. Reg#*256+value Frm# (20736)
; Command 82 skips the next instruction if reg = value. See below. (20992)
; Command 83 puts up the string of the # in the frame # in a box. (21248)
; Command 84 changes the floor texture to a the handle in the frame #.(21504)
; Command 85 sets lighting register in frame# >> 12 to frame# & 0x0fff (21760)
; Command 86 changes the current universe attribute to frame# (22016)

***********
***********
***********
........
........


So that is a bunch more info than I'm going to use in this step of the tutorial,
but anybody reading this understands now the amount of possibilities..
the player can have dramatic influence in the game with a well scripted explosion from a weapon,..
as well can use "many" of these comands for the basic weapon animations

Here is a link to the full text I cut those two sections from..
this text goes into all sorts of aspects which would apply with gcsp
as well some features that can be employed with various other versions of the GCS
..........

web.archive.org/web/20030101134328/http://www.pieskysoft.org/man30_html/engine.html

.........
.........
***FINAL PART***
.........
.........

.....
.....
*****
*****
A
*****
*****
.....
.....


Sending signals to FLD animated enemies and objects
as well as solid 4th guards,...
with explosions created by player!

...

Here is a random example of this occurring

youtube.com/shorts/BqipisKMg_4?feature=share

Same as other animations to do this we are going to assign a value to a register
and utilize an invisible blast... but instead of using the GCS engines GUI animator
we are going to do this in plain text, learning more about weapon scripting.

It is important as this animation will interact with solid 4th scripted guards to utilize
the negative death attribute number before a positive radius invisible blast,
so they will have the desired reaction, and FLD animated enemies and objects
will not react to that signal so the second signal cater specifically to them.

To do so first we must set the register value for desired fld animations outcome,
and communicate to the engine that is what we are doing.
So in the 7th column we are going to utilize command "81".

81x256=20736.. so by placing "20736" in the 7th column
the engine knows we are going to assign a value to the register.

In the 8th column we are going to communicate what register and what value

Rx256+v= column 8. Example I want to assign the value of 5 to register 10..
10x256+5 = 2565.. so "2565" is the number we put in the 8th column..

I just wanted to spell that out, that's a good example of how this math and system work,..
so with the notes from gcsp and my FLD weapon script notes..
I will explain the rest of how to send a unique signal to an FLD animated object or enemy
with an explosion from players weapon.

I don't know if I've already mentioned it but utilizing two different blast types
in an explosion makes for cool effects with solid 4th guards..

Although that second blast with a traditional radius works as the carrier of the signal for Fld animations..
this impacts solid 4th guards who are not within the 500 unit radius of the negative death attribute blast,
but the second traditional invisible blast radius.
Giving the effect that those closest to the explosion Gib,
but those little further away are killed by the Shockwave.

this video demonstrates it pretty good

youtube.com/shorts/xKk6N4BDoLA?feature=share

So just as much as using this dual invisible blast assist when
sending a signal to an FLD animated object, it makes for more
interesting outcomes with solid 4th scripted guards.


********example basic explosion*****
this is just a random script for "fldexpp.txt" I saved along the way

; EXPLOSION gib
;S T X Y Z T C+W # X Y FR

;S T X Y Z T C+W # X Y FR
;2 2980 0 0 -32 0 0 0 0 0 ;0
;2 2981 0 0 -64 0 20736 1281 0 0 ;1 r5 v1
;2 2985 0 0 -96 0 5120 260 0 0 ;2 alow atrb to change
;2 2984 0 0 -128 0 2818 -8 0 0 ;3 -8 gib atrb
;2 2982 0 0 -200 0 2050 -2 0 0 ;4 -2 fire atrb
;2 2985 0 0 -96 0 0 0 0 0 ;5
;2 2984 0 0 -128 0 2050 -2 0 0 ;6 -2 fire atrb
;2 2982 0 0 -200 0 2818 0 0 0 ;7 second wav
;2 2983 0 0 -200 0 2048 1500 0 0 ;8 normal blast 1500 radius
;2 2000 0 0 0 0 10 0 0 0 ;9 delay 0.8 of 10 sec
;2 2000 0 0 0 0 20736 1280 0 0 ;10 r5 v0
;2 2000 0 0 0 0 4100 3 0 0 ;11 remove
;-1 0 0 0 0 0 0 0 0 0 0

frame
0
1 assign r5 v1
2 alow atrb to change
3 -8 gib atrb, 2818 comand 11 blast with sound
4 -2 fire atrb, 2050 command 8 blast with no sound
5
6 -2 fire atrb, 2050 command 8 blast with no sound
7 second wav, blast with sound but no radius
8 normal blast 1500 radius command 8 no sound
9 delay 0.8 of 10 sec based on comp speed
10 assign r5 v0
11 remove animation

pretty simple one.. you might see some of my videos where now
and then guards walking tward an explosion just after other gib
suddnley catch fire then are knoced dead by the next blast with
positive radius.. thats what is going on here..

all you really need is a neg death attribue blast and a
normal blast..

another note.. command 11 2818 invisable blast.. always plays
wav file of explosion, its pre defined.. so if you have altered
your sounds.txt this will play different sound.

so more or less you assign a register,
have a blast with neg death attribue,
then a normal blast greater than 500 units,
then a short pause...to ensure the ur haings for a sec,
then reset reg value to 0


.....
.....
*****
*****
B
*****
*****
.....
.....


..........
next type
looping animation
..........

this is an erly expermint with my fire bomb
6 3609 fldexpg.txt will always make player vision hazy..
that will no longer occur if you remove object
by using command 16 "4100" at the end.. and you can
bring it to an end how ever you please..
later examples will demonstrate ways to do so.

;FIRE BOMB catches 4th and fld animations on fire u5 r2..
;S T X Y Z T C+W # X Y FR
;2 2990 0 0 -500 0 0 0 0 0 ;0
;2 2991 0 0 -500 0 20736 1282 0 0 ;1
;2 2995 0 0 -500 0 5120 260 0 0 ;2
;2 2994 0 0 -500 0 2818 -2 0 0 ;3
;2 2992 0 0 -500 0 2048 1500 0 0 ;4
;2 2993 0 0 -500 0 20736 1280 0 0 ;5
;2 2992 0 0 -500 0 2562 -2 0 0 ;6
;2 2994 0 0 -500 0 2 0 0 0 ;7
;2 2995 0 0 -500 0 2 0 0 0 ;8
;2 2990 0 0 -500 0 260 6 0 0 ;9

fame
1 assign reg 5 value 2
2 allows attribue to change
3 negitive death attribue "-2" fire
4 normal blast 1500 unit radius
5 assign reg 5 value 0
6 negitive death attribue "-2" fire
9 loop back to frame 6

the loop back to frame 6 lands on invisable blast that will
catch mobil 4th gards on fire, and it keeps cycling
frame 6 - 9 so the handle graphics animate the fire.

the 2028 blast at frame 4 will kill guards who caught fire before that point.

every time you throw one of these they keep looping, so you can fill
a room with fire, but it dose not only stop enemies..
the player can block his own path using too many of these..



.....
.....
*****
*****
C
*****
*****

.....
.....
........
........
next types of examples
........
........



.....
.....
*****
!!!!Spawning animated objects from a explosion FLD's!!!!
*****
.....
.....

This technique is a bit more tricky and I'm going to be prolific and long-winded
explaining what's going on..

getting the animation handle numbers and keeping them uniform
throughout the game is going to be the difficult part..

*if you want to do something like this it is easier to do it when you start a project,..
I built half my game then discovered this, and it made it difficult to get the
animation handle numbers consistant in all my levels..

This video is a bit Goofy but demonstrates an animated object
from the world "level" object.txt, being commanded to spawn into the level
at the same coordinates as where the explosion occurred.

youtube.com/shorts/GHNtLCXa_HM?feature=share

Literally that's pretty goofy and it causes an insane chain reaction with multiple animations,
it was my first experiment with this command and it got me to thinking..

The way I have been scripting my explosion animations..
I send out an invisible blast with a negative attribute number so solid 4th enemies received the signal,
as well a universal register and invisible blast so FLD animations receive a signal.

The normal invisible blast which is used to communicate with other FLD animations
is capable of having a user-defined blast radius..
but the invisible blast with a negative death attribute number has a
maximum and minimum blast radius predetermined by the engine as 500 units.

So I was thinking to myself if I make an animation using the GCS GUI,
I can set the frame position and the frame reference point is where
it will spawn when called by an explosion animation.

As well applying that now if I wanted to still use invisible blast
with a negative attribute number I can increase that blast radius
as now in that event I have other animation spawn at a
further point from the origin sending the same signal..

Catching what I'm pitching we can make pretty interesting blast patterns this way,
as well send a variety of signals at different points around an explosion animation..

***Important,..
The animation you will be calling on "spawning" in to your level/game...
must be in your objects txt.. and have a handle # "objdef**.txt"..
to get it in objdef.txt it must be placed in your level..
And for it to work in your game, it must have the same handle # on all levels..

Easies way to do this is make it step 1 when you start a new project..

if that not you and you have started building your game/levels alread..

check all your objdef files.. you will find the animations at the botom of the document..

it will read something like this

(6 108 GDSWTCH.2)

6 is the species
108 is handle #
name of file . level number

ok.. the important part is the handle number..

we can not edit this txt, the engine writes it..

even if you delete a animation and it falls off the objdef.txt..
the handle #s keep growing..

so looking at all your levels objdef.txt, find the highest animation handle #

on that level place the animations you want spawn with your explosion

test the level, then check objdef*.txt.. make note of the handle #s

then back track to other levels.. you will need to place fld animations
in the level to increse the handle numbers. placing 10 of the same will not
increse the handles more than 1.

so if your higese handle number is 10 and you need to get to 20,
place 9 fld animations that are not on the level yet..
you can delete them after you increse the objdef handle #..

if you have 4 unique animations in you libary
and need to get from 10 to 18.
and want to land your desired file on handle #18
you can place 4 test level,
delete the 4 you placed, test level..
place 3, test level...
and that will get the handle # to 17.
when you return to editor the next animation you place will be handle #18
so make sure you click on the right file..

if your handle #s are low, and you have not used a bunch of animations
this is not a big head ach... but if your like me, and tested 100+ amimations
on a few levels, this can be a headach getting a level with a low handle count
up to the right number.

the important part is to keep these
weapon aux related handle#s uniform through out the game.

if your not deep in your game, or are starting a new one this is easy..
but be warned, if you want to add this to a project you been working
on and have more levels than fingers on your hands,..
this is a rainy day project from hell..

but it sure feels good when its done

just thought I would mention that.. its Important..

unless your making a single level game.

***Important... tip of the wise

if you do have these imported, and placed in the levels..
handle numbers are perfect and for some reason you need to change
the animation or graphics...

leave it on your level dont delete it.. go to import modify..
click remove.. then go to modify, same file name..
after changes save as same file name and import..

this way it will keep the same handle # and it wont be a big headach to tweek with them..

Im imploying 12 of these animations,.. so editing them all is headach enough,
without having to update the handle number.


....

Examples of explosions that spawn more animations
...


.....
Basic explosion, with Rising mushroom cloud.. and four directional spread
.....

This is my basic Gib explosion, watch in the script where I change the elevation,
so the cloud Rises. As well I spawn four animations of explosions.
They are placed to the north south east and west of the epicenter of the Main blast..

as was explained toward the start of this thread,
an invisible blast where we used the neg death attribute we are trying to achieve
in lieu of radius always results with a predetermined 500 unit blast radius.
So this example is an out-of-the-box way to continue the same death attribute blast at a greater radius...

So if the initial blast gives us a 500 unit radius,
and using frame positioning when creating the animations
that will be spawned the reference point being the epicenter of the main blast
and I move them 400 units from the reference point at which point they have a 500 unit radius..
I've extended the negative death attribute blast radius to 900 units..

There still are small slices of pie between the defined Outer Perimeter of the radius
created by these four auxiliary blast, as well the main animations invisible blast radius
is just a little further. So if enemies wind up in those regions they do not gib..
and appear insted to have died from the shock wave of the blast.. or what not occurs at the moment they are there

Here are a few visual examples showing the radius beyond 500 units for my Gib
as well as the four axillary explosions spawned by the main explosion.

Check the radius on the first explosion, quite a bit of range.
Then the visual effect of the second explosion occurring behind the boxes,
it wouldn't have the same appeal with a single animation occuring

youtube.com/shorts/_9ItyUVTBxo?feature=share

Here you can see the difference from being Square with the explosion
versus viewing it from an angle. Based upon the players position,
it gives each explosion a little more character

youtube.com/shorts/cx3MPM8zj0o?feature=share

This video shows it being employed in a unique feature of level layout..
does it make 100% sense, not exactly..
does it make the game play a feminine hair more interesting sure

youtube.com/shorts/BqipisKMg_4?feature=share

So it visually appears different from various angles,
looks cool when it happens half exposed behind some boxes or behind a corner,
and definitely spreads the negative death attribute radius.

And this is what the script consist of.

*****************
; EXPLOSION gib with north south east and west expansion exp animations..
;5 explosions spreads -8 death flag blast beyond 500 unit base radius.
;S T X Y Z T C+W # X Y FR
2 2000 0 0 0 0 20736 1281 0 0 ;0
2 2980 0 0 -32 0 5120 260 0 0 ;1
2 2981 0 0 -64 0 17408 126 0 0 ;2
2 2985 0 0 -96 0 17408 127 0 0 ;3
2 2984 0 0 -128 0 17408 128 0 0 ;4
2 2982 0 0 -200 0 17408 129 0 0 ;5
2 2983 0 0 -300 0 2818 -8 0 0 ;6
2 2983 0 0 -350 0 20736 1281 0 0 ;7
2 2983 0 0 -400 0 2048 1500 0 0 ;8
2 2983 0 0 -500 0 2818 0 0 0 ;9
2 2983 0 0 -600 0 3 0 0 0 ;10
2 2000 0 0 0 0 10 0 0 0 ;11
2 2000 0 0 0 0 20736 1280 0 0 ;12
2 2000 0 0 0 0 4100 3 0 0 ;13
-1 0 0 0 0 0 0 0 0 0 0

************************

frame #
0 assign reg 5 v 1
1 allow attribute to change
2 "17408"=command 68 spawn animation,.."126" handle# of one of my animations *north
3 "ditto but different fld" *south
4 "ditto but different fld" *east
5 "ditto but different fld" *west
6 2818 blast with sound -8 death attribute 500 unit radius
7 assign reg 5 v1 "incase barrel or prior explosion reset r5 v0" "rapid fire rocket?"
8 normal blast 1500 units
9 blast no radius plays boom sound
10 "3" pause for a hair over 2 seconds
11 "2000" no image "10" delay to ensure reg 5 v 1 is true for fld animations..
12 assign reg 5 v 0 ....
13 4100 remove this animation...

*important .. based on the animation to be spawned..

mine assign reg 5 val 1.. but they do not clear val back to 0..
if they did so.. there is a chance that they might set v0 when I need it 1..

as discribed before.. more activation less deactivation.. less problems.

so in my application the delay at the end of the explosion insures everything
that is going to happen has happened.. and it resets reg 5 v1 to v0.. ok..

so to get the, animations you want to spawn, handle #s they must be objects in the world,
then they will apear in object.txt.. ok..

to reduce complication, my extra explosion animations simply go off..
so when i test a level the first thing when it loads they explode..
thus reg 5 v 1 is already present...

To fix this... i put a 200x200 platform at the location the player warps in to the level.
So as soon as level loads that platformis reseting r5 to v0...


*important "z" a negitive number is rising verticaly, greater positive number drops lower..
the # is from horizontal center of your image.. so if you image size is 1000x1000
-500 would make its botom meet the floor, -600 would = z 100... so the z # really needs to
be ballanced based on your graphics defined size in weapon def.. ok..

as for the z of the animation handles being spawned...
if you used frame position creating them.. they will spawn at that height except
now its there horizontal center line they are measured by.. so if my animation graphics
were 100x100 and i set it at z 0 then when it enters it will be -50.. got it? ;p

if animation you are spawning dose not have frame position.. then it will be spawned
at the height defined in the frame that calls them.. think.. the video of the barrel spawning flames.
negitive z = up so if my frame z was -500 then the barel is going to be more or less entering at height
of 500.. i have not done acreate measurement of this.. but more or less thats the idea..

re watch the funky spawn barrel video.. i did not tell it to merge at that hight
how did it get there? I did not predetermine a height so it pulled from the frame z.

ok..

so if making an animation specificly to be spawned in this manner, make sure to
set frame position, and add twice the height as a positive number for the z.
so when it is called on by your explosion it should be flat with the ground..

this will help if your trying to get them to apear at a specific height..
like if you were aiming for 350 z, now you got an idea how to get it there when your
explosion calls it

I hope this all makes sence.. Im sure Im all over the place.. trying to go step 123..
but it probley reads 1.4.8.2.3.6.5.7. ;p


************
************
next up
......
Fire bomb , with three phases of loops, and spawned auxiliary flame animations
......
**********
***********

I could polish this by creating a couple more graphics,
to demonstrate why the fire spreads..
or have the smaller fires spawn in the first phase..
but for this tutorial these videos shows enough explain the scripting.

This video shows single application

youtube.com/shorts/vlDoZTfQ_o4?feature=share

This video shows multiple fire bombs thrown,
but far enough apart in timing that they all run through their cycle

youtube.com/shorts/c-t2wyYqQ3Y?feature=share

This video shows multiple fire bombs thrown,
but close enough in timing that when running through their counting system
they get hung or paused in one of the three phases.
Doing so creates an impenetrable wall of Fire,...

youtube.com/shorts/AIM6nblXUy0?feature=share

in the fire bomb script I included a branch if shot
that will skip it to the next phase of its animation.
So if more invisible of blast occur within the vicinity
or if the player engages combat in the vicinity the fires eventually go out.

this one reads heavy, but if you understood what came before, its pretty simple,
just a couple more moving parts and two new tricks. ;p

so im only going to explane whats different wit this one.


*************
*************
*************
;FIRE BOMB spawns 8 directions of smaller fires
;S T X Y Z T C+W # X Y FR
2 2990 0 0 -400 0 0 0 0 0 ;0
2 2991 0 0 -400 0 20736 1282 0 0 ;1 assign value. r5 v2
2 2992 0 0 -400 0 5120 260 0 0 ;2 allow attribute to change
2 2991 0 0 -400 0 2818 -2 0 0 ;3 blast with sound attribute value -2 fire
2 2990 0 0 -400 0 2048 1000 0 0 ;4 normal blast 1000 radius
2 2991 0 0 -400 0 2562 -2 0 0 ;5 blast attribute value -2 fire
2 2992 0 0 -400 0 4352 1025 0 0 ;6 add value to register r4 v1
2 2991 0 0 -400 0 512 10 0 0 ;7 skip to frame 10 if shot
2 2990 0 0 -400 0 20992 1028 0 0 ;8 skip next if r4 = v4
2 2991 0 0 -400 0 256 5 0 0 ;9 loop back to frame 5
2 2993 0 0 -250 0 20736 1280 0 0 ;10 assign value r5 v0
2 2994 0 0 -250 0 17408 134 0 0 ;11 import animation 134
2 2995 0 0 -250 0 17408 135 0 0 ;12 import animation 135
2 2994 0 0 -250 0 17408 136 0 0 ;13 import animation 136
2 2993 0 0 -250 0 17408 137 0 0 ;14 import animation 137
2 2994 0 0 -250 0 17408 140 0 0 ;15 import animation 134
2 2995 0 0 -250 0 17408 141 0 0 ;16 import animation 135
2 2994 0 0 -250 0 17408 142 0 0 ;17 import animation 136
2 2993 0 0 -250 0 17408 143 0 0 ;18 import animation 137
2 2994 0 0 -250 0 20736 1024 0 0 ;19 assign value r4 v0
2 2995 0 0 -250 0 5120 260 0 0 ;20
2 2994 0 0 -250 0 0 0 0 0 ;21
2 2993 0 0 -250 0 4352 769 0 0 ;22 add value to register r3 v1
2 2994 0 0 -250 0 0 0 0 0 ;23
2 2995 0 0 -250 0 512 28 0 0 ;24 skip to frame 28 if shot
2 2994 0 0 -250 0 2048 -2 0 0 ;25 blast attribute value -2 fire
2 2993 0 0 -250 0 20992 773 0 0 ;26 skip next if r3 = v5
2 2994 0 0 -250 0 256 22 0 0 ;27 loop back to frame 22
2 2996 0 0 -125 0 20736 768 0 0 ;28 assign value r3 v0
2 2997 0 0 -125 0 4352 513 0 0 ;29 add value to register r2 v1
2 2998 0 0 -125 0 0 0 0 0 ;31
2 2997 0 0 -125 0 512 35 0 0 ;32 skip to frame 35 if shot
2 2996 0 0 -125 0 20992 516 0 0 ;33 skip next if r2 = v4
2 2997 0 0 -125 0 256 29 0 0 ;34 loop back to frame 29
2 2000 0 0 -125 0 20736 1024 0 0 ;35 asign value to register r4 v0
2 2000 0 0 -125 0 20736 768 0 0 ;36 asign value to register r3 v0
2 2000 0 0 -125 0 20736 512 0 0 ;37 asign value to register r2 v0
2 2000 0 0 -125 0 4096 0 0 0 ;38 remove animation
-1 0 0 0 0 0 0 0 0 0 0

******
*******
******

so this one starts out doing the same at others, but different ur and neg atrb
then...

frame
6 "4352" com 17 add value to reg, 1025 r4 v1
7 "512" com 2 branch if shot, to frame 10
8 "20992" com 82 skip next if rv= "1028" r4v4
9 256 com 1 unconditional branch to frame 5

...........

so in this you can see my
first phase timer is u4
second phase timer is u3
Third phase timer is u2

i use a 4 or 5 count to jump..
so if two explosions wound up in the same phase
before the skip number is reached by one of them,
the skip number will never be. and they loop in that phase
making the wall of fire an invisable blast,
or a shot from player will skip one to the next phase.

in the end all the timers are removed..
so if a fire was behind when another cleared the counters,
it would start the late fire counter back at 0

another aspect, the first phase before the first loop..
r5 v2 so fld near by will burn...
there is a typical invisable blast with radius 1000.
that happens once, so if fld animation was near by it would burn,
after the first phase of the animation is skiped, it resets r5 v0

so if you did have two fires locked in a phase,
and you throw another of these close amongst them,
that blast with radius 1000 should knock them out
of the loop using com 2 "512"

So building the wall of fire with these is doable,
but requires a little practice, as well its easy to stop
simply by playing the game.. if you were firing a gun
or anything in there direction..

there are 8 animations spawn in this one
n ne e se s sw w nw...

im using them to hide the negitive space between the main graphic
and invisable radius where guards would catch fire.. so my little fire
animations do no damage.. there for they never activate a ur ether..

they are removed when r2 v4.. so when one of the main fires reaches
its end, all the little fires disapear.. even if they were spawned by
a fire that started after...

..................
..................

I am going to tweek with my own explosions a bit more, and mod some graphics
im not 100% satisfied with how mine look now.. but as I said this visual
is enough to help explane how this works.

The list of comand numbers took a lot of the mystery out of
weapon scripting.

Command 4 means xform us to a new type of object. In this case the
frm# field contains the handle # of the fluid file to xform into.

that could be pretty interesting.. have the fire in a loop..
skip next if rv= then the folowing frame the animation
becomes another animation from your object txt..

example,..
a type of fld enemy.. with fram position movment,..
if shot, falls down and comes back to life..
if gibbed, reanimates, and comes back together...
if killed with fire, goes through his cycle..
but then triggers a rv.. and the fire that killed him spawns,
more fld animated enemies around the fire.. and when they are all dead..
they trigger another rv.. and the colum of fire transforms in to some
final boss or something.. xform... ;p

so where the explosion goes off could result in a unique conflict..
its all based on our creativity

kinda like santas rescue, i could imagine comand 4 "xform"
being used when we find the magic!

.......................

If anyone has questions feel free to ask,
cant wait to see what others create with this list of animation commands ;p