MoonDog

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.

http://www.quake3world.com/forum/viewtopic.php?t=3620

How many times do you want them to flip back down after being shot? Do you want the range to be resettable at any point in time? Doing what you are asking in itself is simple, but adding in diversity and accounting for player choice complicates the matter a bit.

I don't have any questions. Your maps are some of the funnest I've played from the modding community. Why question that? Just let it happen.

Wow. The man, the legend.

Use parameters or a global variable to track its location. Trying to do checks based on vectors in Icarus is a waste of time.

Hi. I had a multi level callable elevator in my ffa3 plugin, and I dug out the scripts. You'll have to look at them and decipher if theres anything of value to you. im extremely inebriated right now, so i find myself unable to explain whats going on. Apparently I split it into multiple scripts and used a global variable with hand imputed vectors and move times. https://www.dropbox.com/s/bdaebu8q286kkmy/ElevatorFFA3.rar There go. Let me know if it helps

I've made rotating, moving, destructible etc... objects in JKO, JKA, Doom 3, COD4 and ************* and never had to follow any such strange ritual when grouping with an origin brush.

That's like untying your shoes to tie them, to untie them again, and then use the velcro straps.

Yes.

You probably have a leak in the bsp that is preventing you from saving a prt file.

The irony of those statements is palpable.