Custom SOC Actions: Execute console commands?

[Pyro the Magma Fox]

I was wondering, after finding all the code for the SOC actions in p_enemy.c (Not sure why =/), how can I edit the source code to make a new action that executes a console command (the 'tunes' command to be exact) where Var1 is the MusicSlot and Var2 is the speed? What is the code I need for this?

 

[742mph]

You could always just have your SOC use A_LinedefExecute to trigger a linedef executor in the level that runs a script that changes the music. It sounds very complicated, but believe me, it's not. I use mechanisms similar to that all the time, and it's one of the reasons why my custom bosses have attacks and attack patterns that don't look like they should be possible in SRB2.

 

[Pyro the Magma Fox]

You could always just have your SOC use A_LinedefExecute to trigger a linedef executor in the level that runs a script that changes the music. It sounds very complicated, but believe me, it's not. I use mechanisms similar to that all the time, and it's one of the reasons why my custom bosses have attacks and attack patterns that don't look like they should be possible in SRB2.

I meant as in, like Sonic 4's Boss Pinch.

 

[742mph]

I meant as in, like Sonic 4's Boss Pinch.

You could still do that with the advice that I gave you. Just have the boss execute a Once linedef executor in the level it's placed in when it enters its RaiseState, and attach a linedef with effect #415 to that executor. Then, create a text lump in the boss' WAD file and name it appropriately (see the wiki for more info), and write "tunes xx" in it. That's all you have to do. There's no need to mess around with the source code or anything like that.

 

[Prime 2.0]

Or you could just use A_LinedefExecute to trigger Linedef 413, since that's what it's for. :P

Otherwise, 742mph has it right on the head; the tools to do what you're asking already exist.

 

[742mph]

Or you could just use A_LinedefExecute to trigger Linedef 413, since that's what it's for. :P

Sorry about that. I never took the time to think about if there was an easier way to do what he wanted.

 

[Pyro the Magma Fox]

Sorry about that. I never took the time to think about if there was an easier way to do what he wanted.

I thought that action meant execute a linedef number in the level!

 

[Monster Iestyn]

I thought that action meant execute a linedef number in the level!

Nope, it's actually the linedef's tag you need for A_LinedefExecute.

Though for that matter, I thought A_LinedefExecute would only work for the trigger linedefs (i.e Once, Continuous, Each Time, etc.) or something, but maybe it actually works for the linedef execs themselves too? *shrugs*

 

[Pyro the Magma Fox]

Nope, it's actually the linedef's tag you need for A_LinedefExecute.

Though for that matter, I thought A_LinedefExecute would only work for the trigger linedefs (i.e Once, Continuous, Each Time, etc.) or something, but maybe it actually works for the linedef execs themselves too? *shrugs*

I dunno, I personally have never used that action...

 

[Prime 2.0]

Nope, it's actually the linedef's tag you need for A_LinedefExecute.

Though for that matter, I thought A_LinedefExecute would only work for the trigger linedefs (i.e Once, Continuous, Each Time, etc.) or something, but maybe it actually works for the linedef execs themselves too? *shrugs*

As far as I know you have to use it on the triggers.

 

[Pyro the Magma Fox]

As far as I know you have to use it on the triggers.

So, using the tag as opposed to the linedef number?

 

[Ice]

Yes, use the tag of the linedef trigger on VAR1.
So, say your trigger is tag 16, then VAR1 = 16.

...I think. Amirite?

 

[Pyro the Magma Fox]

The tag of the linedef to be executed is determined by Var1 or, if Var1 is set to 0, the state number + 1000.

I just read the Wiki, Ice. It IS the tag, but wait...the state number + 1000? That's a bit like A_RandomNumber, is it not?

 

[Prime 2.0]

I just read the Wiki, Ice. It IS the tag, but wait...the state number + 1000? That's a bit like A_RandomNumber, is it not?

That's how it used to work before action parameters existed; it only does that if you leave VAR1 as zero, and is pretty much just there for backwards compatibility since nobody would ever want to control their tag that way given the choice. That said, you should use linedef type 300 for the linedef trigger.

 

[Pyro the Magma Fox]

That's how it used to work before action parameters existed; it only does that if you leave VAR1 as zero, and is pretty much just there for backwards compatibility since nobody would ever want to control their tag that way given the choice. That said, you should use linedef type 300 for the linedef trigger.

So I guess VAR1 is the tag?

 

[Prime 2.0]

So I guess VAR1 is the tag?

Yes, that's exactly what it said. Something besides that to note though, but the trigger "each time" will not work with A_LinedefExecute. Use continuous instead.

 

[Pyro the Magma Fox]

Why would that be?

 

[blm768]

Why would that be?

I'd guess that it's because keeping track of the internal state to make that work is too much of a hassle when you can just make the state calling the executor last one tick and get the same effect. I guess that also partially explains the quirks with pushables and executors...

 

[Pyro the Magma Fox]

I'd guess that it's because keeping track of the internal state to make that work is too much of a hassle when you can just make the state calling the executor last one tick and get the same effect. I guess that also partially explains the quirks with pushables and executors...

Yeah... And idk whether a VAR1 is needed to keep my custom enemy from disappearing after less than a second... (Not to go off topic...)