MoonDog

MB3 could have used someone like this guy to map, it would probably have a demo out by now lol.

 

Still, I plan on watching this when its done.

It's really easy. Decompile the map, convert it for use in UDK. Or you could you know, make original assets instead of decompiling a bunch.

I find the gameplay for this mod to be very lackluster.

I think your moose should act as the Wampa do and walk on their hind quarters, prepared to punch Luke in the face with deh frunt whoovz

Well the Kell Dragon has customizable harness with space for the galaxy dictionary for the best of topic discussions betweens jan and 8t88 at space starbucks. but then if some one says frack too often the robots win cause they r very mad

Although I admit me questioning your mod choice was a bit too direct, I gave you perfectly fine constructive criticism as to your server choice, which is a much larger issue. How do you want to host a fair tournament without taking into account that people might want to participate that don't live in the vicinity of the server and thus without putting them at a serious disadvantage? And if you can't guarantee that your tournament is going to be fair to everyone who wants to play in it, putting money on the line is a questionable use of resources... especially if it could be used to fix the glaring problem with your tournament.

Are you suggesting that there is a magical spot in which to place a server where everyone from each distant part of the globe can attain a good ping?

I wasn't asking if you guys were planning on supporting the maps; I was asking what I could do to fix my personal copy of the map, which is why I originally posted this in Tech Support. In that regard, it appears I have my answer. Ignoring the argument going on here, in what files would these comments be found? Are they in the shaders themselves, are they found in the .bsp, somewhere else? If I were to attempt to fix things, just how much tedium am I looking at? It's a great map that I've gone back to several times over the years in an attempt to find all the switches (never have), and the grey/black checkerboards are not easy on the eyes, to say the least.

Extract the shaders from the pk3, modify them in notepad ( remove all the #'s ), repack them into the pk3.

This is due to his use of # in comments. // and /* */ are to be used exclusively, and while # is supported in base due to bugged behavior (it still remains unknown how it worked before without causing problems. This comment style is not supported in ioquake3 at all), this behavior is deprecated in OpenJK and not supported. It is up to him to fix his maps.

 

If we support it, then that means that we will be supporting maps with undefined behavior in base, which might result in all kinds of wacky behavior... I'm surprised his maps haven't caused crashes or worse yet.

 

Furthermore, we've attempted to engage in dialogue prior to this and he hasn't responded. So our response is: no, we aren't supporting the maps, it's his responsibility to fix them.

Im sorry there has been plenty of response - I have fixed various maps as already stated. However, I still feel that if the goal of OpenJK is to preserve compatability with base JA, you need to readdress this change in shader syntax behaviour.

Put a huge wall of copy pasted text in a spoiler, or link it to a pastebin.

If you are worried about the entity limit, its 1021+1 for the worldspawn. (I think)

As for what you require from Icarus, it's not exactly possible. If there were callbacks to retrieve each axis individually, then maybe. At that point you could store each origin value in a parameter on the entities and then do a simple math on that value. After that you'd need callbacks that could then input those parameters back into an X Y Z format and then move the entities that way.

Of course, if this were better scripting, (Lets say, CODSCRIPT) you could store the initial value of the origin, make it into an array and call a function to increase each axis by a set amount and store the sum in an element of the array, which could be called upon by a different custom move function. But alas, you are stuck in the past.

I could of swore you could set a radius key on this entity signifying the distance in gtkradiant units for the attenuation.

Try that. You should be able to do volume and volRange as well.

He means he wants some one to do it for him.

http://holonet.antarat.com/wiki/index.php?title=Map_Modding

http://jkhub.org/tutorials/article/141-ent-modding-trigger-multiple-telporters/

If you know the proper way to make a specular texture, I'd definitely do a lightingSpecular stage. tcGen environment stages work pretty well too.

Example:

I can't think of a single thing that JKO's SP didn't do BETTER than JKA's SP.

Omfg that looks delicious.

lol. Whoops.

Give both of your scriptrunners key: count  value: -1

It doesn't matter how bad your English is as long as you bring tiramisu or some zeppole with you. Give to me now.

Alright, different hint.

This is the door opener you posted above fixed. See the difference? Try copy and pasting this into a txt file and save it as whatever.icarus. Open it in Behaved.

//Generated by BehavEd

rem ( "opens door in beginning of map" );

affect ( "bbdoor_trigger_downwards", /*@AFFECT_TYPE*/ FLUSH )
{
	set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "true" );

	affect ( "bbdoor_trigger_upwards", /*@AFFECT_TYPE*/ FLUSH )
	{
		set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "true" );

		affect ( "bb_door1", /*@AFFECT_TYPE*/ FLUSH )
		{

			task ( "moveup" )
			{
				move ( $tag( "bb_doortag2", ORIGIN)$, < 0.000 0.000 0.000 >, 1000.000 );
			}

			dowait ( "moveup" );

			affect ( "bbdoor_trigger_downwards", /*@AFFECT_TYPE*/ FLUSH )
			{
				set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "false" );
			}

		}

	}

}

@@Asgarath83 You seem to be answering questions without actually knowing what's causing the errors or how to clearly fix them. Refrain from that behavior. 

He's not experiencing a "bug" or a "leak" in the "Icarus system". It's simply an incorrectly structured script.

You don't need to decompile a level to change the spawns...

You can do an -onlyents recompile after changing the spawns in the .ent list.

