ShrewdTactician

Glad to hear that it worked! And don't worry about feeling dirty, it gets easier each time.

I'm not sure if you quoted the right line. The navmesh(part 1) uses an a* search for the edge to edge pathbuild on the polygons in the navmesh.

I do want to fix that aswell. Sometimes it's them getting stuck that causes them to suicide but also sometimes it's just their logic that causes it. There's essentially going to be "parts" to the bot upgrade. The navmesh is part 1, which deals which navigation/movement/freedom. Part 2 is the "logic" part, where I'm going to teach them how to play renegade. Teach them to target the mct, how to eng rush, or tank rush, how to use stealth, etc. Part 2 might get split into a third section where I move the logic out of hardcoding and into the visual scripting kismet.

I brought the stuff. You didn't tell anyone, right? Extract this into the game dir. There's a new setting in the launcher that tells it to use the x64 exe instead; or you can run the udklift.exe in the binaries folder which will use the x64 exe if available, or the 32bit if not; or you can run the udk.exe in the binaries\win64 folder directly. You can check if your running the x64 version by checking task manager or by looking at the window title. NOTICE: I've marked this as debug as 2 minor features don't work yet with the 64bit version. The ingame version check doesn't work yet (just use the launcher for checking the version), and the level loading screen isnt dynamic to the level, it just shows the default loading video. x64_Debug_Patch.zip

Meet me in the ally behind the school in an hour and we'll get this exe deal done. Bring your friends, but if you tell /the man/, i'll make sure you'll regret it.

I am planning to make a tutorial video for map makers, as well as converting all published maps that could he used for examples. I wanted to make it as easy as possible for mapmakers,and should be easier then the current waypoint system. For a quick run down. You put down a navigtion point called a pylon, and use either a radius or volume(s). Cover the areas in your map that are accessable and then press build paths. Done. The Udk "explores" the pylon area from the pylon, creating a "map" of all the areas that can be reached, this includes drops off edges, ledges, jumps,mantling, etc(which are now aware to the bots). The bots now use this map to work out all the path finding. Since it deals with areas rather then points, the movement is more free and "natural". It also makes pathfinding cheaper, as the map is easier to check against then trying to find the nearest waypoint node of the source and destination of a trip, which has to be line checked multiple times. The other advantage for map makes is, that except for major region changes, you won't have to keep muking with pathong when stuff changes. The amount of waypoints I've found underground, in building walls, etc is nuts. That hassle for map makers should go away.

Should be. Instead of following waypoints, the harvester finds it's own way using the navmesh, which is a precomputed map of movable space. The navmesh is devided into sections, with the edges of these sections marked with the size of actors that can fit through it, including height. So harvesters shouldn't run into things, doesn't rely on map makers having to place waypoints down everywhere, the bots have alot more freedom in how they move, and where they can move.

I've been working heavily on the bot navigation (and bots in general), mainly looking to ditch the old waypoint system for the most part and replace it with the more modern navmesh system. Strangely I have been using islands as my test map. Navmesh have numerous benefits over the waypoint system, and should allow us to do more with bots overall. This is all "experimental" and could turn out that if I cant get it to 100%, then it will all have to be dropped, but of the work I have done so far, its looking pretty promising. I'm actually quite happy with some of the improvements to the bots already.

Ah, ok. If you do want to try again let me know.

I'm quite happy to use the shrewd gaming server as a test bed for this. I have successfully deployed new rx_game files using the ingame downloader before.

I'm guessing that we tried to deploy a new version of the rx_game to clients using the ingame downloader? If its dropping to main menu, its probably just missing a file in the repo that its requesting. Check the webserver logs for what its looking for.

I missed all of this, what happened? why are we replacing rx_game?

Thanks m8

Should i keep updating this?

Yeah it looks like it made it in. Im extremely happy about that. I am interested if people notice anything. So if anyone hears people talking good or bad about it, just post it here.

aww

as title

Looking around, I think @Agent got the jump on us. https://github.com/JAJames/Rx_CustomContentPackager Else, the other way to do it, /possibly/ is to use the built-in udk extractor that comes with the game anyway. https://docs.unrealengine.com/udk/Three/BatchExportCommandlet.html If the video file is always named the same thing inside the map package, then the logic could go. 1. launcher looks for video file for a map. 2. If not found, run the batchexport command on the upk of the map to get it. Problem sorted (if works).

no.

Happy birthday!

I wouldn't be to hasty yet, while the ingame downloader is awesome, it still has some limitations. 1. The multiple map problem, which I will try and get fixed. 2. The config ini files wont transfer across. This can be turned into a non-issue by removing the need for them. As I understand it, the only place that needs it is skirmish. Since that info in the config is static, and is already essentially in the map info already put in by the map maker, the class can be changed to read that info straight out of the map, instead of from the ini files. 3. The pre videos, this is going to be harder to work out. If you can put a video straight into a map file, and then somehow read them out again from a program like the launcher, then that would be the answer. Trying to figure out how to actually do that,,, is going to be interesting. Otherwise the seeker could always be adapted to support the preview videos as an individual file. 4. The seeker can be used server side as a way to update official/recognised maps to servers without having to release a new renx build. As a server owner, I would love if the seeker/launcher would basically automatically maintain the official/common maps. And I'm sure map makers would love a way to publish their maps without having to wait for an official renx build.

That's good news!

What i'll do, since I do actually need to raise the limit, is I'll write a new mutator, since the original mutators author doesn't what that one floating around. For now I wont post the mutator, for the reasons you just mentioned. I might post it after the game goes to release. If anyone else actually has a need for the player max to be higher, they could probably work it out from the 2 values I put in the OP, and from the udk/ut3 mutator guides that float around the net. I do actually agree that 40 players is probably the optimal max, but I'm not a fan of hard limits because of situations like this. For instance if players end up playing on 64 players servers, a lot, then the game should be balanced for that anyway. Its also a bit interesting since the gameplay can vary greatly when there's only 2-4 players on a server and 40; so varying player counts should already be part of the thought process. There's also the niche situations like I'm in as well to consider. Where its either higher or it doesn't get played at all, and given those 2 options, I think raising the player limit should be the choice to make. I wont be putting the mutator on my public Australian server for now, since it doesn't need it. But if for some miracle it constantly hits the 40 player limit (and I hope it does someday),and the choice comes down to having to pay another $140 a month for a second server, or slightly effecting the gameplay, ill raise the player limit on the public server as well. I would also like to say that organised matches (of any game) are always going to play differently then what normal players experience, so don't use them as the sole input into game balancing. Devs should also be easily able to filter the info they get from the dev bots that they use for gameplay balancing stats, by looking at the player count or other mutators on the server. Essentially "pure" mode only servers. And if most servers arnt pure, then they should be taking that into consideration anyway.

I do actually have a need for the player limit to be higher. So if the issue is solely that the specific mutator didn't want to be posted by the author, there should be no problem if I write a new one. If the problem is, more then 40 players is not what the devs intended, then why have any mutators at all. The whole point of a mutator is to change the game play. Its a bit silly, to have a download section on the site for mutators, have example mutators, and then say, but we don't like people changing the game. If the problem is, its not the "authentic" renegade x experience, then the mututor reason applies, but also the devs can host their own official server with the "authentic experience". If the problem is, its not what the players want, then it really shouldn't be an issues anyway as players will join 40 player servers (and new players will follow the crowd)

O wow, that's exactly what I was looking for. Also thanks YagiHige you suggested it aswel.