Crnyo

As an added benefit players would have a sense that they are working towards long-term goal during their play. They would accumulate credits so that after a while they can buy really powerful vehicles. But they would have to balance between playing offensively and defensively. If you are too defensive you won't get credit ticks from dealing damage and you might lose control of the field. If you are too offensive you can lose your expensive units which will delay your ability to buy weapon upgrades.

Sometimes marathon matches can really suck when more than half of your team consists of lone wolf players. I'm sure most of us had an experience when someone would try to get tank rush going only to have 6 out of 20 people respond. Other times you can even get decent numbers but if defenders decide to turtle in base they can easily outrepair your damage. I'm interested to hear what do you guys think about giving player's ability to pay extra credits to buff their vehicle's damage? When spawning a vehicle you should be able to select the level of weapon upgrades it will have. I propose 3 levels according to following formula cost = damage ^ 4 1st level: DPS increased by 33.3% - vehicle cost increased times 3,13 (1,33 * 1,33 * 1,33 * 1,33) 2nd level: DPS increased by 66.6% - vehicle cost increased times 7,59 (1,66 * 1,66 * 1,66 * 1,66) 3rd level: DPS increased by 100% (doubled) - vehicle cost increased times 16 (2 * 2 * 2 * 2) Now even if your team only has 6 teamplayers out of 20 people they can at least buy upgraded vehicles which would significantly increase the chance of making the rush successful. These upgrades would be really expensive - for example if you want to upgrade your medium tank so it does twice the DPS you would have to pay 16000 credits for it. Therefore these vehicles couldn't be spammed. You would have to spend at least half an hour saving credits for that one special rush. What are your thoughts on this?

For some reason Beta 5 SDK is failing to download and I only have Beta 4. I've read what BroTranquility is trying to make. I think reason why he encountered difficulties was because he tried to change building health through internals class. Month ago I made a small mutator which removes repair guns and buffs vehicle and building HP with certain multiplier. I encountered similar issue and what worked for me was changing building HP through Rx_BuildingObjective class, not building internals class. Although mutator I made can successfully modify building max health it does so before game fully loads. I'm not sure if building max health can be changed during the game after buildings have already been spawned. If that turns out to be an issue then we can try to mod repair gun instead so it stops repairing buildings beyond target percentage. If I manage to download beta 5 SDK I'll attempt to code a mutator for this. edit: Mutator BroTranquility is trying to make is much more sophisticated than what I'm suggesting here. He is trying to add actual armor values which would be graphically represented. I am on the other hand just suggesting to tweak building max health. Its much more crude approach.

Decreasing building max health whenever it gets damaged beyond certain level should take only few lines of code. For example if 50% of building health is armor and other 50% is unrepairable HP then pseudocode would look like this: if (buildingHealth < 0.5*maxHealth) maxHealth = (0.5 + buildingHealth/maxHealth) * maxHealth; If building health drops to 20% then new maximum health would become 70%. I could probably code it today but issue is that there is only 1 or 2 active servers and I imagine admins aren't willing to implement new mutators cuz changing stuff is risky and they might lose players.

I'll quickly throw my 2 cents although I'm not really qualified to answer. I think it is up to you to decide whether you want to start making simpler games from scratch by yourself or mod RenX. Personally I've decided to learn UnrealEngine just so I could mod RenX. However if you are purely interested in learning UnrealEngine to make your own games then simply getting a book on how to do so might be a faster route. Make sure to browse through Unreal Developer Network as it has all the technical information you need. If you want to start learning how to make games by modding RenX then I can recommend: a) Get Unreal-X Editor for writing code b) Download UnCodeX UnCodeX is useful because it allows you search entire sourcecode for specific phrases. When modding RenX you will often find that one functionality is fragmented across several files so traditional text editors just won't do.

Excellent work. I especially like your decision to make new vehicles only accessible through crate drops. Kudos to that, I think it will make map control more rewarding.