Why don't you leave people's work alone? If they wanted it released outside of MBII, there would be a standalone version.

Polarity, I will try the method you showed, thanks for that! But to answer your question, I'm building this from the foundations so to speak. If I can't make a script reset itself in such a basic form, I cannot truly utilize the potential of scripts and use them for other things. When that's said, it might be I'll use the method you showed me, but I would still like to know how to solve the problem I have on the current script I'm using, since it's highly relevant to further scripting mastery

Well in answer to that, I'll hint to you that your script is structured incorrectly. Look at mine for clues.

if is refer to me, because is first time that i go into a community of JA for getting help, so many things i learned by my self experience and maybe not all is correct.

or maybe because simply i like the func_door entities because with that i can do a large amount of things. there are func_door that i not used only for making "doors" but simply moving object in a two sens

No one is talking to you.

@ I updated my original post due to errors I accidentally placed in the script.

I must ask though, why are you set on scripted doors? You could accomplish this easier with regular old entities.

I usually use a single script for this, and just setup parameters on my entities. That way I can have like 292929292 doors, but only one script to work all of them.

//Generated by BehavEd

rem ( "First block checks is door down" );

if ( $get( FLOAT, "SET_PARM1")$, $=$, $0$ )
{
	set ( /*@SET_TYPES*/ "SET_PARM1", "1" );
	rem ( "If it is, set to up" );
	set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" );
	rem ( "Turn off the trigger" );

	affect ( $get( STRING, "SET_PARM3")$, /*@AFFECT_TYPE*/ FLUSH )
	{
		rem ( "script_targetname of door" );
		move ( $get( VECTOR, "SET_PARM1")$, $get( VECTOR, "SET_PARM2")$, $get( FLOAT, "SET_PARM3")$ );
		rem ( "Vectors set on parms on door" );
		wait ( $get( FLOAT, "SET_PARM6")$ );
		rem ( "parm6 is the wait time, set on the func_static" );

		affect ( $get( STRING, "SET_PARM7")$, /*@AFFECT_TYPE*/ FLUSH )
		{
			rem ( "String parm7 is the script_targetname of trigger" );
			set ( /*@SET_TYPES*/ "SET_INACTIVE", "false" );
		}

	}

}


else (  )
{
	set ( /*@SET_TYPES*/ "SET_PARM1", "0" );
	set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" );

	affect ( $get( STRING, "SET_PARM3")$, /*@AFFECT_TYPE*/ FLUSH )
	{
		move ( $get( VECTOR, "SET_PARM4")$, $get( VECTOR, "SET_PARM5")$, $get( FLOAT, "SET_PARM3")$ );
		wait ( $get( FLOAT, "SET_PARM6")$ );

		affect ( $get( STRING, "SET_PARM7")$, /*@AFFECT_TYPE*/ FLUSH )
		{
			set ( /*@SET_TYPES*/ "SET_INACTIVE", "false" );
		}

	}

}

 
It's been a while since I used this, let me see if I remember what's going on.
 
parm1 is the status of the door. 0 being down and 1 being up. This parm is set on the trigger_multiple initially as the key "parm1" value "0". The trigger_multiple is also given the key "usescript" and the value of this script's name and file path. At this point the script sets the trigger as inactive before continuing. This is mostly to help prevent player error.
 
Now, the script looks at key: parm3 on your trigger. This is a string that tells it the name of the func_static you wish to move. (The script_targetname on the entity you are going to be moving.)
 
Example:
 
Key: parm3
Value: myCuteDoor1
 
Now, we are running a block of commands on myCuteDoor and thus can now fill out the parms on your cutedoor func_static entity.
 
Parms 1 and 2 on the func_static are vectors. 1 being an origin, 2 being an angle. Parms 4 and 5 are the same. 4 being an origin, 5 being a set of angles.
 
(This is optional. For me it's easier to do just one script to effect multiple doors. If you'd rather manually specify tags in the script, you may do so yourself.)
 
Parm3 is a float that specifies the time it takes for the door to move. Set this to whatever you want. It's shared by both the move up and move down blocks of command.
 
Parm6 is also set on the func static door. This is the time you wish to wait before reactivating the trigger that we initially turned off.
 
And finally, parm7 is a string signifying the script_targetname of the trigger_multiple that was deactivated in the beginning. This parm is also set on your func_static door. This means we are running another block of commands on the trigger_multiple. This time, the only command is to make the trigger_multiple usable by setting inactive to false.
 
 
 
There you have it! After all of that, parm1 on the trigger_multiple is no longer 0. It is now 1 and the door is up. That means the next time the trigger_multiple runs the script it will run the else block, which should have values that indicate the doors down origin.

Use CTRL + K for link an entity on GTK radiant to another, for create a trigger, make the brush of the trigger like a large square wall textured with sustem \ trigger and after convert the brush on the trigger yu desire.

for the teleport, yu need simply to create a trigger_teleport linked with control + k to a target position entity. this target_position set when the player be spawned using the warp.

the switch are  so: ù

target activate and target deactivate, linekd to  -> trigger multiple with an usescript, -> , linked with a func_usable or a func_botton.

the script also can deactivate thetrigger for a few of second and after reactivaed by Icarus way.

player use the trigger, start the usescript, and the script make the other operations.

Shhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh. I think you lost the beat.

So much better.