Raap

Good show folks, and my apologies for Siege's continued performance issues.

I still broke the game with Siege somehow, VIS doesn't seem to help it out that much. Unfortunately the only option left is to severely cut down the number of trees, assuming of course, that the scripts aren't causing the performance issues. Also, Danpaul's teleport script has a problem in live play (non-LAN), if two or more people use the same teleporter and block the 'exit point', they become stuck. In Siege's case, adding rotating spawns is not an option. The map challenge may have to be removed entirely as a last resort for Pushwall to decide on.

Sure, that's not creepy at all!

And that's when you know you placed yourself in a tight corner; You can no longer not at these units.

Part of the "more player-like AI" initiative, the AI APC driver emulates the "asshole driver" portion of the player base.

Food for thought I suppose. I'll see what options are available to me when I get more time for such things. I also haven't "officially" cancelled a 3rd map yet, but a while ago I've really started to second-guess if another map is in the best interest of the project, and whether or not I should contribute something else instead, such as fixing/brushing up Siege and HW, or contributing some "generic assets".

Much less time than I likely would have needed, due to my lack of experience with the culling system. Not doing air sectors was a good decision, as I was mostly stuck on theoretically dealing with that issue. I did notice one blind spot in the Soviet base tunnel near the War Factory, but that's it. Anyhow, I'm not sure if giving the map another visuals pass is the right thing for me to consider, since it would counter your VIS efforts.

Far too long and I do apologize for this. Must have been quite a challenge juggling the several terrain files that make up the map as well.

SORRY! As for bots being smarter, smart enough to have attack plans (pre-designed I imagine), and smart enough to understand the concepts of credits and purchasing, I can safely say I didn't see that coming. If they are more developed beyond this point while also not being a huge performance drain, then tossing them into all existing maps alongside playercount scaling effects (more players = less bots) would start to make more sense (more sense, moon sense, SEE DAT?).

You need to make a clear difference between a silo or refinery theft, because stealing from a silo is in nearly all cases much easier. I also think you need a satefynet for large games. Typically in large games, personal credit capacity is higher due to more people harvesting or less pressure on each individual player due to combat load spread. So essentially a scaling effect that results in a lower theft percentage with increasing population sizes, from 50/30% (refinery/silo) at 6 players to 30/10% at 20 players. Finally, I really dislike the "instant theft with only a text message to inform you" logic. I think stealing should require an interaction with an object that uses a "casting bar mechanic" similar to flare deployment. This will give Soviets a chance to interrupt the process and make zig-zag suicide ninja thieves not viable. Perhaps the easiest way to make this work is to create a flare-type weapon that has a casting time and uses a warhead that causes a script to react and initiate the stealing mechanic. You'd obviously need to create this script logic, along with a tool and thief animation... Probably the thief crouching down to plant some device on the ground and pressing some buttons to initiate the ritual voodoo magic... (?!?!) With some luck, you might find a suitable stock Renegade animation for this, although those are pretty bad mostly.

I haven't been able to play recently or catch a filled server when I could, but my 2 cents: I always thought the limited ammo super repair tool felt gimmicky. It prolonged matches unnecessarily due to being a cheap, solo, and low-skill ceiling counter to any team-based attack. It does have use in Hostile Waters due to neutral building logic, so a change would need to be made there. I'd say ditch the wrench model and give engineers a re-textured "Improved Repair Tool" which repairs very slightly better. Engineers retain their purpose with C4, mine-clearing and detection, and general repairs. Removing the wrench reduces the inventory clutter that Engineers have.

Other duties prevented me from participating. Hopefully you had fun!

I'll attempt to make an effort to be there (although probably somewhere between the EU and NA times). As for april 1st, maybe the joke will be Siege gaining better client performance?!? (hint: NOPE).

He's still floating around:

Fair enough. I didn't mean to trash his work as a whole, after all, I don't have the full picture on these events, since they occurred when I was not around. Since I feel my comments might appear too 'harsh' due to the way I write sometimes, I'll refrain from commenting on this subject further.

It's a great shame someone can just walk in with 'contributions' that literally messes up other functionality, to the point where even removing it becomes a risk. Perhaps at the time, a rollback to pre-CJ might have been the beter solution in the long run. Not much you can do about that now anymore, I suppose.

