Trying to SOC a Rotating Turret

[Sparkz]

I thought it would be simple enough to make this work. A stationary turret that fires, turns 90 degrees, fires again and eventually reaches back to its stating point to do it all again. This turret shouldn't look for or target anything, just shoot in four directions.

Here's what the SOC looks like.
If you have the patience, please take a look. What am I doing wrong?

# Turret
Thing 321
MAPTHINGNUM = 125
SPAWNSTATE = 1795
SPAWNHEALTH = 1000
SEESTATE = 1803
SEESOUND = 0
REACTIONTIME = 100
ATTACKSOUND = 119
PAINSTATE = 0
PAINCHANCE = 2000
PAINSOUND = 0
MELEESTATE = 0
MISSILESTATE = 0
DEATHSTATE = 1641
DEATHSOUND = 119
XDEATHSTATE = 0
SPEED = 0
RADIUS = 1572864
HEIGHT = 1572864
MASS = 100
DAMAGE = 0
ACTIVESOUND = 0
RAISESTATE = 0
FLAGS = 16777221

# Turret Firing Once
FRAME 1795
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1796
ACTION A_ShootBullet

# Rotating
FRAME 1796
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1797
ACTION A_ChangeAngleAbsolute
VAR1 = 90
VAR2 = 90

# Turret Firing Twice
FRAME 1797
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1798
ACTION A_ShootBullet

# Rotating
FRAME 1798
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1799
ACTION A_ChangeAngleAbsolute
VAR1 = 90
VAR2 = 90

# Turret Firing Thrice
FRAME 1799
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1800
ACTION A_ShootBullet

# Rotating
FRAME 1800
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1801
ACTION A_ChangeAngleAbsolute
VAR1 = 90
VAR2 = 90

# Turret Firing Frice
FRAME 1801
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1802
ACTION A_ShootBullet

# Rotating
FRAME 1802
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1795
ACTION A_ChangeAngleAbsolute
VAR1 = 90
VAR2 = 90

 

[Shadow Hog]

Well, if you don't mind me asking, what's wrong with it as it is? Evidently you think there's a problem with the end result, but I have no information as to what that problem is. Without knowing what the undesired behavior is, I can't really pinpoint a cause.

 

[Sparkz]

OPPS! My apologies.
O.K. when I test the map and the turret spawns, it stands idly for a moment then turns 180 degrees. It doesn't do anything after that. It never fires.
Sorry again.

 

[MascaraSnake]

A_ShootBullet requires you to specify which Object should be fired. Just put the Object number as the RaiseState of your turret.

 

[Sparkz]

Yeah, I see I'm missing that... Fixed. Still not working. Wont fire. just turns 180 and stops.

 

[MascaraSnake]

Ah, now I see the other problem. Objects can't perform actions in their SpawnState unless you add MF_RUNSPAWNFUNC to their flags value (+2147483648). You can either do that or insert another state before your first one.

 

[Sparkz]

Tried them both. Still stopin'. The SOC does look more organized with a spawn state though.

I put this in front of everything and changed frames accordingly.

#Spawning
FRAME 1795
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 50
NEXT = 1796
ACTION None

 

[Sparkz]

Changed the angles of rotation from 90, 90, 90, 90 to 90, 180, 270, 360 and that got it rotating properly but it still wont fire.

 

[MascaraSnake]

This might be because A_ShootBullet needs a target to fire at. I assume you want a turret that fires its shot straight ahead without aiming. A_ShootBullet can't do that and unfortunately I'm not aware of any action that can.

 

[Violo]

I know this sounds weird, but maybe an invisible object that spins around the turret (CapeChase?) which gives the turret a target when it turns? Though depending on how those actions work, that may not work at all.

 

[Sryder]

You might be able to spawn 4 invisible objects around the turret and then use A_Look to find the one in-front of it before firing.

 

[Monster Iestyn]

You might be able to spawn 4 invisible objects around the turret and then use A_Look to find the one in-front of it before firing.

Except that A_Look only looks for players specifically.

You could try A_FindTarget or A_FindTracer instead, but those don't quite work the same way as A_Look.

 

[Shadow Hog]

Changed the angles of rotation from 90, 90, 90, 90 to 90, 180, 270, 360 and that got it rotating properly but it still wont fire.

