Here are my ideas

[Hyphen-ated]

Hi. I like this game. There's a couple of things I don't like about it:
1: It's really annoying when you hit neutral floating mines. Part of it is because it kicks your view so much, and part of it is because it causes a prediction error with the player's position. For me it would probably be more fun if you just passed through inactive mines, but I can see why you maybe wouldn't want to do that.

The pred error when you hit mines I'm guessing is caused because they're only simulated on the server. It would be a lot better if they were all predicted by the client, with the logic for touching a mine and getting bounced away put in shared code. If implemented correctly, your view wouldn't stutter every time you hit a mine.

2: I think the controls would be better if secondary fire just shot a blue ball, instead of toggling a mode. Having it be modal makes it a two-step process to fire a blue ball instead of one, which is clumsier, and I don't really see any benefit. It lets players glow blue sometimes instead of red but I don't think that's a very significant aesthetic benefit.

I had another thing to say but I forgot what it was! I will post it here later if it comes back to me.

[DuckSauce]

1. The prediction error would be the fact that... well... it's not predicted at all! Nor can it be, it's done via a touch function and... apparently Touch functions are broken client side...

2. What Bekey said. Someone else also once suggested that releasing grapple button and then pushing it again could toggle the mode. Change that to be instant fire of blue instead and it'd be exactly what you want, while still allowing people to grapple launch.

Anyway, I'm currently doing experiments with the UDK, so it might be GraviNULL is moving to UDK It's got it's ups and downs so far for me, much like Source hehe, but hopefully I can handle mines alot better in UDK, because there's also the issue of moving triggers(which the mine's are in this case) can't touch the invisible, static and non solid triggers... which is a pain in the ass since it seems to be an engine limitation.

[Hyphen-ated]

Dang, touch functions don't work on the client. That sucks. Hmm, you could try something ridiculous like having the player calculate his distance to every nearby mine on every client frame and hit ones that are close enough. Since they're spherical this miiight work sort of okay? As long as the radius is small enough that it didn't ever cause false positives.

2. It's better to be able to hold right mouse button all the time, so you grapple instantly after launching.

Oh, I think I have miscommunicated. I always bind secondary fire to mouse3 so I think of the toggle as secondary fire.

Mouse1 is absorb/fire, mouse2 is grapple, and mouse3 is toggle. I'm proposing that mouse3 shoots a blue mine instead of toggling a fire mode to shoot blue mines. This wouldn't affect grappling.

[Hyphen-ated]

I needed to predict touch functions on the client for dystopia and I figured some stuff out about them, so I figured I'd come back here and tell you. The bad news for me is that touch functions on nonsolid triggers won't work on the client without some kind of significant code changes in some subsystems that it isn't worth it to me to figure out. The good news is that touch functions can be predicted on the client just fine as long as they're on a solid entity.

Check out http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg15535.html
Most of this code is already in the current version of the SDK, but you need to uncomment moveHelper->ProcessImpacts(); in prediction.cpp like in the second half of Vino's old patch. As long as your mines are solid, that should be enough for the client to run their touch functions. If your mines aren't solid, well, it's probably worth it to you to make them solid so you can start doing this!