MoonDog

A.) trigger_always B.) target_relays with "targetShaderName" and "targetShaderNewName" keys. Obvious which one is which. Give all the relays the same "targetName". Give the trigger_always a "target" value of that same targetName you gave to all your relays.

Bowcasters are pure energy weapons right? Maybe the few(few(few)) enemies you spawn with bowcasters would have a killswitch rigged up so that their pure energy weapon(bowcaster) would explode upon their death. I'd do that if I were a space criminal sort. Be an interesting little danger mechanic to add to bowcaster carrying mercenary types. Maybe instead of a plain old explosion you could have it send off a bunch of the ricocheting shots. I'd have no idea how'd you go about coding that though. Since you don't want all enemies that wield bowcasters to do that you could restrict that to a certain npc class you'd use until you introduce the bowcaster to the players inventory.

You are doing a fairly good job of breaking up the textures with your timber framing and other trim. That's a great direction to move in. What's the rest of the area going to be like?

That whole part of the story line felt dry. When they "killed" Jan I as the player didn't care about it at all. It had no emotional drive because they hardly did anything to show players the emotional value of the character. She bordered on annoying back ground noise almost. So that whole build up to Kyle's decision to become a Jedi felt forced and unbelievable. Definitely not a great story telling mechanic they developed there. We're never going to agree on this, I can see that. I've made a ton of mistakes in developing my own process, some of them fatal to whatever I had been working on at the time. Others less so. I've evolved my theories, methods and lines of thought on design in a very drastic manner to get to where I am and where I'm going. I can say 100 percent though that skipping over the necessities of the design process perches your projects precariously on a ledge of failure. Each time you force on without heeding a good process it teeters further. If you have happy accidents it could work out, but it rarely does. Gameplay drives everything else, so as a level designer it's the first thing you should focus on. Believe me, I've learned that the hard way.

Awwww, but that was one of the things DF2 did well. Actually getting the saber when you went to your fathers home felt like a big deal. They tried to do something similar in Outcast but it didn't have near the same feel. It kind of just felt matter of fact. "Well, here's your puzzles now here is a saber."

He's not compiling a .map. He's compiling an entity list back into a bsp, overwriting the original entities. This is done by using q3map2's onlyents switch. If it were a fresh map using the autoclip method would be on the table.

The primary concern when planning a SP level is gameplay beyond all other considerations. They are not just important aspects, but the most important. Block out the level with the simplest shapes and textures possible and get gameplay in there immediately. You never go the other way around. You'll end up having to make a lot of adjustments to complex geometry when something doesn't work out. Plus, as you brainstorm and sell yourself on new ideas and iterations of combat you may find ways in which you want an area to play out in an alternative manner. The AI in DF2 was extremely weak. While the AI is pretty weak in this modified Q3a engine, it's still a great improvement over the game he's recreating for. Instead of just having random NPC's bumbling about on combat waypoints, he could have more interesting combat for the user to enjoy. That way they can say, "Oh wow, he really improved on the gameplay. Not just the aesthetics of the level." Trust me.

Are you purely worried about aesthetics here? Your first priority for an SP level is scripting and combat(aka gameplay). Doesn't matter if the level looks good if there are just randomly placed NPCs for combat. Some things were awkward to accomplish with COG scripts and geometry construction in JED. I think you may be falling into a trap of trying to create a carbon copy rather than an elaboration. Mayhaps you can send me a beta pk3 of the level so I can give you better feedback?

lol... I am most certainly not referring to the blue lights in the first screenshot... Never mind.

This guy gets it.

I don't think you are as dumb as eezstreet led me to believe. I have been wrong before though.

Sounds boring.

Or! My comment could have been about the images almost immediately prior to my post. You know, the ones with the flames making white light. If it were a snake, it would have set you on fire. With it's white light.

Using common sense to determine which flames from the available and recent screens shots too much of a chore eh? Couldn't possibly be the pictures I posted almost immediately afterwards.

Are you.... are you serious?

JA++ does have a bit-field calculator. http://japp.jkhub.org/?page=calculator

Er... no. The script makes it so whatever you assign it to as a spawnscript can't be used by players, and you can set it's scale in the parm1 field of the entity while you are ent modding. And to make it a spawnscript on the entity you add the keys "spawnscript" "script_name". As for more detailed instructions, no. The screenshot is more than sufficient.

You can't make solid objects with entity modding. The objects aren't solid to begin with. That is done with the various clip shaders in Radiant. (Or autoclipping through q3map2, but like mrwonko said it's not advisable. Creates a clip plane for every tris in the model. Grossly expensive.) Your best option would be to use misc_model_health_power_converter entities with no model of it's own indicated. That entity has a small hitbox you can take advantage of in entity modding to simulate real clipping. However it get's expensive if you try to get too complex with it. Anyways just try this. Get the origin of the model you are using and make a misc_model_health_power_converter in the same location. A quick word about this. The entity will still be usable as a health converter, which can be cheesy. Make this script the spawnscript of the entity. The setscale line can be safely ignored. Unless you plan on using it to scale up or down one of your models. In which case just put "parm1" "number" in the entity. *Disclaimer: You can't affect the hitbox of the misc_model_health_power_converter. Ex: Change it's scale or shape.

Something like that would also benefit from a larger blocksize.

They are brush models. Meaning they are level geometry given properties as entities. For example a square brush made into a func_door. All the brush models are sorted into an index which is called a Brush Model Index and stored as a lump in the bsp(I think). In any case, they are each assigned a designation and can be seen in the entity list within the BSP by looking for the designation "model" "*number". Anyway I'm pretty sure Boba Fett's Ultra Utility can list all of the brush models for you, as well as their origins in relation to the 0,0,0 origin of the bsp. Try !bmodels.

You don't need two triggers first off. One trigger can target a multitude of entities. Second, your origins and angles are probably wrong for the brush models. (I'm not sure which one *1 is btw, *8 is a tiny piece of an elevator and generally works better.) Use Boba Fett's UU. Get in game and do !brushmoveorigin bmodel. Ex: !brushmoveorigin *8. In order to move the cloned brush model to the origin you are currently occupying, UU will give you the proper origin to use. This is because the origin of the original bmodel is treated as 0, 0, 0 when it is being cloned. You can't give it an origin based on the 0, 0, 0 of the bsp. It simply will be some place completely different. Next, check your angles. You have spawnflags 3 on the first entity. Which I can only assume is facing and clientonly. So make sure your facing angle is correct. Same with the second trigger. Which appears to be facing, clientonly, usebutton. Also, I'm not sure why you have targetnames on your triggers. You can probably get rid of those. Lastly, just delete one of the triggers. Give the target_teleport and the target_print the same targetname and target the trigger at them. Easy.

Generally, yes that is a good rule. You only need things to remain structural if you want them creating splits. You should read this. http://www.quake3world.com/forum/viewtopic.php?t=3620

Yeah, sorry. I misread your post. Happens occasionally.