MoonDog

+1

You dont need to put the shader in a pk3 until you are finished and testing. Just test with sv_pure 0 and you can leave the shader in the base/shaders folder. Also, textures/colors/white is already a shader in system.shader. textures/colors/white{q3map_nolightmap { map $whiteimage rgbGen const ( 1.000000 1.000000 1.000000 ) }} ^^^^^ Rename yours to something else. Example: textures/colors/my_glowy_white. Also also, make sure you aren't adding the .shader extension to the name in shaderlist.txt. dynamiclight will suffice.

Yeah I've been following the limited previews and play descriptions lately. Its come a long way since the 2013 plays.

did he send them!! so cool man!! hehe!! you should do it !!!

You need to add the custom shader file to the shaderlist in base/shaders. Perhaps the brushes are degenerate and being removed at compile. Try running brush cleanup on them. Or split them if they are complex geometry.

Make a small, square brush at the center of the object. Look under system shaders for a shader called "Origin". Select the origin, the object and turn them into a func_rotating entity.

cool stuff.

http://web.archive.org/web/20120815103646/http://www.japlus.net/index2.php More than enough info there.

You mean they are pretty.

He's not fat, he's big poly-d.

LOL!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!11!11!1one!

I'm going to say words, but don't get offended. I just mean to help. The light textures on those (crates?) look pretty stretched. Aside from that, it look like you are using white lights to produce "illumination" from them. I notice only one stack appears to have light entities close to it. Perhaps you'd be happier with using shaderlighting for those surfaces. Probably a WIP type thing, but i notice some light silhouettes without apparent sources. The black and blue pipes going over that room appear sort of float-y structurally speaking. Considering placing a support that clamps both pipes in their center and then ties into a roof support. Flushes out the detail a bit better. All in all, I'd say you are doing pretty well. Look into using some q3map_surfaceLight shaders to produce some of lighting. If I remember right, that level was pretty low lit and had very cool colors. surfaceLight shaders will help a lot with that feel.

I tend to turn off motion blur in games that have it. Just my preference since I find it a bit distracting.

There are other countries. They speak different languages in most of these other countries. Its crazy. Look it up, I swear. ....lol.

Do some fact checking before offering advice like this. Ungrouping all func_groups could be detrimental to someone who doesn't know any better... Aside from this not doing anything for the entity count, it's a major waste of valuable time.

These are thought processes that can happen while the action is occurring, and the player is coming to terms with acquiring a new mechanic. I'm not saying that's a conversation a player sits and has with themselves (unless they are into game development and trying to comprehend the choices of other developers to improve their own design skills ). I'm not saying it's necessarily a terrible idea, or a no-no to provide a large amount of choices to a player immediately. But you need to do it in a way that is intuitive and adds value to the gameplay. When you are working on the same thing everyday, its really hard to know when you've achieved that, because you can't distance yourself from what you just created. It takes a bit of practice I think. Give your intuition a workout. What, intuitively, feels right to you from a design perspective? Do that. When you play it, if it doesn't feel right, change it. I think when you have a fully progressable first level that people can try out, you can get some pretty good opinions by having it played by a lot of different people. What players actually want, and what is fun are not the same things. It's a crazy process, but you'll grow to love it.

Typically, no. Players tend to like to be introduced to mechanics gradually in a manner that teaches them how to use them, without actually explicitly teaching them. Granted, this is a really old series of games and most people get the idea by now, but giving players a lot of options in equipment right of the bat can come across as unelegant and cluttered if you catch my drift. If you can justify gaining a lot of weapons and facing enemies using those weapons early, then you should find a way to balance it. Players have a lot of thought processes that they might not even be aware of : - Okay, I'm in a bar, shit has gone down. I've got a blaster. it uses energy packs. Okay, that guy dropped a more powerful and less accurate blaster, but it uses the same ammo, so I'm not worried. But wait, this guy dropped a bowcaster and it uses a different resource. How can I use this weapon, is it better than the other two I just got? Should I not use those? Do I have to worry about maintaining resources for both? What am I supposed to do? Why do I have such a large arsenal already? Now I have grenades. I understand grenades, but should I have grenades all the time at the push of a button without switching weapons? Why do I have to switch to my grenades just to use them?! Is there any rhyme or reason to my equipment? What meaningful choices do I have to make when it comes to using this instead of this? Should I use this new weapon exclusively for the rest of the level?

I'm just showing you how I would do it. Global variables. As for timing, other directions, order, etc... you'd need to iterate on your own until you find a way to make it work which makes you happy. This is Icarus. Icarus is weak.

