Veyrdite

Released in December 2002, Nod expressions are some skins I like to use with IA to make my low-caliber vehicles seem a bit kinder. How couldn't you love that transport copter? Original download link . Mirror: nod_expressions.zip The author for this pack is listed as "RenegadeZone" Diane, which I think might have been James Bunting's partner. Kudos to them for keeping this site online, so many skins on other sites have been lost to the internet dark ages. I didn't like the Nod buggy skin in this pack so I made my own variant a while back: Download: v_nod_buggy_.dds For those that find the hard, cold floors of Nod buildings oppressive: delight yourself in luxurious, thick red velvet carpet: I have no idea who made this skin, I've lost track of the original archive. Nonetheless it's kept me warm and comfortable for many years, so I'd like to share it, and hope that I will rediscover the anonymous upholsterer so I can attribute them properly. EDIT: compression has utterly destroyed this screenshot, it looks much nicer than shown. Download: gd_flor.dds Finally, I had a bit too much spare time at the Nod air-depo a few years back: It's amazing how many airframe washes some crayons can last. Download: 19_c130.dds

I put some of the changelogs into a free neural network service. Some highlights: Now we know the real plans for the 2020 releases :D EDIT: My god, this could easily be confused for actual mod feedback. What have I done.

Topology wise: it's very similar to many maps. Both C&C_Field and C&C_Under have one open route, one infantry route and some overlap in the middle. EDIT: many IA maps follow this too. Texture wise: yes it's going to look like other maps. I've kept the custom texture count low, it's mostly using default renegade textures. If this map turns out to be any fun then I'll make the main map geometry prettier. Hopefully I'll be able to give this a play online against others soon. I'll contact DB and see if he is kind enough to put it up on his ttfs.

@Kaskins do you want us to provide our feedback in this announcement thread, or elsewhere? The humvee felt very weird at low speeds today. Not sure if I just hit some random oddities or if the low gears have changed. Goliath weapon changes are going to be interesting to see, I'll have to give it a go. Ditto for the physics changes on the strykers and ships. Dynamite changes: that's like clipping KTFF's wings! You monster :D Infantry re-arrangements: nice to see the suit'd versions of characters now cost more, so hopefully strategies other than PIC suits will come more into play. Projectile velocity equation: interesting. I know from previous experience on another game that projectile speeds are hard to get right, and that putting random numbers in (as I do) never seems to cut it without lots of iterative testing. I presume by "weapon size" you mean the shell diam, and that you're only applying this to non-gravity shell weapons? > Vile Facility after multiple complain I have make the out of the map a death zone. An instant-death zone or one that warns players as they approach it? If this is invisible it's going to be hard to work out where is allowed and where is not (until you try it). Hopefully not invisible instant-death, that's the brother of invisible walls and the child of Vanquisher turrets. > Vile facility tree’s are now temp permanently indestructible. Yes Eco warfare. 

