Raap

Couldn't be done with existing scripts, or couldn't be done without significant code changes? I think we're quite limited in terms of physics, unfortunately, as I could come up with a lot of interesting gameplay if I had the means to alter physics on demand. Speaking of falling, how about updating the falling and jumping animations to loop better? They are rather bad to look at, and it's especially noticeable on Paradox. Might be worthwhile since any future water changes will likely use those animations anyhow. Still, @Pushwall consider applying Demolition Truck logic to kill passengers aboard naval units on their destruction to partially remedy some of the naval gameplay weirdness, even if that won't solve the appearance of the water.

I've never had the opportunity to look at other W3D projects so I didn't know. That being said, swimming is also a gameplay design choice and I do not believe APB specifically even wants to have that. But slowly sinking and drowning, as well as slower movement on the underwater surface, along with all the expected visuals, would make more sense. Right now for example when your Destroyer is, well, destroyed, your character ejects and starts falling through the "water" at top speed and clear view. It always triggers me when I see it. A band-aid solution might be to somehow freeze the camera in place when your ship/sub is destroyed while you're still in it, until you respawn. This would mask the fact your character is actually falling through the water. Additionally, it could fix that "shoot the enemy while falling" issue if input is disabled via a scripted death similar to Demolition Truck logic. Same logic could then maybe be applied to aircraft if their death is caused by collision. Unfortunately I have no idea if any of that is easy to pull off. I'd wager a cinematic effect could be employed to freeze a camera (maybe allow rotation), but new scripts would have to handle everything else.

As Einstein suggested, you can intentionally throttle your upload rate in order to on-demand "lag switch". It's an unfortunately quite common problem in online games. You got two solutions: Move hit detection to server-side (good luck with that). Add auto-kick safety measures that boots people with high ping spikes. The latter is a common solution, unfortunately it also affects people who legitimately cannot help their Internet situation. It's a tough call to be sure. I personally haven't noticed much lag switching in W3D - plenty of rubber banding at times though but that is something else. It also doesn't help NA players much, since the servers are hosted in Europe, and NA network infrastructure is known to be a wreck, it could potentially false flag a lot of NA players due to their relatively higher pings. in a perfect world however we'd have two servers; One in Europe and one in NA, with the playerbase to consistently fill both servers. Unfortunately splitting the playerbase right now would not be a wise decision.

I remember @saberhawk experimenting with water effects some time ago, but I don't remember exactly the reasons for why he dropped it. It's no simple subject though. You need to consider a large number of factors such as how it looks in relation to depths (you need more transparant edges compared to water that is further out), caustics simulation, wave and shore simulation, and a range of textures designed by someone with an understanding of how water actually looks - which is more challenging than you might realize. Then you've only done the water surface appearance and have yet to work on the gameplay logic and underwater logic as well as appearance. You also have to create a camera logic enhancement that enables plane clipping to draw a different surface on-screen in order to eliminate having a clear underwater view when clipping across the water plane (alternatively, create a way to make a camera-no-fly zone of sorts that pushes the camera up and down either fully submerged or surfaced). Finally, you have to consider expanding the physics to include an actual concept for water/swimming/drowning without it just being a damage script, and optionally you also have to consider infantry character swimming/drowning animations and behavior. In other words, to get water done properly on W3D, you're looking at a lot of parts to achieve it. For what it's worth, my 2 cents on this is that it would be a worthy addition to the W3D engine, since water is used in nearly all levels for all W3D projects.

I've so far only done it where elements visibly connect (example: a pile of meshes stacked on top of each other that then got merged into one mesh), making sure certain areas properly connect to form a single element. I wasn't quite thinking of going so far as to make "hidden bridges" between every element, unless of course that was proven to be an actual increase in performance. Only Saberhawk would have an answer to this question though. Anyhow, this just goes to show that working on asset creation has layers upon layers of challenges, which are simple to me now, but starting out fresh with no knowledge and limited documentation has to be a real problem, and certainly a large barrier to entry.

Yes.

You're a true Lag Wizard.