Oh, yeah, that's because you're using A_ChangeAngleAbsolute. You probably wanted A_ChangeAngleRelative...

 

[Sparkz]

This might be because A_ShootBullet needs a target to fire at. I assume you want a turret that fires its shot straight ahead without aiming. A_ShootBullet can't do that and unfortunately I'm not aware of any action that can. .

I'm using A_ShootBullet because it's the only projectile on the Wiki that
doesn't specificaly say it needs a target:/

I know this sounds weird, but maybe an invisible object that spins around the turret (CapeChase?) which gives the turret a target when it turns? Though depending on how those actions work, that may not work at all.

I've looked at orbiting bodies, and it's more complicated than I wanted them to be but it might be answer if this doesn't work...

You might be able to spawn 4 invisible objects around the turret and then use A_Look to find the one in-front of it before firing.

Then each turret would need a set of four of these but the programing should be easier.

Except that A_Look only looks for players specifically.

You could try A_FindTarget or A_FindTracer instead, but those don't quite work the same way as A_Look.

Four invisible targets around the turrets, using one of these actions is what I'm about to try. I'll let y'all know how it turns out.






---------- Post added at 02:23 PM ---------- Previous post was at 02:03 PM ----------

Well I got the turret to fire (at me). A few modifications later its crashing the game.
The turret rotates. I changed the angles back to 90 and changed those from absolute to relative (the soc looks cleaner that way). Right before the game crashes my turret either turns into or spawns a green Sonic (Green Sonic haunts Green Grove. It's kinda funny) I've been messing with frames and states allot and I guess I've been lucky till now but what I need is some core organization comprehension. (Directory Fundamentals)

Please correct me if I'm wrong and tell me what I'm missing.

Spawning states and frames call pictures from the S_Start- S_End inventory but is not directly correlated with ThingNumbers or MapNumbers. So an object placed on a map can accidentally call a state (and accidentally call undesired pictures from the inventory) resulting in an object that dramatically changes its appearance (say, a bullet fired actually spawns as Green Sonic)

Argo, Lump F001= State 1792 indefinitely and always?

Other than assigning the proper states (and pictures from the inventory) a MapNumber has no relationship to the pictures in the inventory. So an object with a MapNumber of 318 (the first free slot) could call from the inventory anything from any free slots available in the picture inventory. (Sorry to keep calling it that but as artist, pictures are first thing I understand)

So if MapNumbers call SpawnStates and States call from the inventory, what is the relationship between anything and a ThingNumber or SpriteNumber?

Again, I'm not sure how much of that I got right. Please let me know if I'm wrong. I'll continue working on the turret.

 

[MascaraSnake]

I'm using A_ShootBullet because it's the only projectile on the Wiki that doesn't specificaly say it needs a target:/

Yeah, the description doesn't state that, but a quick look at the code confirms that it does need a target.

Spawning states and frames call pictures from the S_Start- S_End inventory but is not directly correlated with ThingNumbers or MapNumbers.

What are "spawning frames"? There is a "SpawnState", which is the state in which the Object is spawned. In your case, this is the state 1795. SOCs call states "frames" (e.g. "Frame 1795"), but since that term is also used in relation with sprites, please stick to "states".

It also appears you got the Object number and the Thing number confused. The Object number is the "ID" of your Object. In your case, this is 318 ("Thing 318"). SOCs call Objects "Things", but again, this is misleading. We call them Objects. Things are the Objects that you place on maps. So your turret is both an Object (when you look at it from the SOC perspective) and a Thing (when you look at it from the mapping perspective). The Thing number (called MapThingNum in the SOC) is 125 in your case. You only use this number when you place the turret on the map. Of foremost importance is the Object number (318).

Yeah, I know the terminology is a mess. SRB2 is really inconsistent about this. So let's see again:

Spawning states and frames call pictures from the S_Start- S_End inventory but is not directly correlated with ThingNumbers or MapNumbers.

I assume you mean that the sprites are called by states, which are in turn called by the Object. Therefore, there is no direct connection between the Object and the sprites. That is correct.

So an object placed on a map can accidentally call a state (and accidentally call undesired pictures from the inventory) resulting in an object that dramatically changes its appearance (say, a bullet fired actually spawns as Green Sonic)

This could be what's causing the error, yes.

Argo, Lump F001= State 1792?

I don't know what you mean by that, sorry.

Other than assigning the proper states (and pictures from the inventory) a MapNumber has no relationship to the pictures in the inventory. So an object with a MapNumber of 318 (the first free slot) could call from the inventory anything from any free slots available in the picture inventory. (Sorry to keep calling it that but as artist, pictures are first thing I understand)

Again, Object number, not "MapNumber". The MapThingNum is 125 and isn't directly related to the Object.

So if MapNumbers call SpawnStates and States call from the inventory, what is the relationship between anything and a ThingNumber or SpriteNumber?

Well, what is "anything"?

The easiest thing would be if you just post the SOC in its current state so we can look for errors.

 

[I'll Begin]

Oh, yeah, that's because you're using A_ChangeAngleAbsolute. You probably wanted A_ChangeAngleRelative...

I'd like to add that it's better to use relative because that way you can actually set an initial rotation as well.

 

[Sparkz]

It's shooting! Kinda...

Yeah, the description doesn't state that, but a quick look at the code confirms that it does need a target

I've given the turret four targets to shoot at (It's only shooting at one but I'll get that later)

In your case, this is the state 1795. SOCs call states "frames" (e.g. "Frame 1795")

Understanding this relationship is helpful!

(called MapThingNum in the SOC) is 125 in your case. You only use this number when you place the turret on the map. Of foremost importance is the Object number (318).

So in terms of the free slots, are they directly related? i.e. MapThingNumber (125) is always related to object Number (328) or...

Argo, Lump F001= State 1792 indefinitely and always?

Sorry that was't clearer, I'm trying to figure out if a specific StateNumber like 1792 (first free state slot) always calls from the states in F001xx (first free lumps) So when I'm SOCing and call state 1792, will it always look in F001? If not, what is the relationship between states called and where the game looks among the lumps for the sprites? I hope that was clearer.

So if MapNumbers call SpawnStates and States call from the inventory, what is the relationship between anything and a ThingNumber or SpriteNumber?

Well, what is "anything"?

You've explained that a ThingNumber is is an objects ID used in SOCs. Is this number related to it's SpriteNumber or it's map editing MapNumber? If not, what are they related to? Do these numbers reference anything among the lumps? I'm just trying to figure out how the game uses these numbers. What is a SpriteNumber?
I've noticed in the turret SOCs that work (at least they rotate properly) that the SpriteNumber doesn't change during the turret's rotation. Is this because It's using the same Lumps (sprites) to express its different frames and states?

Alright, the SOC as it is right now eliminates Green Sonic. It rotates the turret and fires. However, when it spawns, fires its first shoot and rotates, it returns to its starting position to fire again. It then tries again to rotate. so it makes a loop of firing south turning east, then jolting south and firing, turns east, jolts south and firers. it does this four time before turning into the yellow robot from SRB1 and taking a few steps east before turning back into the turret and doing it all again. the transormation to the robot happens so quick I didn't notice at first so I though I could fix it by giving it 4 unique targets to aim at but that didn't seem to have any effect what so ever.

Here it is.


# Turret
Thing 321
MAPTHINGNUM = 125
SPAWNSTATE = 1795
SPAWNHEALTH = 1000
SEESTATE = 0
SEESOUND = 0
REACTIONTIME = 0
ATTACKSOUND = 119
PAINSTATE = 0
PAINCHANCE = 2000
PAINSOUND = 0
MELEESTATE = 0
MISSILESTATE = 0
SPEED = 0
RADIUS = 1114112
HEIGHT = 3932160
MASS = 100
DAMAGE = 0
ACTIVESOUND = 0
RAISESTATE = 111
FLAGS = 16777221

FRAME 1795
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 10
NEXT = 1796
ACTION None

# Turret's Invisible Targets

# First Tartget
Thing 322
MAPTHINGNUM = 126
SPAWNSTATE = 1789
SPAWNHEALTH = 5000
RADIUS = 1310720
HEIGHT = 3276800
MASS = 100
FLAGS = 16777221

FRAME 1789
SPRITENUMBER = 247
SPRITESUBNUMBER = 0
DURATION = 100
NEXT = 1889
ACTION None

# Turret's Invisible Targets

# Second Tartget
Thing 323
MAPTHINGNUM = 127
SPAWNSTATE = 1789
SPAWNHEALTH = 5000
RADIUS = 1310720
HEIGHT = 3276800
MASS = 100
FLAGS = 16777221

FRAME 1789
SPRITENUMBER = 247
SPRITESUBNUMBER = 0
DURATION = 100
NEXT = 1889
ACTION None
# Turret's Invisible Targets

# Third Tartget
Thing 324
MAPTHINGNUM = 128
SPAWNSTATE = 1789
SPAWNHEALTH = 5000
RADIUS = 1310720
HEIGHT = 3276800
MASS = 100
FLAGS = 16777221

FRAME 1789
SPRITENUMBER = 247
SPRITESUBNUMBER = 0
DURATION = 100
NEXT = 1889
ACTION None
# Turret's Invisible Targets

# Fourth Tartget
Thing 325
MAPTHINGNUM = 129
SPAWNSTATE = 1789
SPAWNHEALTH = 1
RADIUS = 1310720
HEIGHT = 3276800
MASS = 100
FLAGS = 16777221

FRAME 1789
SPRITENUMBER = 247
SPRITESUBNUMBER = 0
DURATION = 100
NEXT = 1889
ACTION None

# Targeting Invisible Target #1
FRAME 1796
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1797
ACTION A_FindTarget
VAR1 = 322
VAR2 = 0

# Firing Once
FRAME 1797
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1798
ACTION A_ShootBullet

# Rotating
FRAME 1798
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1799
ACTION A_ChangeAngleRelative
VAR1 = 90
VAR2 = 90

# Targeting Invisible Target #2
FRAME 1799
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1780
ACTION A_FindTarget
VAR1 = 322
VAR2 = 0


# Firing Twice
FRAME 1780
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1781
ACTION A_ShootBullet

# Rotating
FRAME 1781
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1782
ACTION A_ChangeAngleRelative
VAR1 = 90
VAR2 = 90

# Targeting Invisible Target #3
FRAME 1782
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1783
ACTION A_FindTarget
VAR1 = 322
VAR2 = 0


# Firing Thrice
FRAME 1783
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1784
ACTION A_ShootBullet

# Rotating
FRAME 1784
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1785
ACTION A_ChangeAngleRelative
VAR1 = 90
VAR2 = 90

# Targeting Invisible Target #4
FRAME 1786
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1787
ACTION A_FindTarget
VAR1 = 322
VAR2 = 0

# Firing Frice
FRAME 1787
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1788
ACTION A_ShootBullet

# Rotating, Return to Starting Position
FRAME 1788
SPRITENUMBER = 246
SPRITESUBNUMBER = 0
DURATION = 20
NEXT = 1796
ACTION A_ChangeAngleRelative
VAR1 = 90
VAR2 = 90

 

[Prime 2.0]

I'd just like to point out for a moment that you only need one invisible target; just make it A_FindTracer the turret and then use A_CapeChase on it continuously. Because A_CapeChase works relative to the angle of the actor's target object(tracer, in the above case), you don't need the turret to change targets to fire in different directions... the turret can change angle normally with A_ChangeAngleRelative or absolute and the invisible target will follow accordingly.

 

[Sparkz]

Thanks, Prime that's good to know. I'll try that next. I would like to thank everybody else too for their help and I wanted y'all to know I got it working! I have one more question as far as this is concerned. How can I change the Z offset of the projectile. I'm using A_ShootBullet. I've tried other projectiles but they all seem to throw the projectile. (by throw I mean there's an arch) and other projectile are too violent.

---------- Post added at 11:53 PM ---------- Previous post was at 10:30 PM ----------

Well, we all know there is no answer without more questions. Aside from wrapping my mind around upper and lower 16 bits. The Wiki isn't helping much and I can't find or reverse engineer an example of orbiting bodies i.e. The Eggmobile with it's spike balls.

just make it A_FindTracer the turret and then use A_CapeChase on it continuously.

Use A_FindTracer on the turret or target? Same question for A_CapeChase.


This is the part of the SOC for the new single target. The turret works perfectly so I wont bother you with that. Unless one of these actions belong to it (which I don't know) and I'm sure I have Var1 and Var2 totally screwed up.

# Turret's Invisible Orbiting Target
Thing 322
MAPTHINGNUM = 126
SPAWNSTATE = 1808
SPAWNHEALTH = 5000
RADIUS = 1310720
HEIGHT = 3276800
MASS = 100
FLAGS = 2147483648

FRAME 1808
SPRITENUMBER = 247
SPRITESUBNUMBER = 0
DURATION = 100
NEXT = 1809
ACTION A_FindTracer
Var1 = 321
Var2 = 0

FRAME 1809
SPRITENUMBER = 247
SPRITESUBNUMBER = 0
DURATION = 100
NEXT = 1809
ACTION A_CapeChase
VAR1 = 0
VAR2 = -800

In this condition, the target spawns (I know this because I've given it a temporary sprite) but shortly after spawning it disappears. I'm not sure if it goes into the floor or disappears entirely. Needless to say It's way off from orbiting.

Learning how to do this properly will come in handy because there are more enemies in the game that will make use of it!

 

[MascaraSnake]

So in terms of the free slots, are they directly related? i.e. MapThingNumber (125) is always related to object Number (328) or...

No. Look at your SOC. In the first block, there is line that says "MAPTHINGNUM = 125". This controls the MapThingNum of your Object. You can set it to anything you want.

Sorry that was't clearer, I'm trying to figure out if a specific StateNumber like 1792 (first free state slot) always calls from the states in F001xx (first free lumps) So when I'm SOCing and call state 1792, will it always look in F001? If not, what is the relationship between states called and where the game looks among the lumps for the sprites? I hope that was clearer.

Again, no. Look at the second block. The second line says "SPRITENUMBER = 246". This controls which sprites the state is looking for.

Is this number related to it's SpriteNumber or it's map editing MapNumber?

No. You can set the MapThingNum (There is no "MapNumber") as part of the Object's properties. The sprites aren't even directly referenced by the Object, the states do that.

If not, what are they related to?

I still don't understand what you mean by "related". The numbers are just there so much can identify these things and reference them wherever necessary.

Do these numbers reference anything among the lumps?

The only numbers that have anything to do with the lumps are the SpriteNumber and the SpriteSubNumber of a state. The former controls what prefix the sprite has. For example, if the SpriteNumber is 243, the sprites with the prefix "F001" are used. If it's 246 like in your case, the sprites with the prefix "F004" are used. If it's anything lower than 243, the game uses sprites that already exist in unmodified SRB2. You can see which number is related to what prefix here. The SpriteSubNumber tells the game what animation to use. If you set it to 0, it will use the "F004Ax" sprites (assuming you have a SpriteSubNumber of 246). If you set it to 1, it will use the "F004Bx" sprites and so forth. Neither the Object number nor the state number nor the map Thing number have anything to do with the sprites that are used.

What is a SpriteNumber?

See above. In the SOC Editor, you get a neat dropdown list for it under "Edit States". It's right at the top, labeled "Sprite:".

I've noticed in the turret SOCs that work (at least they rotate properly) that the SpriteNumber doesn't change during the turret's rotation. Is this because It's using the same Lumps (sprites) to express its different frames and states?

It's not supposed to change. As long as you want the turret to look like a turret, the SpriteNumber for it must stay the same. The SpriteSubNumber is used to animate the turret.

I assume your SOC is already outdated, so you'll have to give me the complete new SOC if you want me to identify your current problem.

Aside from wrapping my mind around upper and lower 16 bits. The Wiki isn't helping much

The value of the variable is calculated as the desired upper bit value multiplied with 65536 plus the desired lower bit value.

That's all there is to it. If a variable requires you to use upper bits and lower bits, don't panic: Before even wrapping your head around what upper bits and what lower bits are, you decide what values you need. Let's use an example:

Let's assume you want to use A_DropMine. The article tells you that Var2 is used for proximity checks. So far, so good. "The lower 16 bits of Var2 set the distance threshold (0 disables the proximity check). The Object is only dropped if the distance between the actor and its target is smaller than the threshold." Okay, let's assume you want a threshold of 16 fracunits. Keep that number in mind and move on: "If the upper 16 bits are set 1, the proximity check is performed with the actor's tracer instead." Let's assume you want to perform the proximity check with the tracer (for now it's completely irrelevant if you know what a tracer is). Okay, you keep the number "1" in mind and move on.

Now you calculate Var2. The lower bits are 16, the upper bits are 1. "The value of the variable is calculated as the desired upper bit value multiplied with 65536 plus the desired lower bit value." Well okay. Multiply the upper bits (1) with 65536 and you get 65536. Now add the lower bits (16) and you get 65552. That is your Var2 value.