MoonDog

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

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?

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

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: textures/blerp/sultra_armory_metal_tank_storage{ q3map_editorimage textures/blerp/sultra_armory_metal_tank_storage q3map_normalimage textures/blerp/sultra_armory_metal_tank_storage_nm q3map_material solidmetal q3map_lightmapsamplesize 1x1 q3map_lightmapMergable { map $lightmap rgbGen identity } { map textures/blerp/sultra_armory_metal_tank_storage blendFunc GL_DST_COLOR GL_ZERO } { map textures/blerp/sultra_armory_pipe_spec blendFunc GL_SRC_ALPHA GL_ONE detail alphaGen lightingSpecular } { map textures/blerp/sultra_gloss blendFunc GL_SRC_ALPHA GL_ONE alphaGen const 0.15 tcGen environment }} That shader above is for a texture in a level. However, I highlighted the parts you should look at. In red, you'll see the stage that applies the specular texture. Pretty important for a lot of weapon models depending on their material and how it should look in game/life. In blue you'll see the stage that applies an environment texture. This is a texture to sort of imitate reflection, gloss etc... If you want to learn more of the specifics behind the other keywords, check this out:http://q3map2.robotrenegade.com/docs/shader_manual/contents.html

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.

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

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.

Shhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh. I think you lost the beat.

So much better.