The Supply Truck logic is a good one, especially for C4, so nothing exists there that I would change. But for reloading-while-unequiped, you name Volkov as the worst case scenario and rightfully so. But the current usage is not much different, players can pre-reload both weapons and use them in succession right now. It'll be much more user-friendly in general to still make Volkov reload while using a different weapon, and just balance this edge-case accordingly via increased reload times. Unless memory escapes me, Volkov still has a standard pistol sidearm as a backup? He could use that while waiting for those reload times. Rocket launcher is a valid concern, but then perhaps exceptions can be made. In this particular case the reload time isn't much longer than ~1.5 seconds, so you can still apply the reload logic change here, but instead implement a weapon-lock-on-swap delay mechanic that emulates the reload delay slightly and independently of the actual reload speed. Naturally, both reloading and weapon-lock-on-swap delay logic are both functionalities not presently available on W3D, so there is that hurdle to overcome... But either way, having these two options available would improve your balance toolkit and also improve the general player control "feel" the game has. Edit: Then there is the question of sprinting cancelling reloads as well. In my opinion, ideally you don't cancel reloads while sprinting, but you put them 'on hold' to continue for the remaining duration when sprinting stops.

I remain of opinion that there needs to be a way to continue reloading during a weapon swap, it is just very counter-intuitive that you currently cancel a reload by switching.

I think that the type of armor and the resistance values of them versus each weapon should ideally be listed in-game somehow. APB unit and weapon balance is quite 'complex', well beyond the days of Renegade where only a select few damage types and armor types existed. Frankly, if the in-game GUI could be more easily modified, I'd suggest having a complete mini-wiki available, with a page of information dedicated to each unit, building, map, etc. with detailed information (not just 'strong or weak versus'). But then again, countless other GUI functionality has been wished for in the past, from 2D/3D level maps with live building status information, to map-specific GUI tie-in capabilities. I'm assuming anything GUI related is just hard to do.

If purchasing alone was an issue (but it's not, entry/exit transitions is what lead to this conversation), then what you could do is stop having the MK.II walk out of the War Factory on purchase, but instead be delivered via dropship, similar to how helicopters are purchased in APB.

Yeah, a sitting dog position would look fairly... awkward... Axing the wheels idea and sticking to tracks, you can make them quite slim with the bulk of the "logical design" hidden within the leg segments. More fancy still, you could hide and show the tracks based on the animation state via "deployable" logical design, which means that during the transition animation, you also make the leg segments 'flip open' to withdraw the tracks. The whole 'resting dog position' for the MK.II makes perfect sense to me. Ever thought how hard it must be to perform maintenance on a legged vehicle that cannot lower its body? Or ever considered how you'd transport an MK.II across continents when it has no compact form? Plenty of logic to be found in this direction. Obviously, the tracked/resting travel capacity would be very limited and slow, and purely intended for non-combat purposes.

Pretty substantial patch, Pushy. Let me quote something to highlight it as this is quite a game-changer that could easily be overlooked in this wall of text you call patch notes: I'll run through some of the changes tomorrow, and I'll post if I see anything unintended.

I've played most Zelda games except for this one and the previous Wii U one, because unfortunately I no longer feel like paying for a completely new (and expensive) console for just one game, when the last consoles I even remotely touched were the Wii and Xbox One (if I got the name right) when they launched, when I pretty much learned consoles aren't for me anymore. But I'd lie if I said that I don't feel like I'm missing out on these rare, select few "good" console titles!

Something that comes to mind here then, would be to have two MK.II presets, the current 'walking' one, and a preset for an unoccupied "resting" state; imagine a resting dog position with the legs pulled in, in order to lower the body to the ground. This would considerably reduce the scale of the physical model, and allows you to 'fix' the transitions this way. Naturally, scripting logic would need to be created for this, as well as an animation that transitions between the two states. Bonus point here is that you could add wheels or tracks to the sides of the legs that would enable the unoccupied version of the MK.II to ride while in unoccupied 'resting mode', meaning also that the GDI War Factory doesn't need to be idiotically huge if the MK.II can come rolling out of it in this form.

Isn't this a case of simply editing the transition zones, or has the MK.II reached a scale that somehow goes beyond the size limitations of transition zones?