RypeL

You capture it with the repgun like you do with a techbuilding. It has a team num var "TeamID" wich tells you what team currently owns it. Thats really all there is to it and all thats needed i think. There are no special Kismet nodes for it. Cause its a persistent object in the world and you can access variables from those in Kismet by using 'New Action->Object Property->Get Property'. With that you should be able to access "TeamID". Im saying "should" cause i didnt test it but i know we did use 'Get Property' successfully before on Buildings to read their health. So the general node 'New Action->Object Property->Get Property' is the node that is supposed to be used to get the TeamID from the MCT.

(Reminder that i will delete any posts from people who use swearing and insults (like the previous, now deleted post in this thread). Then i will PM you one warning and if you do it again your account will be deleted and you will get a global IP ban on all RenX servers so you can have fun using VPN. I know devs could do more and im currently pretty much inactive aswell but this is no payed job at all so nobody has the right to demand anything from us or to insult us.)

Should be fixed now.

Nice work ☺

Never heard of this. Definatly not intentional. Maybe the map spawns them and then the server replicate spawns them once again.

Afaik none of those will get fixed with the next patch. Not by me atleast and i dont think by anyone else. Why ? Cause i think those are minor issues that new players will hardly notice. Fixing any of those to me is a waste of time. We fixed other issues before and it never made a difference in player numbers. From my point of view its proven by now that the game mode is just terribly outdated and boring and i am certainly not playing the game cause of Floating C4 or some shit. I am not playing the game cause the game mode too often is too boring with lack of progression compared to other games. The game mode in general needs to get better progression mechanics to become more fun for a bigger audience. The next patch will get the building armor idea (viewtopic.php?f=135&t=75217&hilit=building+armor) cause thats arguably the most promising and not too complicated progression idea we had so far (thx again to BroTranq again for taking some effort to make good suggestions instead of just blaming the devs and minor bugs). If that or other ideas for the game mode doesent catch on i am most likely done with this for good (well im already 90% gone at this time but if i would see some new hope for the game mode i might have a reason to invest more time again, else i just have more reason to leave this behind). Fixing more bugs is NOT enough. I wish more people would think like that and would try hard to come up with ideas to improve the game mode.

Sometimes executing things in PostBeginPlay doesent work cause it can depend on things that are not fully initialized yet. Generally the game takes a short moment till every initialization code etc is executed. So you can try to add: SetTimer(0.5,false,'init'); <- into PostBeginPlay function init() { ... } This will result in your initialization code happening 0.5 secs after game start. Id try that first before trying to find other reasons why it doesent work in SP.

The RepairCloseVehicles() function in Rx_Bot contains the logic about vehicle repairs. In it if(bDefending && VSize(V.location - Rx_BuildingObjective(Squad.SquadObjective).GetShootTarget().location) > 2500 ) { continue; } defines that when its a defending bot they should only heal vehicles that are within a 2500 radius to theit BuildingObjective (wich is the building they are currently assigned to defend). Basically bots are separated in attackers and defenders. If they are attackers if they heal a vehicle depends on if you are visible to them. They will repair the closest visible vehicle that needs healing. If a vehicle needs healing is defined in Rx_Vehicle.NeedsHealing()

Ah, that means we can't do a mod that replaces MRLS to Hover MRLS then, too bad Cause initializing code that is done to a vehicle directly after its spawned is not executed when it is replaced with a mutator. This can be circumvented (by doing the initializing code in the mutator) but i have no energy right now to explain/detail it. Ill try to look into it later.

pls try a "return false;" directly after the ReplaceWith line. Return false at that place means to not keep the original stank (see checkreplacement description in the mutator class). We will get there, dont worry

Can you post your log pls ? UDKGame\Logs

It alternates between 0 and 1. 0 is the left rocket pod, 1 is the right rocket pod (or the other way arround, not sure). I think its giving you this error cause your RenX codebase doesent yet contain the variable "i" in the stank base class (i think this change was done after the last source code was distributed). This should work: class Rx_Vehicle_StealthTank_Weapon_MOD extends Rx_Vehicle_StealthTank_Weapon; var int j; simulated function rotator AddSpread(rotator BaseAim) { local vector X, Y, Z; local float CurrentSpread, RandY, RandZ; CurrentSpread = Spread[CurrentFireMode]; if (CurrentSpread == 0) { return BaseAim; } else { GetAxes(BaseAim, X, Y, Z); if(j++ == 0) RandY = -0.4; <---- change this. changes arc to the left i think else RandY = 0.4; <---- change this. changes arc to the right i think if(j > 1) j = 0; RandZ = 0.1; <---- change this. changes initial up/down rotation of the rockets return rotator(X + RandY * CurrentSpread * Y + RandZ * CurrentSpread * Z); } } DefaultProperties { ReloadTime(0) = 1.3 ReloadTime(1) = 1.3 VehicleClass=Class'MyStankMod.Rx_Vehicle_StealthTank_MOD' }

