MoonDog

Developing what?

 

I stopped following Helical Games on facebook because every post I saw was about how many likes your page had, or how you guys were making your website spiffy, or search engine optimization, making your spiffy website pop up nearer the top.

 

I only saw some concept sketches and a very rough low poly model in a long time of allotted development. Perhaps you'd be more interested in a machine for social networking and or advertising development?

You could do all that without entering a 3d package. Select all your geometry composing the fireplace and save selected. Save it as whatever map name. Increase the scale of all geometry by 4 on all axis. The larger things are the easier it becomes to detail and align for an ase conversion. Building at that large scale, align all the textures and make favorable shapes from your image references.

 

Run a bsp compile ---> ase conversion on that .map of the fireplace. Make sure you follow the usual steps for making an ase in radiant. (0, 0, 0 origin on grid, one structural brush etc...)

 

 

Import as a misc_model with modelscale .25. Position, done.

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?

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.

This guy gets it.

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.