It seems that turrets have their own Controller class. Instead of referring to placeable turret classes perhaps you should try referring to Rx_Defence_Controller class. Those shouldn't be duplicated in MP match. You should be able to find the location of Controller's turret using this: Rx_Defence_Controller(Actor).Pawn.Location

Hm the number of initialized turrets in multiplayer match is different from singleplayer match? That is weird. It would be interesting to find out why this is the case. How can I replicate your finding? Is there a console command which lists all objects of specific class? In any case, I think your issue could be solved this way: (Replace Rx_Defence with the exact name of duplicated turret class) Struct All_Actors_Refering_ToA_Single_Turret { var array Actors; } var array Turrets; ... local int i; local All_Actors_Refering_ToA_Single_Turret NewTurret; local bool Turret_Already_Exists; foreach Rx_Game(WorldInfo.Game).AllActors(class'Actor', Other) { if (Rx_Defence(Other) != none) { Turret_Already_Exists = false; for(i = 0; i < Turrets.Length;i++) { if (Turrets[i].Actors[0] == Other.Location) { Turrets[i].Actors.AddItem(Rx_Defence(Other)); Turret_Already_Exists = true; } } if (Turret_Already_Exists == false) { NewTurret.Actors.AddItem(Rx_Defence(Other)); Turrets.AddItem(NewTurret); NewTurret.Actors.Length = 0; } } } So basically every element of array Turrets will hold all actors refering to a single turret. Say Field has 2 turrets. If you want to order second turret to fire then iterate through Turrets[1].Actors array and give order to every individual Actor to fire. This is not elegant solution but I hope it will get the job done until someone manages to figure out this singleplayer-multiplayer weirdness.

Are you trying to make harvesters only spawn once? If so try to access VehicleManager in Rx_Game and set bNodRefDestroyed and bGDIRefDestroyed to true. If you are using a mutator you could try putting this in your postbeginplay() RxGame(WorldInfo.Game).VehicleManager.bNodRefDestroyed = true; RxGame(WorldInfo.Game).VehicleManager.bGDIRefDestroyed = true; Whenever harvester gets destroyed game will check whether *RefDestroyed is set to true. If it is then harvester spawning will be aborted.

I can't understand why this is the case. Either marathon is objectively a better gamemode or most players have left for other games which do TDM better than RenX marathon can - in which case those who remain form very specific and unrepresentative sample of players.

This is a good point. If commander controls more than 5 pawns and someone else applies for commanding then pawns could be evenly split between you. But if no one applies for commanding then it would be possible for one commander to controller all of the pawns. However, I'd put this under fine-tuning category. For starters we should aim to make simplest prototype version of commander mode so playerbase could actually getting a feeling for it and then decide whether they like the idea or not. This is the problematic part. If commanders were only to give waypoints instead of micromanaging pawns then issue with bad bot AI would still remain. Coders would still have to spend time on improving AI and fighting bots would still feel like PVE. On the other hand if commander micromanages pawns from overhead view then fighting those same bots would now be true PVP. So players could use vote menu to initiate bot rushes. You could choose between APC rush, tank rush, aircraft rush, rocket soldier or engineer rush through the tunnels etc... Basically every category of rush would have scripted strategy for bots to follow. If vote to rush passess then global AI controller would temporarily be replaced by specialized AI sub-controller specifically scripted for executing specified type of rush strategy. This would require some work not only because those strategies need to be coded but because bot pathfinding isn't reliable. They tend to crash into each other and get stuck. If you ever wondered why bots suicide it is because of bad pathfinding. When they can't get unstuck they just kill themselves and respawn.

EDIT: I don't think overhead maps are really all that necessary. None of the maps are all that big, and having to open up a map takes you out of the game. Just being an overhead view entirely REALLY takes you out of the game which actually puts your team down a player, and removes any sense of danger for whoever is commanding. I think it'd work if teams did have a commander, or optionally several, that could use an item........saaaaaay binoculars, that let them set targets/objectives/Waypoints without them ever actually leaving the fight and being vulnerable. They'd have to stay in the back, and they'd probably be best as a sniper/Tech, but since their main job would be coordinating this wouldn't be much of a problem at all. Well I personally think that commanding a squad of bots against FPS players would be a fun RTS concept. Overhead camera is necessary so you can issue orders and position bots more easily. Technically they wouldn't be bots any more because player commander is controlling them but you get the idea...

