-
Posts
1716 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Articles
Docs
Gallery
Everything posted by Duion
-
Only screenshots can save you now.
-
There is too little information from you to help you, I don't know what you are trying to do.
-
Does the script point to the .dae file or the .dts file? Otherwise as I have told the file may have gotten corrupted, since there is problems with collada import export of the default assets from Torque.
-
Scripted objects need to be defined through script, they do not automatically show up, that is why they are called "scripted". Do a search for the script files that define the object and you may see how it is set up. For example if you rename the model or save it somewhere else, the script no longer picks it up and it no longer shows up in the editor.
-
What exactly is the problem? Importing the default assets may cause issues.
-
You have to consider that from a gameplay standpoint all of those solutions are not good, since when the "cloaked" player is visible in some way, he is visible and if he is not visible good, it encourages people cheating, through graphics settings. Best method may be to just make the player invisible when cloaked and occasionally add particle effects, like smoke, so it helps indicating that there is a cloaked player, but he is not physically visible.
-
You are asking complicated things... I would just replace the whole model texture with a transparent one and add a cubemap with very soft reflection, so it will only be visible from certain angles, maybe that does the trick.
-
I have cloaking, it uses the fizzle fade that is already in there.
-
As I tried to add sound effects for my GUI items I found out that everything that is not from the button category cannot have sound effects. This is because in the engine there is no function for it, even though you can set it in the ingame editor to have a sound. Here is the source function that plays the sound for buttons: https://github.com/GarageGames/Torque3D/blob/c83efa59e0a11fc15c68afaf106807643191ac6f/Engine/source/gui/buttons/guiButtonBaseCtrl.cpp#L255-L256 And here you see it is missing for other elements: https://github.com/GarageGames/Torque3D/blob/c83efa59e0a11fc15c68afaf106807643191ac6f/Engine/source/gui/controls/guiPopUpCtrlEx.cpp#L1653 Before I start to fumble around I wanted to ask, if anyone already has implemented a similar feature or knows a good way to do it. What would better, to add in in source code or through script? I would do it through script, since I'm not good at C++. My thoughts were it would be nice to have additional functionality for more events, since in source I see a lot of callbacks, for mouse over, mouse down, mouse up, mouse leave etc, but by default only mouse over and mouse down for buttons have a sound effect added. Would it be too much work? I would like that feature, but I do not plan on putting too much work into it, since it is a not so important feature for now. So any ideas?
-
The GUI windows in Torque by default support functionality like moving around, resizing, open, close, minimize, tabs etc the only problem with that is, you can not really bring them into foreground with that, the visibility hierarchy stays in the order you opened them, so once a window is behind another window it is always behind it until you completely close and open it again. What also does not work is when you minimize windows to tabs, the tabs overlap each other on the bottom line and do not form separate tabs like you have in your browser or operating system for example. Anyone knows if there is a functionality in Torque that allows to fix that or if it would be possible to build such a feature relatively easy?
-
Well you claim that the paintball arenas should be closed off for short matches, but they actually are closed off, you just did not bother to look at it enough. The paintball map can be played as big map but also on each field individually where it is closed off, so you have 1 map with all arenas open that can be played as deathmatch or team deathmatch, then you can play the 4 regular fields with team deathmatch individually as closed off fields as well as the 2 arenas with deathmatch and team deathmatch also closed off. So the whole setup is basically 10 different maps/gametypes. So you see the problem is in most cases that people do not bother to try it out as most reviews have less than 5-10 minutes playtime, you cannot have played the game in that time or even looked at all the maps and features. The maps are all designed to work good with around 4 players, except the fields map with grass and forests, which is a bit bigger, but it also works with 4 players. The maps are intentionally large and open, since I want realism, not such fake facade maps that look like the real thing but in reality are just closed of "tube" maps as I call them. Most reviews come from the initial launch of the game which had like 10 times less features than what it is now and the biggest part of complaints and feature requests are fixed now. It worked fine the first few months as many new people came in, there was always someone playing, but it was still not enough. A multiplayer game needs a few thousands of active players so you have always someone playing and the launch visibility which was also not very good did not provide that. With some more visibility the player base probably would have stayed up. I also wasted a lot of potential due to some issues that only got visible after lots of people tested it, it took me a few month to fix most problematic things. Thanks for wanting to help with AI, but you have to look into it, since I'm using behavior trees where each behavior is kind of a module, which gets activated through behavior trees. I'm currently building the behaviors for each situation, but deathmatch gameplay already works.
-
Occasionally you find other players, but they often quit fast, since it seems most are just checking the game out and are not interested in playing. You can join on the #duion.com channel on freenode IRC, to find other people to play with. Bots are in there in the latest development, but as I have many levels, gamemods and weapons it will take time to teach them to handle it all, currently they only can play deathmatch with regular weapons. Maybe I will just leave it with that and make a release later and host a deathmatch only server with bots.
-
The problem is that everyone seems to ignore the work of other people and what is already there. People still wait for someone "official" do to something, but there are no more official people caring about Torque3D, we are the official people now. Resources can simply be posted here in the forum or whereever you want now. And regarding the "store" this will likely never work out in the old way, since Torque does not have a big consumer base of "dreamers" who will occasionally buy something, but are not serious about game development, since that is what the stores of other engines mainly live from. Regarding the store I already have something like that for around 2 years now: http://duion.com/art/main I share my art there, all licensed under the extremely liberal CC0 license. It can be used as a multi user site as well, but I had relatively few contributions by others yet. Maybe people ignore it, since they don't want to be associated with me since of their personal problems with me or whatever irrational behavior they have. I'm pretty much the only producer of open source art that is game ready for Torque3D at the moment. So you either do it yourself and/or use what is already there or wait for something that will never happen, as most people are doing for around 3 years now.
-
Übergame is forum #42 (look in address bar)
Duion replied to NekoDemon117's topic in Übergame's Forum
Just a coincidence. -
I just did, it is not that hardm you just have to consider actor radius AND cell size. Actor radius is min distance to walls and cell size is how small the navmesh can be.
-
In options menu there is an auto detect button it executes OptionsDlg._autoDetectQuality(); when pushed, thats all you need probably.
-
I found the solution, it is a combination of many settings in the navMesh. You have the actor radius, which defines how big the actor is, it is 0.5 by default since the actor is roughly 0.75 meter thick, 0.5 radius adds a bit buffer so the actor does not get stuck that often, 0.5 + 0.5 = 1. In my case I used 0.4 actor radius, it is still ok, but also still not enough to make it go through my 1 meter doorway. 0.4 + 0.4 = 0.8 so it should fit through, but it did not. Then I found that it worked for some of my doorways that have been increased in size a little bit so the door was slightly larger than 1 meter, like 1,14 meter in my case and it worked. So finally I found out that you need to decrease cell size in the navMesh as well, since cell size is 0.2 by default. In my case this would then be actor radius 0.4 + 0.4 + cellSize 0.2 = 1m so no space left in my 1m doorway for the navMesh to go through, after setting cell size to 0.1 it went through.
-
There is an auto detect graphics button in the options already. You need to find the command and execute it on the game's launch. Then you would need to make it remember that the auto detect has been executed, otherwise it will do it on every launch, breaking the users configs every time. I would do that with storing a $pref value into the config file after the first launch and auto detect has taken place.
-
I would not argue too much about whether engine x or y is better, but rather look if there is finished projects made with it, since there is a big difference in producing demos/showcases projects and actual final products. For example the showoff of tesseract impressed me a lot some time ago Pure graphics rendering is nicer than in T3D and it also has Global Illumination, performance is also great, so I tested it out, the engine was pretty simple in its structure, but in the long run it had so many features missing that T3D had already that I gave up pretty quickly.
