Duion

Creating such a big terrain alone is not the hard part, the hard part is to build a game around it as well. 8192 basetexture will not give that much benefit on a 4096 terrain. And be aware that you cannot just use random images from the internet for your projects, yes privately you can, but when you release it, you will not have the copyright and it will be illegal, so make sure to use proper free images with the license that allows you to use them.

Found out how the spammers work, they just copy and paste a real post from a real user, in this case this post is copied from Mitovos post here: https://forums.torque3d.org/viewtopic.php?f=2&t=760&p=6290&hilit=Marrevee%2FRichard%27s#p6290

You may need to change the engine in order to make a terrain bigger than 4096, look at here for example: https://github.com/GarageGames/Torque3D/blob/c83efa59e0a11fc15c68afaf106807643191ac6f/Engine/source/terrain/terrImport.cpp Change that to 8192 and see if it works then, if not it needs probably more changes. I have not tried 8192 terrains yet, but I know modern graphics cards can handle that big textures now, so it should work.

180km² is extremely big, why not go smaller to begin with? Even games like Skyrim that seem huge are not that big actually, I think it is 5x6km or so of playable area, which is only 30km². So you see even big companies often chose smaller world sizes, because of performance reasons and because of costs, since the world has to be filled somehow. If you want bigger terrains you have to use trickery to make it work with good performance. If you still want to do it, here are the limits of the engine: The biggest working heightmap by default is 4096x4096 which results in a 16km²world, a 8192x8129 heightmap should work as well, since modern hardware is capable of using that big textures, which results in a 64km² world. You can also vary the square size in Torque, normally 1 pixel is one meter in the game world, but the larger the square size is, the more chunky and low resolution the terrain gets, my personal limit is square size of 2, but it seems you can also use numbers like 1.3 etc. So the biggest possible terrain in Torque without getting too ugly is 8192x8192 heightmap with square size 2 which gets you a 256km² terrain, in case you get 8192x8192 textures working. You can also stitch multiple terrains together, which would then lift all limits, but there is an ugly seam at the edges, someone coded a solution for it, search for "Torque terrain stitching" or so, you may find it, but no idea how complete it is. Alternatively you can just cover the seam with water, objects, mesh terrain, or by just mashing the terrains a bit into each other so the terrain meshes intersect a bit. But I would try with a 64km² world and see if that is enough, I once did it and it is extremely huge. Performance is not the big problem with the terrain, it depends more on how much more you add to the terrain.

Why you guys post dublicate posts? Are you bots?

What would be the use of that? Are you trying to build a pseudo 2D game with like a top down view, but 3D graphics? If that is the case, you can just leave everything 3D and just lock the camera.

You have to chose physics module before compiling, default is stock Torque3D physics, you can change that to bullet physics then you can use it right now, the only downside is, there may be a few bugs with bullets, the last time I checked it had problems with vehicle collision for example, but this was years ago, no idea what the current state is. The more people use it, the better we can fix the issues with it, the better it will work.

Yes.

Yes.

The stock Torque physics work quite well for basic applications, you only need PhysX or Bullet, if you want to do more complicated physics simulations. Regarding performance I would not worry so much, your biggest issue will be to get it running and fixing bugs. To me it is an easy decission, I would chose Bullet over PhysX, since Bullet is open source and PhysX is proprietary. To install PhysX you need to register at Nvidia and request the PhysX package etc and if it does not work, you cannot do much, with Bullet you are independend and got the source code, so you can better fix bugs yourself.

Do you really need PhysX? I would recommend investing time into Bullet physics, they are open source, so it is better in the long run.

You can do both ways, using your old datablocks again through making derivative datablocks using the namespace method in script may be the more elegant solution in some cases.