Hm I guess people aren't thrilled with the idea after all. I think people play multiplayer games because they enjoy the social aspect, not just opportunity to chat with other players but rather the knowledge that you are playing with other humans. I'm confident that even if we made AI to be much more smarter people would still prefer playing against other humans. For instance, imagine someone told you during your RenX game that all other players were actually bots. I'm sure the game would suddenly become much less fun despite the gameplay objectively remaining the same. Commander mode is essentially a way to make fighting against bots feel like fighting against other humans. NPC Pawns would no longer be controlled by AI. When fighting those NPC Pawns you would know you are actually fighting other human player and that is what would make it more satisfying. Fighting against bots is currently PVE, if bots are commanded by human player then suddenly it becomes PVP. Thats the whole idea behind commander mode. When you go on a killstreak you would know enemy commander is watching his pawns getting slaughtered and is raging. When you get baseraped by NPC pawns you would know human commander is orchestrating this.

I'm not yet very familiar with UDK and RenX source code but it seems to me that this wouldn't require very much work. Largest bit that needs to be coded is camera class for commanders and a unit bar for buying vehicles and infantry. Everything else is already in game. Bot decision making AI needs to be removed and replaced with listener which would transmit commander's order where to go or what vehicle/character to buy. That shouldn't be longer than few lines of code.

RTS interface or commander mode. One player should control bots using RTS-style marquee selection while other team should consist only out of human players without commander. If bots are directly controlled by player commander then that solves the issues caused by bad AI and makes for a very interesting game mode. Alternatively, we could have 2 commanders controlling bots and duking it out while PC soldiers do their own thing. From RTS perspective they would be something like hero classes commanders can't control- This mod would put bots to a very good use which is exactly what this game with low playerbase needs. As far as I know there is nothing like this on game market. Natural Selection 2 has commander system as well but commander there doesn't directly controls units, he just builds stuff and buys upgrades. What do you guys think?

I share your sentiment to some degree. That is why I made a small mutator which disables repair guns and buffs building HP by factor of 2-10 depending on number of players on server. (It takes 2-10 nukes to destroy a building as well) Tanks are fine. Problem is that most players are bad at teamplay (which is strange considering our small playerbase). Spawning 10 tanks and rushing a base as a group works well most of the time, it just isn't done very often. That is why IMHO whenever you manage to pass through enemy defences and fire a few shots at their buildings that should count as a small achievement which brings your team closer to victory. Repair guns shouldn't invalidate efforts of solo players. RenX can be very frustrating because lot of the time teammates are playing it like it is CoD TDM. It is impossible for objective-oriented players to do anything on their own because they are often minority on larger server. If players enjoy 3 hour marathons then that fine by me. I guess what I don't understand however is why don't they play Blacklight Retribution or some other game which does TDM aspect better?