I don't know the inner workings of Icarus in the codebase, but I'm pretty sure affect isn't going to put all entities with the same script_targetname in an array for you and run logic on all of them. I'd need a coder to clarify on that point. I'm also pretty sure that you are only allowed 8 total parms on an entity. I'm not entirely 100 percent on that one either. It was just something I was told when I started modding JKA, and I was never shown any of the coding behind that. But it's a safe assumption to work off of. You might have better luck using global variables so you don't need to rely on trying to pick parms off of individual entities. For instance, this could be a script for one of the blocks. //Generated by BehavEd rem ( "This is just to show what it looks like to declare variables" ); //(BHVDREM) rem ( "You'd usually put all your declares in a separate scipt that is ran when the map starts" ); declare ( /*@DECLARE_TYPE*/ FLOAT, "block1_note" ); declare ( /*@DECLARE_TYPE*/ FLOAT, "block2_note" ); declare ( /*@DECLARE_TYPE*/ FLOAT, "block3_note" ); declare ( /*@DECLARE_TYPE*/ FLOAT, "block4_note" ); declare ( /*@DECLARE_TYPE*/ FLOAT, "block5_note" ); declare ( /*@DECLARE_TYPE*/ FLOAT, "block6_note" ); declare ( /*@DECLARE_TYPE*/ FLOAT, "block7_note" ); declare ( /*@DECLARE_TYPE*/ FLOAT, "block8_note" ); //(BHVDREM) rem ( "SPACING_FUNCTIONS!" ); //(BHVDREM) rem ( "SPACING_FUNCTIONS!" ); //(BHVDREM) rem ( "SPACING_FUNCTIONS!" ); if ( $get( FLOAT, "SET_PARM1")$, $=$, $0$ ) { set ( /*@SET_TYPES*/ "SET_PARM1", "+1" ); set ( "block1_note", $get( FLOAT, "SET_PARM1")$ ); print ( $get( FLOAT, "SET_PARM1")$ ); } else ( ) { if ( $get( FLOAT, "SET_PARM1")$, $=$, $1$ ) { set ( /*@SET_TYPES*/ "SET_PARM1", "+1" ); set ( "block1_note", $get( FLOAT, "SET_PARM1")$ ); print ( $get( FLOAT, "SET_PARM1")$ ); } else ( ) { if ( $get( FLOAT, "SET_PARM1")$, $=$, $2$ ) { set ( /*@SET_TYPES*/ "SET_PARM1", "+1" ); set ( "block1_note", $get( FLOAT, "SET_PARM1")$ ); print ( $get( FLOAT, "SET_PARM1")$ ); } else ( ) { if ( $get( FLOAT, "SET_PARM1")$, $=$, $3$ ) { set ( /*@SET_TYPES*/ "SET_PARM1", "+1" ); set ( "block1_note", $get( FLOAT, "SET_PARM1")$ ); print ( $get( FLOAT, "SET_PARM1")$ ); } else ( ) { if ( $get( FLOAT, "SET_PARM1")$, $>=$, $4$ ) { set ( /*@SET_TYPES*/ "SET_PARM1", "0" ); set ( "block1_note", $get( FLOAT, "SET_PARM1")$ ); print ( $get( FLOAT, "SET_PARM1")$ ); } } } } } Then instead of having to depend on grabbing variables off of the entities, you could read the global variables without running any affect blocks. For this, you'd probably have to setup a script for each block with multiple scriptrunners. Target the trigger_multiple at a target_relay and target the relay at all the scriptrunners. //Generated by BehavEd if ( $get( FLOAT, "block1_note")$, $=$, $0$ ) { sound ( /*@CHANNELS*/ CHAN_AUTO, "null" ); } else ( ) { if ( $get( FLOAT, "block1_note")$, $=$, $1$ ) { sound ( /*@CHANNELS*/ CHAN_AUTO, "my_fruity_sound1.mp3" ); } else ( ) { if ( $get( FLOAT, "block1_note")$, $=$, $2$ ) { sound ( /*@CHANNELS*/ CHAN_AUTO, "my_fruity_sound2.mp3" ); } else ( ) { if ( $get( FLOAT, "block1_note")$, $=$, $3$ ) { sound ( /*@CHANNELS*/ CHAN_AUTO, "my_fruity_sound3.mp3" ); } else ( ) { if ( $get( FLOAT, "block1_note")$, $=$, $4$ ) { sound ( /*@CHANNELS*/ CHAN_AUTO, "my_fruity_sound4.mp3" ); } } } } }

This would be so exceedingly easy in COD script using multi dimensional arrays setup to listen for player damage or action keys.

Would you find the charged shot more valuable if each of the shots it sprays in a row were linked with a line of crackling green energy, that when it hits an enemy does less less damage, but immobilizes or slows them down? Sort of like a closeline effect? Little things like that can turn an almost useless feature into one to consider using to your advantage.

Again though, taking action to adjust mechanics which haven't been tested is a messy way to balance a level. You never ever want to do that. If the weapon creates too much of an advantage, there are a plethora of other easier things to change first. Which will lead to better, emergent gameplay.

You only need one plane of the brush in order to fulfill the function of an area portal. Skip suffices for the other planes. Thickness of the brush is entirely irrelevant, as long as the plane is within the func_door affecting it. If you have problems with vis later, odd behaving area portals, errors etc.... it's best to start with best practices to eliminate the amount of troubleshooting you have to do later on.

That question would be much better asked following playtesting with a few people. If you want to keep the bowcaster in, it's a simple matter of iterating on the combat spaces and NPC's until it feels right. People aren't going to necessarily NOT play something because its too easy.

The hint plane creates a split. You use them to control awkward splits from structural brushes, creating cleaner portal scheming, or for creating a new split in conjunction with structural brushes to reduce the PVS where it wouldn't usually happen naturally from the current structural hull in a section.