A small golf-themed map with infantry-capturable turrets in the centre, intended to dominate the field against vehicles. May contain visceroids. This map is a Work In Progress: I'd like to see what people think of the overall map concept and layout before I attempt making things pretty. Many maps follow a "two path" design, where the infantry can weave in and out of both paths but the vehicles can only use the larger one. This map is an attempt to make obtaining vehicle 'control' of the major route more complicated (and affected by the minor route). Various curiosities: A chemsprayer that doesn't shoot "through" the terrain visually, and a general appreciation of projectile (ammo) elasticity. Objects with curious physics. A minified airstrip. Absolutely zero secrets I wanted to name the map C&C_Golfcourse, but it turns out ACK beat me to it. In the tradition of my username I named the map something difficult to spell until you pay particular attention to the order of the letters >:D Thankyou to scripts authors: namely Danpaul88 for dp88_AI_Turret, Blaney for DB_capturable_object, and Jonwil for helping me with my long lists of LE/W3D issues. Known problems (1) Airstrip drops do not drive out as far as expected. I'm not sure if this is due to a hardcoded timeout (slow vehicles are more affected) or the sudden drop. (2) WF has a few glowly-yellow decals floating above it where the chimneys normally are. (3) Bad meshing of the two golf greens (note the dark areas). I'm fighting Gmax when it comes to cuttings and small polygons. Requirements The turrets on this map need scripts 4.x to work. Scripts 4.x is not bundled with this map, download it from TiberianTechnologies.org. License AKA "oh god, I've never thought about how licensing for community maps works." This .mix file contains original artwork, 3d models and other assets. This material is under a Creative Commons BY SA license, copyright William Hales 2019. Use a tool like XCC mixer or RenegadeEx to identify and view this content. This map uses and references material from C&C Renegade, Copyright 2002 Electronic Arts Inc. You need a copy of this game+data to play the map. This map uses scripts from TT Scripts 4.x (GPL, source available online). This map, as far as I can tell, only references ("links") to scripts, however I may be incorrect. C&C_Goldcourse_WIP1.mix.zip

30 second clip: one of the oldest Rene tactics is ramming. With IA's faster vehicles and lots of ledges it's getting more and more tempting. vehpush crf25.mp4 No audio, sorry. I hadn't fixed my audio recording setup until later.