Hey man, I'm glad you like it. Team score could work. Early base rush should get you faster access to higher tech even if you don't manage to destroy any buildings ( provided you inflict more damage than you receive). Hm interesting idea. You know it would be possible to rig crate pickups so they drop "tech blueprints". Then you could research that tech for yourself at the base (you'd have to pay large sum of credits). When researched specific vehicles would get some kind of buffs be it higher damage resistance, more damage per shot or higher speed. There could even be ultra buffs like invisibility or automated defense scrambler (guard towers won't shoot at you) or stun dart for SBHs(this probably won't happen because it would require some modelling&animation but i can try), but of course those wouldn't be permanent, you could only apply them once. Just imagine a invisible Mammoth or flame tank, or APC which doesn't get targeted by base defenses. I think I have my next mod project.

As much as I'd like to think that tech level unlocks based on harvester unloads is a cool system, I have to agree with this. It seems that tech level unlocks should be time based. This won't fix the base turtling issue but at least we will have nice gameplay transitions from basic to more advanced units. Reasoning behind basing tech level on harvester unloads was that part of the team should deal with base warfare while others should deal with harvester warfare. If you control Tiberium field you will have tech advantage but if you assign too many players to that mission then your base will become vulnerable to enemy assault. Unfortunately most maps only have 2 rush lanes, one for vehicles and other for infantry. This means you can siege the enemy base and block their access to Tiberium at the same time. What this mod would require are specialized maps which would contain 3 tiberium fields. Every refinery would have dynamic number of harvesters depending on number of players on server. But custom maps will require game client that is able to download maps directly from server instead of having to go to forums and manually unzip those files in right folders. So I guess this won't happen any time soon.

I think I know why your code only deletes one blocking mesh. Spawn(x) is a function which tell engine to spawn object of class x and returns memory address of that object. When you say Y = Spawn(x); then you are giving two instructions: 1)Spawn object of class X 2)Give that address of object to Y Take a look at this: for (i=0; i < 3; i++) { SpawnedBlockingMesh = Spawn(BlockingMesh); } i=0: Engine spawns blockingmesh1 on the map and makes your SpawnedBlockingMesh point to blockingmesh1 i=1: Engine spawns blockingmesh2 and your SpawnedBlockingMesh now points to blockingmesh2 i=2: Engine spawns blockingmesh3 and SpawnedBlockingMesh now points to blockingmesh3 When you use SpawnedBlockingMesh.Delete(); Only object deleted will be the one SpawnedBlockingMesh is pointing at and that is mesh 3. You have lost your references to mesh 1 and mesh 2 because you keep overwriting SpawnedBlockingMesh with addresses of new objects. That is why you need to use dynamic arrays. Instead of SpawnedBlockingMesh = Spawn(BlockingMesh) use var Array SpawnedBlockingMeshArray; ... for (i=0; i<3; i++) { SpawnedBlockingMeshArray.AddItem(Spawn(BlockingMesh)); }

Here is version using DynamicArrays, it is probably faster. Search for "NEW CODE" to easily locate what I've added. //============================================================================= // FoliageCollisionVolume: a vehicle collision solution // used to collide certain classes of actors // primary use is to provide collision for non-zero extent traces around static meshes // Created by Pinheiro, https://forums.epicgames.com/threads/913559-How-to-enable-collision-on-foliage // Heavily modified by Ruud033 //============================================================================= class FoliageCollisionVolume extends Volume placeable; var BlockingMesh CreatedBlockingMesh; //need dynamic array var Array SpawnedBlockingMeshes; // NEW CODE static final function vector MatrixGetScale(Matrix TM) { local Vector s; s.x = sqrt(TM.XPlane.X**2 + TM.XPlane.Y**2 + TM.XPlane.Z**2); s.y = sqrt(TM.YPlane.X**2 + TM.YPlane.Y**2 + TM.YPlane.Z**2); s.z = sqrt(TM.ZPlane.X**2 + TM.ZPlane.Y**2 + TM.ZPlane.Z**2); return s; } event Touch( Actor Other, PrimitiveComponent OtherComp, vector HitLocation, vector HitNormal ) { local InstancedFoliageActor ac; local InstancedStaticMeshComponent comp; local vector loc, scale; local Rotator rot; local int i, j; super.Touch(Other, OtherComp, HitLocation, HitNormal); //look for the InstancedFoliageActor foreach AllActors(class'InstancedFoliageActor',ac) { //iterate through the various foliage components for(i=0; i { comp = ac.InstancedStaticMeshComponents[i]; if (comp.StaticMesh.BodySetup != none) { //iterate through the various meshes in this component, if it has a collision model for (j=0; j { //decompose the instance's transform matrix loc = MatrixGetOrigin(comp.PerInstanceSMData[j].Transform); if (ContainsPoint(loc)) //check if this instance is within the volume { rot = MatrixGetRotator(comp.PerInstanceSMData[j].Transform); scale = MatrixGetScale(comp.PerInstanceSMData[j].Transform); CreatedBlockingMesh = Spawn(class'BlockingMesh',ac,,loc,rot); CreatedBlockingMesh.StaticMeshComponent.SetStaticMesh(comp.StaticMesh); CreatedBlockingMesh.SetDrawScale3D(scale); SpawnedBlockingMeshes.AddItem(CreatedBlockingMesh); // NEW CODE } } } } } } // NEW CODE STARTS event Untouch( Actor Other ) { Super.Untouch(Other); ForEach SpawnedBlockingMeshes(BlockingMesh mesh) mesh.Destroy(); SpawnedBlockingMeshes.Length = 0; } // NEW CODE ENDS defaultproperties { bColored=true BrushColor=(R=0,G=255,B=255,A=255) bCollideActors=true bProjTarget=true SupportedEvents.Empty SupportedEvents(0)=class'SeqEvent_Touch' }