ReplaceWith(Other, "Rx_Vehicle_StealthTank_MOD"); -> You need to give the full path to the vehicle which is the packagename + "." + Classname. So for example it should look like: ReplaceWith(Other, "MyStankMod.Rx_Vehicle_StealthTank_MOD"); VehicleClass=Class'RenX_Game.Rx_Vehicle_StealthTank' -> This should also point to Class'MyStankMod.Rx_Vehicle_StealthTank_MOD' Spread(0)=0.00 Spread(1)=0.00 -> In the stanks case id say you should modify the AddSpread() function directly. Especially the RandX and RandY values. Like this: class Rx_Vehicle_StealthTank_Weapon_MOD extends Rx_Vehicle_StealthTank_Weapon; simulated function rotator AddSpread(rotator BaseAim) { local vector X, Y, Z; local float CurrentSpread, RandY, RandZ; CurrentSpread = Spread[CurrentFireMode]; if (CurrentSpread == 0) { return BaseAim; } else { GetAxes(BaseAim, X, Y, Z); if(i++ == 0) RandY = -0.4; <---- change this. changes arc to the left i think else RandY = 0.4; <---- change this. changes arc to the right i think if(i > 1) i = 0; RandZ = 0.1; <---- change this. changes initial up/down rotation of the rockets return rotator(X + RandY * CurrentSpread * Y + RandZ * CurrentSpread * Z); } } DefaultProperties { ReloadTime(0) = 1.3 ReloadTime(1) = 1.3 VehicleClass=Class'MyStankMod.Rx_Vehicle_StealthTank_MOD' } Since your usage of ReplaceWith() was wrong your changes didnt had any effect. To make sure your functions get executed i can give you the tip of putting a loginternal("saying something"); in your code lines. It will print output into the log. Then watch the log if the output comes up (or use a debugger like https://code.google.com/p/unreal-debugger/). In general you should watch the log closely for any errors (your replacewith should have caused an error in the log aswell). You can make a live view of the log visible by using the "-log" commandline param. For example you can start your game like this: udk CNC-Canyon?game=RenX_Game.Rx_Game -nomovie -nosteam -log -forcelogflush -windowed

Changing the values in the AddSpread() method will work if done correctly. But im not sure what you could be doing wrong atm. Are you sure your replaced stank is active. Did the replacement really work or maybe is there still something wrong with your replacement code ? You might have to post all your code for us to see.

Again: As beeing said the sniper changes you are referring to where done by TMX. And if you have a problem with something TMX does you should talk to the TMX guys about it.

Because the game doesent have 100s of people you cant just fill a testing server. Thats why, sadly, there probably isent much of an alternative then to test it on the main server. We tried official servers before but they were never popular. TMX and EKT got popular exactly cause of their own modifications and community wich keeps those servers alive.

Canucck, the "official" Pre Patch Balance Mutator that was made based on CD feedback didnt contain any changes to the snipers as this wasent fully discussed till the end their yet. As said above the sniper changes were added by individuals on their own. We embrace and support people doing their own mutators with example code etc. The community has to take over and balance has to come natural. If TMX decides to change the balance on their server it is their call. And im sure right now its mainly for trying out different things and their idea is to help out, not to annoy. So pls be a bit more positive about it. The CD´s have a private forum.

I dont think you can put in your own stank upk with a mutator. A mutator is for changing code, not for modifying content. "I have made a STank mutator, that locks "fire muzzle" to fire both missiles from front if using primary fire and both missiles from top if firing secondary fire or any combo of the two in any order." Pls take a look at the AddSpread() method in Rx_Vehicle_StealthTank_Weapon. I think modifying this function is all you need to do to get this working. The AddSpread() method defines the rotation the missiles come out of the barrels (or rather it defines how much their rotation should deviate from the barrels rotations). It is responsible for the arch the missiles are taking and it can all be changed easily there. The default implementation of the vehicles AddSpread() adds some random spread to the shots but for the stank the function is overridden to remove the randomness and to create the current steady, put possibly a bit too wide, arch when firing. If you change RandX and RandY you can get different arches or could remove it completly. There also is a CurrentFireMode var already beeing used in that function. It is 0 if primary fire is currently active and 1 for secondary. So you can also change the missiles rotation there easily based on the current firemode. Then i would also advice you to make your own stank class with this modified weapon class and to use the checkreplacement() function like described above to exchange the stank with your version of it.

Good initiative indeed. Yes AI is a lot of work and as stated before i have no motivation or time to work on the AI anymore. ... dont get me wrong though: If you have the time and interest to work on it it really can be fun. It is an interesting area to work in. And it is rewarding to see them do what you planned them to do. The RenX Ai is an extension of the UT AI. Thus to "I'd also suggest looking at the UT3 way of doing paths and setting up area objectives." i can reply that its already pretty much done like that as the RenX AI is really just a modified and extended UT3 AI. Your code modifications so far look good and it looks like youre on the/a right path. I cant spot out the problem immediatly but pls dont expect me/us to go through your AI code and find the problem for you. It can get complicated quickly and thus become hard for us to follow. Instead i could help in getting you an idea how to approach things but you already found a promising approach on beacon disarming. You made a plan, you made the code, but its not working yet. This is what will happen a lot of times when you work on AI. There are a lot of complications in it and so things can go wrong easily. All the AI decission logic needs to fit perfectly together or they will just do something else then what you told them to do. Now the biggest advice i can give you is: Use a debugger. With it you can step through the executed code to find out what the AI is really doing instead of what you planned it to do and why it is making the decission it makes instead of the decissions you planned it to do. And while you watch the code beeing executing in the debugger, trying to find your problem, you will learn a lot about the AI ways of doing things in general. So you have a plan -> good. You have the code implemented -> good. Not working yet -> ok. Now is the perfect time to fire up a debugger and to take a look at whats really happening. I spend a lot of time in the debugger to learn how the AI does its things and its the only way i know how to really learn the ways of the UT AI and how to handle its complexity and how to modify it. It would have probably taken me 10x the time to learn about the AI by just reading through the code, using a log output here and there. A debugger really saves you a lot of time on this. There are debuggers built into some Unreal Script IDE´s but personally i use a debugger that is independent/separat from the IDE and just called "unreal debugger" (https://code.google.com/p/unreal-debugger/) and its really easy to use.

Nice work so far. About AGT we could make its range a property that could be changed in the editor if that would help.

Thx for summing it up Bro. And thx to Yosh for helping out on the mutator side. We now have some kind of community driven evolution of the game going on and that is big. And the devteam has nothing against that. It really gets some pressure from our backs and we really want to empower the players to make evolutions to the game themselves. For that reason we will try to get even more tutorials up in the future. For instance check out the new vehicle tutorial Havoc89 just recently posted. Also i hope to find some time to write up an in depth tutorial about making code mutators for ren x. So through the mutators most of these changes should currently be running in EKT and TMX atleast. A patch with the listed changes and more might follow next weekend.

Yeah i´ll make sure it can be deactivated. For the health bar what about showing health and armor together in the box but armor would be shown in a different color ? Like silver or blue for armor maybe. So then the health bar could show health and armor at the same time.

I want to try this idea out badly aswell so since it seems this cant be modded in atm and needs a game update anyway i can incorporate this into the main game aswell while im at it so that a mutator wouldnt be needed. Would have gladly helped you to do this as a mutator but i really dont know how. If i incorporate it into the game with the next patch i´ll make sure the armor and health values can be tweaked through ini´s and that it coudl be modified more with mutators.

Yes doing it like the Orca and Apache changes in the BalanceMutator would be how i would try to exchange the BuildingInternalsClass aswell. But this wont work atm cause it is set to be a "const" variable so it can not be assigned something else with the mutator and trying it would give you an error when compiling the mutator. But we will remove the "const" with the next RX patch as i see no purpose for it. "Or, if I leave the armor and the way the structure handles damage and healing, could I just leave the health vanilla and see if it works?" Yeah something like that. But you will need to extend Rx_Building_Internals and you will also need to do that for every different Building_internals there is (one for every building) as only the specific types Rx_Building_Internals_Barracks etc are spawned and thus only them are "real" objects in the game, Rx_Building_Internals is just an abstract version of it that doesent exist in the game world and therefore cant be replaced with a mutator. But i dont want it to sound too complicated. You already figured out a lot in a short ammount of time and you are on the right track.

You "extend" Rx_Building meaning all the variables are inherited by your class automatically. So you already have "Health" and "HealthMax" wich is why defining them again in your class gives you the conflict error. Most likely the biggest problem you will run into though is that i dont think its possible to replace the building or building_internals classes with a mutator right now. They are not going through the CheckReplaceMent function of the mutator and you also cant exchange the BuildingInternalsClass setting of the normal building classes as BuildingInternalsClass is set to be const. I will look into opening it up more so that a mutator to atleast replace the building_internals classes would be possible. Replacing the Rx_Building classes themselves might already be impossible as they are part of the map and not spawned at runtime. So i think the map itself would need to be updated to use modified buildings. But we separated Buildings in their map part (Rx_Building) and their "internals", logic oriented, part Rx_Building_Internals (wich is spawned at runtime and therefore should be accessible to a mutator somehow but not right now i think). Replacing the Building_Internals should be enough to do such a mutator but again i dont think that is even possible right now. So i think you need to change your mutator to extend of Rx_Building_Internals instead of Rx_Building and then you will most likely also have to wait for the next patch with changes to make this buildingmodification possible with a mutator (but maybe im wrong and it is possible but atm i see no way how).