> Based on what Dblaney said Renegade is capable of going beyond 60fps but is best not to as if your fps is higher than the server it may cause some de-sync with the server ( server fixed at 60? ) or at least how I interpret Dblaney message. I regularly play in the 100-200 FPS range, never thought it was an issue. Is DB talking about physics timesteps here? The contributions of these (1/60th of a sec vs an arbitrary 1/framerate of a sec) are probably minimal compared to the effects of ping. Being 250msec behind in your simulation and having different inputs to the server (your player's input) are going to create a lot more divergence than a smaller physics timestep will do. Shared "lockstep 60FPS" physics is only achievable over LANs, not the internet. > In addition, IA texture size are restrict to 512x512 and I refuse to go beyond it, like 1024x1024. Thankyou This will mainly affect laptop/integrated vs dedicated users: ie people who have limited VRAM or bad RAM<->card transfer techniques. I appreciate being able to play games on my laptop. > We need the processor that will make single process program to be able to run by multiple cores. We're unlikely to ever see a processor that turns a single-threaded job into a multi-threaded one, it's too hard of a problem to solve on paper let alone in hardware. Maybe if quantum computing can quantum-teleport/syncrhonise states between multiple cores & mirror memory banks in some weird ways that might perhaps help, but that's a dream. > Yes HUGE difference in directX which may be game breaking since Renegade is single threaded I don't follow here. Is there some inherent performance loss from using a newer directX that can never be worked around, due to threading? Or is this just a general statement (unrelated to the DX implementation change)?

Prerequisites First read and follow Laubi's original tutorial on "Harvester AI Pathfinding" (W3Dhub link). This tutorial has been around for a very long time. The attached "harvtest_paths.zip" file contains three example .mix maps for you to try out, each one is mentioned in the appropriate sections below. To play these you need to: Extract the .mix files to your Renegade/Data/ folder (typically C:\Westwood\Renegade\Data\) Start Renegade Choose "Host a LAN game" Change the settings to be: Max players = 1 Dedicated = no Map rotation = any one of these three maps Between the buildings on the map is a flying harvester that you can enter. Flying above the map makes it easier to see what is going on. You should be running an up-to-date copy of TT/scripts and the latest version of Leveledit (not the version shipped by Westwood, see the TiberianTechnologies website). It contains several fixes that may affect how well you can follow the techniques in this tutorial. Introduction We're on an island floating far above a lava ocean. On one side of the island are the Nod & GDI bases, on the other far end is the tiberium field: In between the two bases is a maze with many possible routes for the harvesters to take First: setup your map as normal (and as per Laubi's tutorial), but don't create any waypaths for the harvesters just yet. Make sure to place the "Human" pathfind generator and generate pathfinding sectors for your map. In LevelEdit you can show the generated sectors using the menu item Pathfinding->Display Sectors: Note the greeny-blue boxes that appear. Each one is a 'zone' that objects can travel within, and each connects to the sectors that touch it. Objects in the game work out how to get from point A to point B by following a chain of these sectors. You do not actually need to create waypaths for your harvesters Despite all of the traditional advice: harvesters do NOT need waypaths. They can find their way to the fields and back all on their own using the pathfinding sectors. The only waypaths you need on your whole map are the short ones exiting your Weapons Factory and Airstrip, so that vehicles drive out a little after being created. By default harvesters always start in this 'self-navigating' mode once they leave the WF/Air. They only start using waypaths when they "accidentally" encounter one whilst driving (and several other conditions are met, described later in this tut). If you don't believe me: try it. According to JonWil there is no special code (in Vanilla Renegade harvesters) for handling waypaths. My understanding is that they incidentally can use waypaths because the W3D engine's normal innate pathfinding code (used by all AI) handles using waypaths. On the example map for this tutorial: harvesters are picking a non-optimal route when left to work things out on their own: Try the map C&C_Harvpath_nopaths.mix to see this yourself. How do harvesters "enter" a waypath? (1) When a harvester is created: it uses the pathfinding sectors to find its own route to the tiberium field (or other destination) and starts on this route. (2) Every time the harvester enters a new sector it checks to see if there are any waypaths that start in this sector. A harvester will only follow one of these detected waypaths if multiples conditions are met: The path is of type 'innate' The end of the path is closer to the harvester's target than where the harvester currently is. (Possibly some distance or number-of sector metrics, unknown) Once the harv starts following a waypath it will not leave it until the path ends. How do I design my waypaths? First find the path your harvesters take on their own. Play your map in-game to find out. Next create a path that starts from one of the sectors your harvester crosses. End this path near (or closer to) the tib field: Try the map C&C_Harvpath_Pathed.mix to see this working. Both harvs end up getting caught by the one path in this example (but you generally want to add separate paths for each), and the path is not perfect so they start grinding against the walls. You can use any type of waypath provided in LE, they're all the same: I actually use the 'flying vehicle only waypath' just to make people feel unsettled. The only requirements are that you change the waypath settings to enable 'Innate Pathfind' after you create it. You get to this dialog by double-clicking a node on the waypath (not the line part of the path): Two-way is an option that is legitimately accepted by the game and useful to consider. The Human/Ground/Air fields appear to do nothing at all, you can even un-tick them and your harv will still follow the path. You do NOT need to re-calculate pathfinding after making or changing any waypoints. Waypoints are a separate part of the system that are handled during map export (to .MIX). This feature may be buggy in older versions of LevelEdit. Here's an example of a waypath that will NOT work. Note that the path now starts in the doorway of the maze, rather than in the sector outside of it. The harvesters never cross the pathfinding sectors in this doorway, so they never 'see' the path: They may however 'see' this path on the way back from the tiberium field, assuming the path has been marked as Two Way. Harvesters will use your path as long as (1) you start the path in a sector the harvesters already drive over, and (2) end the path closer to the goal than it starts. This means that you can give them really stupid long routes and they will still follow them, such as this: Try the map C&C_Harvpath_Stupid.mix to see this yourself. Note that one of the harvesters takes a 'shortcut', I am uncertain of the exact logic behind this, but I believe it notices the nearby waypath nodes when it crosses sectors whilst leaving the Weapons Factory. If we were to end the path at a position further from the tib field than where we started then the path will NOT be accepted/chosen by the harvesters: (They could potentially choose this path on their way back, however, as its end may be nearer their "goal" (eg the GDI refinery) than their current position). Conclusions Confusions, comments or problems? Ask below or on the main W3Dhub forums. Areas that are still not understood: Whether or not this 'innate pathfinding' is exactly the same for all AI in the game, or slightly different for harvesters. What metric is used to make choices on route. Eg minimising distance travelled OR number of sectors travelled through? How harvesters start waypaths at points other than their ends (ie take shortcuts) harvpath_tests.zip

I've only really ever tried the marauders, and I too found them slow + limited. Since then I've avoided the forgotten, assuming they are all like this. I'll give the templar a go, thankyou. I believe Kaskins/Dblaney told me at some point that a set of unique buildables for the forgotten was planned. Related reading: some references to forgotten plans were made by Kaskins in the 'extra tier-0 troops' topic.

TL;DR: this game is really nasty to play on my computer. Vanilla rene and IA (scripts 4.x) don't seem to have this issue. I played APB online this morning and suffered horrible frame-stutter issues across the few maps I was there for. These are the first proper (player-filled) APB matches I've ever played, so I'm not sure if this is a new problem (due to scripts 5 overhauling the renderer) or not. I'm running my games on Linux using Wine, so I'd like to see if any Windows players are suffering similar issues. Please comment if you think you are seeing the same thing in the new RA:APB or if you have a better/perfect experience instead. Overview Even when the game is reporting 90FPS and higher my game "feels" like it is around 30FPS. Stuttered camera movement and frames, input delay when typing, etc. Settings played with All of the W3D quality sliders at minimum, vsync on or off (my graphics drivers triple-buffer regardless), fullscreen vs borderless, extra shader toggle boxes (do these do anything?) and shadow toggle boxes turned off, MSAA at 0x. Background information: the difference between frames per second (FPS) and frametimes (FT) I'm going to assume you know what frames are and how they are used to fake motion on your computer screen. It's the same concept as frames in videos/film, so have a read about animation if you are not familiar. I'll simplify things down into two types of frame: Rendered frames. These are the frames your game makes. Displayed frames. These are the frames that display on your monitor every time it refreshes. They are not the same thing. Most monitors refresh exactly 60 frames per second (this timing is typically accurate and reliable to better than 0.01%). This means that once every 16.667 milliseconds they can 'refresh' to display a new frame, or keep displaying the old frame for longer, but that's all they can do. Your game and computer render frames. Each frame takes a different amount of time to render, depending on the complexity of what is being drawn and the algorithms (games & graphics drivers) being used. If you are facing a wall then a frame might only take 0.53 ms to render, but if you are looking at a battlefield full of 100 players and tanks then a frame may take 80ms or more to render. For good quality "motion" to be perceived by players on their screens, each refreshed frame must be: Unique. ie no frame lasts more than one refresh cycle. Equally spaced in the game-world's timing. Ie each frame should show the same amount of time elapsing in the game, not one frame where things move further/faster than in the others. Bad quality motion makes players feel uncomfortable (headaches are common, motion sickness less so), makes it harder to aim and generally makes it much more difficult to enjoy the experience. There are two common ways of measuring motion quality in games: Frames Per Second (FPS) and Frame Time (FT). FPS counts how many frames are rendered every second. Typically you want 60FPS or higher, so that (ideally) your monitor has a nice new unique frame to display every refresh cycle. Higher than 60FPS "feels" better most of the time (due to better physics & input timesteps -- outside the scope of this intro), but can sometimes lead to a 'worse feel'. Many setups cap your framerate to a maximum of 60FPS due to a feature called vsync (again outside the scope of this into). FPS measurements are fundamentally flawed in a lot of situations, because the frames being refreshed on a monitor are not always the same frames being rendered AND FPS only informs of an average result, which is not what humans experience. Take for example: One frame is rendered and then displayed for 0.1 seconds. In the remaining 0.9 seconds 80 frames are rendered (and some of them are displayed). Your game will report this as 81FPS, but it will look and feel awful to play. Every second the game will stutter noticeably, which is severely uncomfortable if you are rotating your camera with the mouse (ie aiming a gun). Now imagine a second scenario: During monitor refresh 1/60: (ODD) two game frames are rendered, the second one gets chosen to display because it's newest. During monitor refresh 2/60: (EVEN) no frames are rendered, the old frame still displays. During monitor refresh 3/60: (ODD) two game frames are rendered, the second one gets chosen to display because it's newest. During monitor refresh 4/60: (EVEN) no frames are rendered, the old frame still displays. During monitor refresh 5/60: (ODD) ... During monitor refresh 6/60: (EVEN) ... ... Here the game will report 60FPS, but you will be seeing 30FPS of frames in real life. Half of the frames the game creates are thrown away, the other half display for two monitor refresh cycles each. I've had some games (eg NFS:MW 2005) that do this almost like clockwork on my system. A better measure of animation is frame timing (FT), or "how long did each frame take to make?". Ideally you want all of your frames to take 16.667 milliseconds (1/60) to render so that every monitor refresh cycle shows a nice, new evenly spaced frame. If the frames take too long then your monitor will display the old frame for another refresh cycle (bad). If the frames take a very variable amount of time to create then the physics (eg player/tank movement) on your screen will appear to "jitter". A mixture of both of these problems occurs for every game you play in different amounts. Shorter frame times than 16.667ms will increase jitter, but this tends to be one of the smallest source of jitter (or stutter) in games and is mostly not noticeable. Have a read of my analysis of stutter problems in "The Crew" here (inline pictures have been moved to the bottom of the post) to get an idea of how bad other sources of the problem can get. Vsync (outside the scope of this intro) can help enforce strict and even frame timings, but under certain situations it makes the play experience worse. I believe Rene defaults to triple-buffering by default, which fixes tearing but doesn't clamp timings as strictly as vsync does. Some(?) W3Dhub launcher games appear to have vsync turned on by default. Footage of the problem Note the FPS and FT graphs at the top-left: frametime_RA.mp4 There is a lot of FT variation -- you can see even the 30FPS video has notable stutters. Note the 'odd frame even frame" up down up down timing patterns that appear occasionally, similar to the second bad example of frame timings I describe in the section above. This (edit) typically means that perfectly good rendered frames are being thrown out and the remaining frames are being displayed for multiple refresh cycles. Also note that the variations in timings appear to settle down in the last few seconds of the video when I face away from the bases. This makes me think that view-based culling is taking over and that VIS might not be working. (N.B. I have full-match videos showing similar graphs, but they're at half-resolution and too big to upload here. Toggling my video recording on/off did not noticeably affect the patterns in the graphs.) For a comparison: here is a video of me playing Interim Apex (scripts 4.x) on a map that I don't think has any VIS. Overall the FT stability is better, but you can see it gets worse when I look toward the enemy base (past the airstrip and into the fog): frametime_IA.mp4 Misc: system specs Processor: i5-4460 Graphics: Radeon HD 6850 Graphics driver: in-kernel radeon (default option for Linux users) OS: Linux 4.19.30_1 SMP PREEMPT + wine-4.6 Other games like IA get an FPS from 50 to 300, depending on the map and what is going on. 99% of the time it's above 60 and comfortable, dramatically more so than RA:APB was this morning. Questions VIS issue in scripts 5? Problem faced by Windows users too, or just my Linux/wine setup + the new d3d11 scripts 5 renderer?

Is that what is is? It's beautiful. I thought it was some strange item from a different mod with broken textures, but now I can see the digits. I may admit to saving a copy of your avatar a few weeks back in fear of it being replaced.

A distant silo probably wouldn't be a good idea gameplay wise. As it is this map's existing hidden silos are something I question. An island full of horrifying creatures is something I could get behind. Tiberium affected TOW's driving in circles? AI team 2 peonies? >:D

I would never have guessed it as bouncing. The explosion still looks like it occurs at the correct location. EDIT: that doesn't explain why it's armour dependent either. Hmm. > twiddler *flashbacks* Peony has 1/10000 chance of firing a toy mushroom that harmlessly bounces around the enemy base screaming.

The last time I tried the AMX-30 (GDI vehicle, bottom-left square of the first vehicle menu) I presumed its damage was so low as to be useless. I've just done some tests with it again now and discovered something interesting. It seems that you cannot damage certain armour types if you are <10m away: amx30_damage_crf23.mp4 Lighter armoured targets (visceroids, many other vehicles) don't seem to be affected by this; they always get hurt even at point blank. Here's another example where I'm shooting a map tile: amx30 tiles crf=23.mp4 I've done these tests across a combination of online and offline. Now I'm going to hunt and see if other vehicles are the same IRL explanation: some shells have a 'safety feature' that avoids detonating the warhead until it has travelled a certain distance/time. W3D engine explanation: I don't know of any way to do this with LE presets + armour.ini. I just might not have ever considered some relevant numeric field, or maybe there's some clever in-flight bullet substitution going on via scripts. IDK.

The 'correct' solution is to provide a user-adjustable slider that scales the UI by any amount. This way things can be future-proofed to any screen resolution, DPI and user preference. Unfortunately implementing such a thing in an existing codebase isn't always easy. There's the sneaky problems of font scaling/hinting, which can be anything from easy to nightmarish depending on how font rendering & the scaling are done.

I crashed only a few minutes ago. Context: Map: Winter assault I played for about 1 minute 30 seconds, then my team nuked Nod's ped and won the match. Client crashed after the high scores screen (where you would normally transition to loading the next map instead) I had previously played in this match (~1 hour back) when it started, then I quit to have lunch. After the high scores screen my client crashed instead of progressing to the next map loading screen. I have a video of the last 1:30 of the match, but not one that goes all the way to the error (I stopped recording at the high scores screen). I can't recall if anything else flashed up or not inbetween (eg PENDING or load screen). Something I noticed of interest: similar and suspicious looking score numbers for each team. crashdump.20190427-043716-r8269-n1.dmp EDIT: It looks like all players must have crashed, because there's now only two people playing (including myself). Interestingly I was placed on GDI, even though the only other player was on GDI. I presume the server thought I joined the new match (when I crashed) and was preserving my team.

What? I'm torn between human and robot here.

Was it buffed recently? When I last played ~1 week ago I took one out with a 50cal buggy/humvee. I'll have to try again.

Dang. It would have been fun to GTA the enemy's vehicles that they leave parked around their base.

Dust, bad rubber band, screwed up lube on the stepper rails. All sorts of stuff can go wrong but is relatively easy to try and fix if you open the unit up. Obligatory: not a safe class laser device, do not operate with the case off or with grease (fingerprints) on any of the optics. And don't do you "first test" of your drive by burning a disc, that dramatically increases the power levels (to most of a watt IIRC).

Wow, thanks for that link. There's quite a lot I'm not familiar with.

I believe the anims will be .w3d files, although that won't help you. Yes they'll be in always.dat The best way to look is to open up LevelEdit and have a look at the character & weapon presets. They should list filenames of animations (walking, crouching, weapon firing, etc).

They had the fixed version of the med where the mesh at the back of the turret slants up to avoid clipping through the body? > running animations of Logan running around an empty Nod base, to the FPS model of Havoc's EVA unit.  Can you private time codes? Running animations -> if they're not hiding in always.dat, then it is still possible to make your own. Are you familiar with bones and every tried to animate in Gmax or 3DSmax? If not, it's a wacky and crazy learning experience involving lots of limbs doing weird things FPS model of Havoc's EVA unit -> you mean the thing strapped to his arm? I believe this was used in singleplayer, perhaps only on certain missions?

Do you recall what button it was? "T' is already taken for toggling manual aim on the chinook's tertiary guns.