Not sure why code doesn't remove all spawned actors. Maybe Super.Untouch(Other) does something important behind the scenes? If so you should add it within event Untouch You could also try manually destroying all other meshes within "distance" radius of that one mesh which successfully gets destroyed upon Untouch. var int distance; event Untouch ( Actor Other) { ForEach WorldInfo.AllActors(Actor mesh) { if (mesh.IsA('BlockingMesh') && (vSizeSq(mesh.pos - CreatedBlockingMesh.pos) <= (distance**2))) { mesh.Destroy(); } } }

I don't know if you played the game Interstellar Marines over the free weekend, if not you can check it out on YT but... In that game night time is literally so dark that you can't see enemy unless he is 5 meters in front of you. Not knowing whether the enemy is also sitting in the dark near you and having to rely on almost exclusively on sound is very adrenaline pumping. If that could be replicated on RenX then sneaking into the base would take whole new dimension. Although I imagine that would require putting restriction on gamma setting.

Does anyone else feel that cheaper units such as buggies and lower tier infantry should see more action than they do now? It seems to me that credit gain is so fast that you can get into tanks pretty much within few minutes from starting the game. This kinda makes those cheaper units utterly redundant. Another issue I see is that controlling Tiberium field isn't as rewarding as it should be. Even if you are able to deny their access to Tiberium, enemy players can still effectively turtle in the base thanks to alternative forms of income such as repairing allies. As a part of my UnrealScript learning process I've made a small modification to the game which introduces tech levels. Tech lvl 0: free infantry Tech lvl 1: Buggy + rocket soldier, officer, mcfarland/chem soldier, hotwire, buggy Tech lvl 2: APC, Artillery/MLRS + 500 credits infantry(SBH, Laser chaingunner, Patch, Gunner, Snipers) Tech lvl 3: Everything else To advance from one tech level to the next you need to secure 5 harvester unloads. If you destroy enemy harvester you can slow up their tech progression. Gameplay would be divided into early / mid / late game. Early game would revolve around infantry and buggies, mid game would revolve around APCs rushes and Arty bombardment(infantry would still be important) and late game would be what we have now - total vehicle domination over infantry. I'd appreciate your thoughts on this.

I've created a mutator which I want loaded only if players pass a vote. I have been thinking of using Survey Vote class for this. Easiest solution would be to just add under Execute() function in Rx_VoteMenuChoice_Survey the following line: if (TopString == "Initialize Mod") InitMyMod; however I do not want to edit game source code. So alternative I have been thinking about is to find the GlobalVote instanced object in my mutator class var Rx_VoteMenuChoice Global_Vote; foreach AllObject (class'Rx_VoteMenuChoice', Global_Vote) Now that I have access to game's GlobalVote variable I can use Tick function to check every frame whether there is vote with String=="Init Mod" running. Will this method be too resource-intensive? Is there a better way to use RenX vote system to load a mutator?

function UpdateCollisionBasedOnDistanceTimer() is missing '}' sign. That is causing the error.