All server code, meaning everything that is in scripts/server/* folder is not used by the client's local installation, but packed and send from the server to the client, so changing those scripts on the client will not do anything. So it should be cheat proof. A more difficult case would be client commands to server where the server has code for, I don't know how this will work, but you could just test it.

What exactly have you done? How are the animations saved? In the model itself or separate files? Take a look here: https://github.com/GarageGames/ContentPacks/blob/master/Actors/Soldier_T3D1.1/soldier_rigged.cs "%this.addSequence("ambient", "sitting", "1840", "1840");" The first number is the start frame and the second number is the end frame, you have to specify them again if you changed and exported it again. Looks like the sitting animation is just one frame, if you added frames, you messed it up probably.

That sounds like a more elegant solution to just check for the distance and if the player is making a sound and just assume the AI player heard it, probably best also check for the SFXProfile value that determines how far the sound can be heard. However I was more interested in practical code examples. For example currently by AI players detect the humans by using a container raycast within their field of view. A noise detection would need to be a 360 degree search. Do I make it into a separate functino or just use one 360 degree search and check if a player is detected is he is visible and hearable?!

I like the cloud layer, since it allows for changing clouds, having 3 layers with different scale, speed and direction will result in clouds that randomly change all the time. The cloud layer works through a normal map plus heightmap in the alpha channel I think, same to terrain normal maps for parallax. Then the cloud layers get overlapped with 2-3 different layers and they will add up and when a certain threshhold is reached the clouds will appear and if it falls below that they will disappear again. The settings can be set in the object inspector, you need to play around with it a bit until you find the right settings. I never made custom textures for it though, since the default one is quite sufficient, since you just need a bit randomly generated cloud patterns to generate the clouds, the texture is not directly displayed ingame. I prefer the basic clouds most of the time, since the texture used there is displayed directly and not used for generating the clouds, so you get more control over how it looks, but it will look more flat and the clouds will not morph over time. So just go with the basic clouds, if you are not satisfied or know how to use the cloud layer. Even many modern games today do not use that advanced cloud system, many still even use skyboxes, since it gives the most photorealistic result, but it will be totally static, the basic clouds at least will move. PS: I used the cloud layer in Uebergame in the level "Pazifik - Watertown at dawn" and "Pazifik - Dee Am islands in rain", most other levels use the basic clouds, so you can check how I did it, if you want.

Yes then it may break certain things like it did in the previous version where parts of the rendering change were introduced as well, which then have to be fixed in the next version. I remember someone changing the terrain blending, to a more "correct" algorithm, but in reality it messed everything up and many complained and in the end the old one was brought back. We probably need better communicatin and a breakdown of new features, so they can be tested before release. I usually do not test, since it would be too much work to upgrade all my project just for testing one feature. The backwards compatibility breaking stuff is probably the physically based rendering, but old projects will still work, they will just not look as good as it would with properly adjusted textures for PBR, so I would not really consider it backwards compatibility breaking, since old projects will still work.

Development branch is the current development and what the next version will be and master is always the latest stable release, pretty simple. Yes version 4 brings some major changes, but that should not be an issue, if backwards compatibility is maintained. Backwards compatibility is my biggest concern, but otherwise I don't worry about the development branch stuff. If the new version is compatible with older projects, people can test it out or a while until the old stuff is finally removed. In short, just use the latest stable release and if you are a developer you should be able to figure out by yourself what the development branch is.

You can place it anywhere you want and for coding you should use a code editor, the world editor is not made for programming, just for changing and creating datablocks. You can also create new files, but make sure they are executed in scriptExec.cs or other.

Generally almost everything can be used to create a level, the only thing you need to find is a converter that converts your weird format into .dae collada so Torque can import it. I tried this before, but generally the efford is not worth it, better is to design your levels in Blender and export straight into the compatible .dae collada format.

One thing you can always try is entering "trace(1)" into console and when you are done "trace(0)" it will output anything that happens into console, so beware for a major console spam and in all that spam search for your collision and see what the engine is doing, maybe it is already written in there or at least it may give you a hint.

Well if you open a model in material editor, there is usually a drop down selector that will list all the materials used in the model, you will have to select one you want to change, then you can change the texture layers etc, but you cannot really add a material, since a material is tied to a model and to a UV map, you can only change the textures in it and the settings or swap it with another material, but not add another.

So you are using normal Torque3D? This should be possible, even though I don't do it that way, since it is problematic. Materials are assigned in the model through a material name and on import a materials.cs file is generated for the materials where you add the different layers. If you add another material through the material editor, it will create a script file where your model is, where it will swap the old material name of the model with a new material you created. This however can get problematic, as the material names could be dublicated since in blender for example every material is by default called "material".

Life is Feudal is a proprietary game and not the same as Torque3D, you would have to ask the developers what they changed or if what you are trying is possible at all.

Can't you update any GUI at any time through scripts? You just pick the name of the GUI, a value in it and set it to something in script, then it will update.