My concern lies with rendering performance. We always speak of draw calls but never how to gain maximum optimization out of a single mesh. I'd wager it's probably best to connect elements where possible even if it meant adding unseen polygons to make said connection, but that's my assumption based on other game engines.

Creating terrain can be considered simple, if it is a simple terrain. Terrain can also be complicated, if you are creating a complicated level. There is different kinds of complications as well, for example creating the iceberg naval landing spots on Hostile Waters requires a lot of knowledge on W3D collision logic, where as the walls on Siege requires a lot of UVW texturing knowledge as well as good use of texture-creating tools (I use GIMP). If your terrain goes off the beaten path and into unknown territory then you're opening up several possible cans of worms all the time and you're constantly revising your creations, and what this all comes down to is knowledge + experience = less time used. But, you got to start somewhere, so starting with a "simple" creation is fine... My advice however is not really to keep it simple, but to keep it small. The larger your terrain, the more work is required to fill up the space. Anyhow, if anyone decides to give it another shot, I'm available for advice. Edit: There is no real polygon limit. W3D is mostly picky about something called "draw calls", which refers to individual meshes. The trick is to create a level while keeping that number below 1000 approximately, but this includes trees and LE-generated assets. The best way to count your draw calls is to perform a vertex solve, the number displayed there is the number of unique meshes being solved. If that exceeds 1000 or so, then you have a lot of optimizing to do. Additionally I have asked Pushwall to forward a question of mine in regards to elements within an object or draw call. You can create meshes in two ways; connected as a single element, or not. Some engines prefer the former, but I'm still awaiting an answer regarding to what W3D prefers. Anyhow, this is not something very relevant to any fresh starter, but mainly just to me as I create tons of new assets per project. (To advanced users, this is my question: http://i.imgur.com/O2wSBkf.png )

Stuff like the water logic and appearance could be improved upon if there was a programming contributor with the required time and skill-set to take on the issue.

Yeah I know, it was just a randomcrazythought.

All these Ore Truck tactics made me wonder, what if Ore Trucks get a new combat support role: Heavy duty base perimeter breaching units? By giving them strong resistances to base defenses, you could actually do an Ore Truck rush to breach the enemy teams base defense perimeter (within reason).

What do you mean, "were"? Desolation was actually a map on a floating rock in what can probably only be described as 'space'. I don't recall the exact details, and that's probably for the best. They were made a decade ago using even older tools (Gmax, eww) and less experience on my part.

Not to mention more performance drain. As it stands, vehicles are a key factor in the diminishing performance as a match progresses and more are used on the field, and that is because of their complexity in regards to the model and rigging. Apply similar heavy-duty logic to infantry as well and you'll have very significant risks. Why over-complicate the game anyway? Or why make it more latency dependent? I'm a strong believer of "if it ain't broke, don't fix it". Body shots do normal damage, headshots do more damage. This is a tried and true concept that worked for countless years of FPS gaming. If you want to innovate on gameplay, do it in areas that W3D actually excels at, rather than attempting to emulate modern competitive shooters. It's all about the overal gameplay, not just the gunplay.

Oh God, what have you started...

For reasons I mentioned. That route was not designed with any synergy in mind with the rest of the map, and it is part of the reason of why I blocked it. To open it would require the castle interior to be re-created to connect to it as well, all in all a lot of work, and performance on the client is already being pushed a lot. However it is there as a backup if it were truly required. Similar to people having a very strong desire for a land route on Hostile Waters, and that request I am actually working on (slowly).

The beach IS accessible to infantry, though, unless you mean the rear one. ... What wonderwall... ? The easter-egg is not part of terrain itself.

I did always reserve map space in the rear of the castle in the event a single split-lane approach would have played better for vehicles, but the problem was that Siege was becoming far too large, so over the course of development I trimmed a lot of space; The castle underground tunnels are nearly completely axed, the castle interior got fully axed with just one room visible as a background, the castle rear (top rampart and island) got reduced to just space for aircraft pilots to climb out from if they happened to crash there, the castle roof became inaccessible by normal means, and recently even the secret area got axed because of performance issues. The problem is if you have a map this large, you need to fill it up with a lot of detail which drains performance. I've had to cut down a crapton of detail for this reason, which is why for example the Soviet base looks relatively plain outside. I went for clean approaches on both bases, the Allied base has a theme of "lets hug the trees in the forest", the Soviet base has a theme of "let's burn down the trees and destroy the castle wall to get in". Clear visible themes that didn't require a lot of detailed props to show them. But enabling the castle rear route for access would add more stress to the client and I do not believe that single forked vehicle lanes really work in APB gameplay. Having two completely separate lanes towards an enemy base is a tried and tested concept that works, see Keep Off The Grass. Although I personally am not a fan of splitting up fights in that way and prefer to keep the action centralized but with various means to access that fight. However, if the vehicle game did turn out to be completely unplayable, I left those rear passages as a backup to be re-opened... But I do not believe this is required at all, and also note that those rear passages had no real gameplay synergy designed into them, it's like adding a new road that doesn't participate with the rest of the match. Finally, a rear road would eliminate the blockade gameplay, which would result in giving infantry less purpose as well.

You'd just be limiting the appeal. Many players don't bother with mods, and the word 'mod' comes with the notion that a game is required to run them - "stand-alone mod" is a term nobody really heard of before and is easily overlooked. During BHP days EA gave the go-ahead towards doing whatever with the sole condition that no profit was generated. But your concerns aren't totally misplaced, since those loose agreement were with BHP and a C&C development team, two parties that no longer exist. Nothing was ever agreed with on paper and all it could take is one ill-informed EA legal employee to do what EA remains infamous for. That being said, consider reaching out to EA at one point to try and clear things up? Lastly, my post mainly focused on the fairness of the mod classification being somewhat discrediting to all the code reworks on the engine over the years. W3D projects are no more or less 'mods' than any games based on, for example, the unreal engine. Both W3D games and those games use modified engines that were not created from scratch in-house, the only difference is the paperwork (aka, money was paid). From purely a development perspective there is no differentiation to be made.

W3DHub cannot accept revenue from the games provided. However to host services like game servers, donations are accepted.

For editing and encoding your raw footage for free, try: https://www.shotcut.org/ It's not gotten a lot of fancy editing filters but for compressing and encoding your raw footage it gets the job done (you'll need to play with the settings and do some research).

Fair enough. Maybe one of the code-guys can come up with a more manageable tool than whatever it is you're using right now.

20 to keep the level in the rotation, versus 0 votes to remove it, after 24 hours. I'd say that's a message received. Nevertheless I do share the concerns a few people have with the cannons, so @Pushwall should go ahead with my recommended tweaks to them. With that being said, maybe toss in a bonus here by allowing the cannons to one-shot aircraft with the primary fire... And perhaps toss in an achievement for that? We haven't seen any new achievement additions in a little while I think.

Just one comment, I do think referring to these projects as 'mods of renegade' is somewhat invalid. Mods are changes to gameplay based on the engine a game shipped with. W3D launched in 2002, but when you then apply 15 additional years of community driven engine development you start to reach a point where calling it a mod is discrediting to the work of the programming team. Then there is the fact that during BHP days, EA actually gave full permission to allow these projects to be marketed as independent games (providing no profit is generated due to using the C&C IP), and even outright gave the W3D source assets they still had - the full source code was lost, not even EA has it. But according to Jonwil, everything but the AI pathfind generation has been reverse engineered and updated, with this last thing being quite complicated. So essentially, the community has code in their hands that EA does not, top that off with an incredible number of code changes over the years, and you're more looking at a W3D 2.0 than the W3D that shipped in 2002. The vast majority of true modifications offer no engine improvements due to various reasons. You can look at a mod for C&C Generals and recognising it as a C&C Generals mod. If you compare Renegade to for example, APB, you'd not see the comparison, and the few connections you do see - victory by base destruction - is actually there by design due to both games being C&C inspired shooters (to further add to my point; APB features gameplay not native to the 2002 W3D engine in various levels).