Duion

What kind of help do you want? From looking at what you got so far, you still have a long way to go. Also I think your current concept is not going to work out, since there are hunting simulators far more advanced already you hardly can compete against, you need some features that those games cannot deliver. I'm not really available for help, since I'm very busy, but I can give you some quick advise on your visuals and how to improve them drastically with relatively little efford.

I now know how it works, the ( often very short ) time after release it almost all that matters for your games ranking. The best thing you can do marketing wise that does not cost you much is to give free copies to some selected testers and curators.

I don't think people adding to wishlist will have any effect, what matters is conversion rates of how many that see it also buy it.

You can work with them and make some templates, that may help other people, since I for example had problems finding good values, especially the steering always sucks.

What you mean with creating vehicles? Modeling or programming? As for modeling there is no easier way, you just have to do it and for programming, a vehicle in Torque is just a datablock with a list of values like weight, acceleration, steering, drag etc that you set and combined with the model plus correct setup this will be your vehicle. I mean you can create one just now, if you cannot model it, use an existing model or just a cube and play with the numbers.

How much does the bar cost?

Torque has an autodectect graphics function here: https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/core/scripts/client/defaults.cs#L449 You can see there, that it checks for shader version, if the display driver is intel and the amount of video memory. Maybe you can build something based on that, if not, you have to look for more variables the engine can look up, or build some on your own. To detect the resolution before launch, you have to run that function on launch obviously, which can make problems, thats probably why Torque launches by default in 1024x768 and then lets you increase it manually. For now I would just suggest setting it to the lowest resolution the machines can have you want to run it on and then let the users adjust it later if they want bigger resolution.

You can reach me at Duion,com , I prefer IRC chat which is #duion.com on irc.freenode.net , you can just hang out there for Torque questions, since the Torque IRC channel has vanished. PS: This forum also has a private message function.

I have an issue with my game and there is a possible cheat based on the GuiShapeNameHud. The cheat goes as follows, for spectator mode I have a TargetHud that uses the GuiShapeNameHud class to display names above players, so they can more easily be spotted, the problem is, since it is just a GUI it is client side and can be enabled by a client through the console in regular game, giving him an advantage since other players are better visible with the name tags. Torque3D has shape names enabled by default and if you do not want them you can just hide them, but through console commands etc people can bring hidden GUIs back. Here is where I enable it for spectator HUD mode: https://github.com/Duion/Uebergame/blob/master/scripts/client/commands.cs#L112 So what would be the best way to solve that issue? Would it be enough to remove the TargetHud from the game, or could someone just copy the code back in and it will work, since it is based on the C++ code of the GuiShapeNameHud? Or would it be possible to move the command to server side, so that the server has to verify the HUD mode the client is in?

@Satan What you mean with "the domain" ?

Then the RPG system would be ideal probably, the elder scrolls series originally had a skill system that would go from 0 to 100, which would be the percentage an action would succeed, where of course there were other factors taken into account as well, as well as a little bit random to spice up the gameplay. I think there is a function in Torque3D which checks how much of an object is visible, since I knew I had to bother with it for a postFX to determine how much of the sun is visible, maybe you can use that to determine how much a player is visible and then apply some kind of 0-100% detection rate based on that.

I don't even know what I use, all I know is they work fine. As an indie dev you have to learn how to be pragmatic, if it works good enough, don't bother with the details. You have to consider that if you change it, you may run into other problems, where the bot will not shoot a player even though for a human he is obviously visible, like you said with using worldboxcenter. I would try to go with a simple workaround, like having a delay until the bot fires, like getRandom from 100ms to 2000ms , that way you do not notice when the bot sees you, since there is a random delay, or go the role play game route, where your visibility generates a percentage you get spottet, so if you are 20% visible, there is only a 20% change you get spotted, or some kind of algorithm, well really depends on the type of game.

How did you even manage to get the bots to be that good? I thought the bots aim for the center of the target, which should make them not shoot you if you just peek. Otherwise I would just solve it with some getRandom value, like a roleplaying game, so you have a probability the bot can see you and shoot you, probably no human player will detect that your "algorithm" for that is just a random value.

i explained what i need help with, i mainly need help with the launcher because it does not run... perhaps because his domain is unavailable when he closed his virtual world We are a forum about the game engine called Torque3D, which has no launcher, no database and no domain, you seem to be having issues which some kind of roleplaying game maybe, you did not evne tell us the name of, how we are supposed to help you, if we do no not even know the name of the program you are using?

@Code_Man Don't worry it works just fine, only updating it real time is a bit of a problem, since it is a big file and takes a while to generate, so you can only update small parts of it in realtime, like a cell, which there is even a button for in the editor.

To get support you need to actually tell us what you need support for.

What the bots use for navigation, just generate it and the bots can use it, you can even spawn a test bot in the navmesh editor and order him around to test it.

You are probably using shadows enabled on point lights with cube projection, but that is broken as are almost all methods of casting shadows on regular lights, seems like you have to fix them. I even had to disable shadows in a night level after even the last method of casting shadows broke in the last update.

Ok latest state of my investigations is, that the problem arises from using transparency on the material with lerp alpha blend mode and "transparency Z-write" checked. Decal roads without transparency and only maybe alpha treshhold do not look good, thats why I added smooth transparency as well, seems like this causes a problem, since transparency also lets the texture below shine through.

Meanwhile I found out that if you have a decal road on a terrain that has also a normal map, the decal road will inherit the normals of the terrain, or more they will get added to the normal map from the decal road, this may cause the visual bug. Depending on the strength of the normal maps it also seems to influence the strength of the visual bug.

I noticed that when using DecalRoads that sometimes there appear ugly lines on the shadows and if the shadows are strong, the lines are even there all the time, here is an example: From what I could find out so far is, that the lines only appear with decal roads that have normal maps on them and they appear the stronger, the stronger the shadows are (for the example screenshot I made the shadows much stronger than normal). In most cases it is hardly visible, mostly only if something casts a shadow on the road, but for the level I'm building now for some unknown reason, the lines are too visible even when no shadow is cast on the road, which is pretty annoying. So anyone got an idea what it is or how to fix it?

No idea what you are doing, but I have it working, feel free to spy on my code. Be aware that I use a new loadout and weapon selection system so there might be a whole lot of more code.

Well anything is possible, since you have the source code, it is just a question how much work it will be. For example you could make the turrets always see the player no matter if there are walls etc and then raycast constantly if he is visible and then shoot instantly, thats how my bots work for example.

There should be a checkbox, if the weapon uses real projectiles or raycast, since most weapons probably do not need visible projectiles at all.

I noticed "\t" being used as a separator in my code sometimes, is that a replacement for the tab?