MoonDog

I agree. Getting the saber made a lot more sense with timing in DF2. Outcast was all about revenge, which is fine, but wasn't as impactful.

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.

Everyone's got a different approach when it comes to level design. There is no right way to do it, it's truly up to the mapper. There are pros and cons to my method and yours. It really just comes down to preference and whatever keeps the creator motivated. And maybe in a professional setting your method would be superior, but motivation is fueled by what interests the level designer, so those design aspects may be what motivates the modder. Make sense?

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.

I agree that great gameplay/combat.

Though I also think accuracy is important for recreating the maps too.

 

The one thing I'm wondering about is if DT85 has considered the gunplay in JA? Because it sucks. I didn't like it in JK either and would just use codes to give myself the saber first thing.

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."

Or you can do what I say if you don't care about optimization.  (Which isn't something you should start while your still young.)

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.

While scripting and gameplay are important aspects of SP level creation, I think DT is on the right track with fleshing out his map before placing the scripted entities in it. I find that I'll setup a script in an area, just to erase it and start over because I completely changed that area in question. Plus, as a recreation mod, one of his primary goals is aesthetics and getting the map to look as good and accurate as possible.

 

@@DT85 - I totally thought that screen was from inside Radient lol - I totally freaked out! Keep up the good work man, you're making great progress!

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.

EDIT: I made this special, just for you.

Hah. You won't do very well here.

Ooooh, and old veteran eh?

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

It could have, and it was. Like I said, small mistake that could've easily been solved in a manner that didn't involve insults and condescension.

Sounds boring.

Common sense eh? You made one post in the thread, you could've easily been referencing any of the shots, considering they are not of the same thing. All your comments could've been about any of the screenshots. A simple mistake, nothing more. Don't make it a big deal by being a sarcastic asshole. It's not a good look on you.

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.

Again, no need to be an asshole. The thread covers several different maps and screens, so a simple "Not this picture, the other one." is all that's necessary.

 

You know, considering:

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.

No need to be an asshole.

Light looks blue to me?

Are you.... are you serious?

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.

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

So that script would make my models like if they were misc_models ?

 

Thank you, I will try it out now.

 

 ** Maui **

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.

For example a massive level that has a giant wall of china built into the center might benefit from making the wall structural so that it blocks vis from one side.  That sort of thing.

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.

Thanks for info guys. Just so I understand, I only have the walls/floor/ceiling as structure and the rest detail?

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

I'm fully aware of this. I was just mentioning it because, as you correctly noted, entities are ignored by the vis process, so if you only want to see the brushes q3map2 takes into consideration you'll want to filter out entities, as well.

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

And Entities can be filtered with Alt + 2.

Detail brushes, patch meshes and translucent brushes are not entities unless you make them into entities.

*edit*

Disregard. I thought you were telling me "All Entities can be filtered with Alt + 2". Misread. As to say, "oh you can do all that with alt + 2". Yes, filter entities as well.

Your flames are making white light. Also it's a bit dark. I'd modify your original design to allow more natural lighting from your sky shader(If it's emitting light.) Or crank up the ambient a tad. You don't want people to have to squint to pick out your geometry. You can still keep the same vibe, but have a better lit play space.

During bsp, a recursive operation splits the map into volumes based on the planes of the structural brushes. (The entire grid of the level is treated as the initial volume)

The newly created volumes are called child volumes. If the recursive(repeating) operation encounters more structural brushes inside the child volumes it will create more child volumes inside those child volumes until it no longer encounters structural brushes inside a volume.

Now this may seem confusing, but trust me you need to know it. This is the first stage of how visibility is handled. You see, during the vis process, where one face of a volume is constrained by another face a portal is created. (Use the portal viewer on a bsp compiled map and you'll see) This is where terms like PVS(Potentially view able set) may seem familiar. For a player in a node that can see through the portals into other nodes will render the geometry in those nodes. (Which is why you need to think about angles and hint brush usage)

IN ANY CASE.

You have an extremely unnecessary large amount of structural brushes in your level. Hopefully in my explanation above you can see why. The only brushes you need to be structural are ones that are necessary for culling geometry when it comes to vis in your level. All the small details can be made into detail brushes (The recursive operation ignores these). A some what silly rule of thumb(because it may not always apply) is to keep walls, floors and ceilings structural. For the player is not supposed to see through them, no? 

Things you don't have to do

-Detail brush your patch meshes. (Patch meshes don't affect the vis no matter what you do to them. You can ignore them.)

-Detail brush brush models. (These are brush entities like trigger_multiples, func_doors, etc.... They too will not be used to determine volumes. Safely ignored.)

-Detail brush most translucent brushes. (Stuff like clip. Obviously this doesn't apply to hint, area portal etc...) 

*edit* I'm sorry, I forgot to tell you what to do.

Select the brushes that do not need to be structural. Right click the grid and press "Make Detail"

-or-

Select the brushes and press Control + Shift + D. (Preferred) 

To see how you are progressing filter out detail brushes with Control + D.  It also helps to filter out patches Control + P and translucent Alt +4.