Speeder

View File TDU World Editor Introduction After editing by hand some sectors for the next update of Project Paradise, I thought it could be nice to create a proper map editor for TDU. After all, that's the only part of the game which has never been modded before. (and yes, next pp update should come soon, so less pm spam everyone thanks) Description Even if it's called "Editor", this tool is a toolbox to export your files in your favorite 3D editor (maya, 3DS max, blender,... any editor as long as it's compatible with .obj) and obviously do the opposite. This choice as been made simply because I didn't want to make the usage of a cheap and badly written 3D editor an obligation. .obj has a pretty basic structure making easy to build an object from nothing. Features Heightmap Creation/Import/Export Material Editor World Objects Creation/Import/Export Road Collision Support (Havok *-R.shk) World Collision Support (Havok *.shk) Entities Management Soundscape Edition Wire Editor Map Network Editor Security Ramp Editor Green: done / almost done Orange: in progress Brown: just started / researches Red: todo Screenshots Terrain Edition Fast and clean heightmap edition (note: only the Y-axis is used by the game) Untextured/Textured heightmap World Object Edition Imported Untextured Object from a *-O.3DG (some oil station) Imported Road Network from a -O.3DG with a bit of Havok vertex (yellow dots) Terrain, world objects, havok collision mesh Havok Mesh in Editor, Havok Mesh Exported to TDU (early test) Custom low poly mesh (edited plane) exported as Havok Collision Mesh World Object Import (W.I.P.) World Objects with custom pivot point Basic Material Editor Changelog Objects Import/Export UI update Now using collada Complete and detailed user guide inside the archive I'll try to keep the thread updated as often as I can. Opened to suggestions / Q&A / testing (dont ask for that yet :cheeky:) / ... Submitter Speeder Submitted 10/04/2020 Category Tools / Others  

View File Logitech G27 Racing Wheel Fix From Project Paradise, here's a working download link to the Logitech G27 Racing Wheel Fix. What it does, it fix the Force Feedback for the Logitech G27 Racing Wheel. A must have if you play with this wheel ! Instructions: - Open RAR file and extract the "dinput8" file into C :\Programs Files (x86)\Atari\Test Drive Unlimited For full experience, I would recommend to launch paradise_laucher.exe or TestDriveUnlimited.exe with the Logitech controller app. All credits goes to the original creator of the mod: Speeder Submitter Speeder Submitted 05/12/2019 Category Tools

@Minime891 sorry it might take some time since I'm rewriting the tool from scratch (with missing file format support, like .uva and .pmi). :D

@TDUZoqqer I didn't give a thought to it yet. :D Using a blur mask should be good enough (the whole procedural wheel blur they use in Forza is probably way overkill).

TDU2 probably use the same system as TDU1, so the distant sector (here the moutains) uses the 'Area-x-x-x-x' geometry file instead of the 'Sector-x-x-x-x'. To put it short: - An Area folder contains several sectors files + a area bnk, which is used as the highest LOD (level of detail) on the map screen and in game (for the farest sector that's not loaded into memory yet) - A sector acts as the lowest LOD and is (afaik) only used in game. It also contains multiple LOD for sector specific geometry (e.g. lighthouse, ...) as well as an heightmap for the terrain (which is splitted into several patches for tesselation) There might also be a way to edit the way the game streams the sectors (by adding more sectors to be loaded into memory) if it's not hardcoded into the game code. :geek:

[quote name='Minime891'] @Speeder It would be cool if you could look at it but i understand that you have chosen to put your time into some thing else. With out .shk there is nothing that can be done as i'm sure you know.[/QUOTE] I've already started rewriting the whole thing (including bnk depack/repack so that you don't have to repack it yourself, proper terrain tessellation management, multiple sector edition, ...). Havok stuff is next. :D

Don't expect too much from the .shk generation, as far as I remember the MOPP (the bytecode used by the physics engine) generated is totally wrong. I guess it could be cool to give it some time and rewrite a tool for map edition (research papers on MOPP emerged those last years). :D

@Ryzza5 Yep that's exactly how it works :D

Since I'm currently working on a virtual file system (GitHub - ProjectHorsepower/horsepower at modern_io), I thought it would be nice to write a small post about mods (well at least how I plan to implement these). :) Mods are split in two categories: Local Mods: mods applied locally; meaning others won't see the mod. This is typically anything that doesn't interact with gameplay (3D models, sounds, textures, graphics effects, ...). Global Mods: mods applied globally. This kind of mod would be stored on the server, and shared to the connected clients (either direct download via HTTP or simply ask the user to download the mods from an external link). This kind of mods cover everything the local mods don't (3d levels, physics settings, gamemode, time of day, etc.). What does it have to do with the virtual file system thingy? :D Thanks to a virtual file system (vfs), you can virtually build a directory from different locations (zip archives, disk folders, network content, ...). And that's where it gets interesting. With that setup, you can easilly extend the game content without touching your base data. It basically means mods can be shared as zip archives, drag 'n dropped to the mods folder and that's all. If the mod doesn't match your expectations, and you want to uninstall it, you simply remove the archive from the mods folder. Another interesting feature (not implemented yet, but shouldn't take too long) is stackable mods, which let you override other mods content without needing to disable/remove these. Example: -Mod A introduces new car model CarModelA, with its own set of texture, 3d model, sound, ... -Mod B replaces CarModelA texture set, and introduces new textures for environment -Mod C replaces CarModelA sound -Mod D replaces CarModelA texture set, overriding Mod B (but doesn't disable the new textures introduced by mod B) This would work either automatically (based on the archive date) or manually (introducing a priority index or something like that). The folder hiearchy would look something like this: | Game.zip (base game data that should not be modified) | Game/ (folder containing permanent changes, if you want to override base game data) | Mods/ (folder containing mod archives, which can be added/removed on the fly) | Game.exe Last week progress (warning: contains geeky mumbo jumbo :p): Implemented GameObject binary serialization/deserialization Better GameObject API (e.g. component can be added in a template fashion, 'gameObject->AddComponent<Mesh>( "Tree.mesh" )') Better unicode support (which should allow to port the code easilly to *nix or MacOS later)

I fail to see how both project are incompatible. Plus your work on UI looks pretty great, it would be a waste to throw that away don't you think? :)

@Diablo: roger that :D I have setup a git repo with the current codebase: [URL='https://github.com/ProjectHorsepower/horsepower']GitHub - ProjectHorsepower/horsepower: Horsepower - MMO Racing Game[/URL] The code should be compilable (as long as you follow the Readme). There is not code guideline/contribution guide whatsoever yet, if people are willing to contribute I'll make one. :) I've also made a [URL='https://trello.com/b/XgBYgiT3/']Trello[/URL] to manage the project's roadmap

@TDUZoqqer: right now it roughly takes 3.5ms per frame (with temporal reprojection enabled) at 1080p, which is expensive I have to admit. It should be possible to go below 1.5ms ([URL='http://advances.realtimerendering.com/s2017/Nubis%20-%20Authoring%20Realtime%20Volumetric%20Cloudscapes%20with%20the%20Decima%20Engine%20-%20Final%20.pdf']as suggested by Guerrilla Games presentation[/URL]) with some optimization. I guess UE4 volumetric clouds implementation is based on this paper as well, so it should be viable to use these for high quality settings. :) Raycasting; as you already mentioned it's really hard to get stable constraint-based physics (well unless you write your own physics engine as the guys behind BeamNG did :D). My implementation is really basic right now (e.g. I only apply a single force on the hull, I don't support gearbox yet, ...) but is stable even at low framerate.