Shield like in siege_korriban

[lassev]

Originally Posted by StaffSaberist

***If anybody knows what I did wrong on the above script, please tell me!***

I had decided to stay clear of this thread as it seemed so crazy right from the beginning, but I suppose I can write a couple of notes here now that scripting is involved.

First thing: If you are going to use parms, then set the initial parm in Radiant already. There's no reason to have a small script just for that.

And in general, parms are entity specific, so you can't just launch a script with a scriptrunner and check for a parm. An entity must be affected first, and that means a parm of that particular entity is then checked.

And I would use a number to mark the on/off state (like 1 / 0). That's better programming convention, but of course you can do it however you like, as long as it works.

And also your if-else structure is flawed. In ICARUS syntax, else is not indented compared to the parent if. Check some Raven scripts to see what I mean.

And, if memory serves, when you turn something to invisible with the script command, it's also turned nonsolid. So, when you turn it back visible, you must also use the specific script command (SET_SOLID) to turn it back solid.

Well, that's about it.

[StaffSaberist]

I knew it would be you, lassev, I knew it! OK, I'll go back in a bit. I have my own map to create, too.

[lassev]

Oh. And your if statement is faulty also otherwise. If you check a parm, it needs to look something like this:
if ( $get( FLOAT, "SET_PARM1")$, $=$, $1$ )

Or in your case STRING etc.

[SD_Radical_Ed]

[StaffSaberist]

Don't worry. I have a hard time getting scripting too. It'll come to you, just like mapping does.

[lassev]

Doing this whole thing with scripting would be 90% easier than with those bizarre entity hacks posted earlier (that didn't even work, did they?). I could build this system from scratch in 7 minutes with scripting.

But naturally I won't. It wouldn't teach you anything. Basically all the info needed is pretty much already given, by combining the basic, simplest parts of the entity hacks posted with corrected bits of StaffSaberist's scripting. Well, a variable could also be used instead of a parm, but that's a small difference (though it would require an initial script run once to declare the variable).

[StaffSaberist]

Since I already have that, I may as well fix it. And I will.

EDIT - All right. I have re-done the scripting. And still nothing. Can a func_static simply not be made invisible?

I have in Radiant:

A triggered script like thus for the info_player_start:

//(BHVD)
declare ( /*@DECLARE_TYPE*/ FLOAT, "Switch" );
set ( "Switch", "1" );

A func_static for our "forcefield".
A switch/wall section with a trigger_once. The trigger_once targets the scriptrunner, and triggers this script:

//(BHVD)

if ( $get( FLOAT, "Switch")$, $=$, $1$ )
{

	affect ( "forcefield_not", /*@AFFECT_TYPE*/ INSERT )
	{
		set ( /*@SET_TYPES*/ "SET_INVISIBLE", /*@BOOL_TYPES*/ "true" );
	}

	set ( "Switch", "0" );
}


else (  )
{

	affect ( "forcefield_not", /*@AFFECT_TYPE*/ INSERT )
	{
		set ( /*@SET_TYPES*/ "SET_INVISIBLE", /*@BOOL_TYPES*/ "false" );
		set ( /*@SET_TYPES*/ "SET_SOLID", /*@BOOL_TYPES*/ "true" );
	}

	set ( "Switch", "1" );
}

And finally, a func_breakable that targets a scriptrunner which triggers:

//(BHVD)

affect ( "forcefield_not", /*@AFFECT_TYPE*/ FLUSH )
{
	set ( /*@SET_TYPES*/ "SET_INVISIBLE", /*@BOOL_TYPES*/ "true" );
}


affect ( "button", /*@AFFECT_TYPE*/ FLUSH )
{
	set ( /*@SET_TYPES*/ "SET_TARGET", "NULL" );
}

I used "INSERT" instead of "FLUSH" because I thought it possible to erase the invisibility and nonsolidness. Was that a mistake? IF not, what else have I erred on? I tried to take your advice to the letter...

[lassev]

Hmm... I don't immediately spot any strange errors. Use FLUSH, though. INSERT means any old commands the entity happens to be executing aren't erased but the new commands are added to the queue. That's very rarely something you desire - perhaps useful for some cinematic purposes.

Also it might be more clear to inactivate the switch, not set the target to null. That's quite strange a solution.

Recheck script_targetnames and stuff once more.

[StaffSaberist]

I had it target NULL because it was targeting the scriptrunner. If it was not targeting the scriptrunner, the script could not run. But I changed it anyway, as well as the INSERT >> FLUSH.

OK, x2 checked the stuff in Radiant. I noticed only one thing that may be off: I had a scriptrunner entity with two values as opening. The first was the targetname, the second was the usescript key. So, I changed the targetname to opening_ss (StaffSaberist). Compiled. I load it up... no function.

Perhaps my error is in the placement of my scripts. I have the scripts in folder C:\Program Fles\LucasArts\Star Wars Jedi Knight Jedi Academy\GameData\Base\scripts\.

I set the scriptrunner to access scripts/scriptname. If I had my old project as a reference, I'd know immediately if I am wrong. But I don't. I will look for the answer, but I wonder if that is the problem.

Boy, Ed, we took over your thread! Don't worry, we are working on it. And I am learning some interesting ideas for my next project.

[lassev]

Turn the script monitor on and you spare yourself of some speculation. I don't know if it works in MP, but test in SP if it doesn't. g_icarusdebug 5.

And you don't include the "scripts/" in the scripts path. Scripts is where scripts are always kept (though normally in subfolders under it), so no need to include that part in the path.

[StaffSaberist]

I found the answer. No scripting. Nothing more complicated (at first) than targetting a trigger_multiple at the forcefield. I got it to work! And I did it following a tutorial.

I recommend you read thorough this tutorial WORD FOR WORD. It will show you not only how to do the forcefield, but how to have a button change textures as it is pressed. It will also show you how to get sound running for it. It will not, however, show you the destructible brush thing, though. If you need help, let us know.

http://www.darthg.com/richdiesal/dar...rushes_301.htm

And if you do not get it at first, this is the link to RichDiesal's Mapping University. It's for an older Radiant that works with JO, but the info is basically good.

http://www.darthg.com/richdiesal/tutorials/