Code TW: guys, you need a software architect

[-=THOR=-]

I'm trying to figure out what to call, when, to create a mutator to "balance teams" the way it should work. (see this)

What the heck is that?!?

AIController.SetTeam
ROGameInfo.ChangeTeams
ROGameInfo.JoinTeam
ROSPGameInfo.JoinTeam
GameInfo.PickTeam
GameInfo.ChangeTeam
GameReplicationInfo.SetTeam
ROPlayerController.SelectTeam
PlayerController.SwitchTeam
PlayerController.ServerChangeTeam
PlayerController.ChangeTeam
PlayerReplicationInfo.SetPlayerTeam
TeamInfo.AddToTeam
TeamInfo.RemoveFromTeam
ROAIController.SetTeam

I don't want to start a fight there. Seriously, that just doesn't make sense. If that is representative of the rest of your code (and so far I've seen too many files with 1000+ lines of code), that is a major issue. You should consider hiring a software architect. I've been working in (real) military-grade flight simulators, with hundred thousand code files, and it was easier to understand than this... You need to split things up and reuse code better than you do now. I hope that you will consider seriously what I'm saying. And as I said, I don't want to start a fight here, but if you want your applications to be more reliable, more flexible, more manageable, more reusable and easier to debug, review your software architecture.

 

[Raneman]

As a programmer, nothing pains me more then seeing people write all their code in a few files. Whatever happened to modular programming?

 

[Ducky]

I'm trying to figure out what to call, when, to create a mutator to "balance teams" the way it should work. (see this)

What the heck is that?!?

AIController.SetTeam
ROGameInfo.ChangeTeams
ROGameInfo.JoinTeam
ROSPGameInfo.JoinTeam
GameInfo.PickTeam
GameInfo.ChangeTeam
GameReplicationInfo.SetTeam
ROPlayerController.SelectTeam
PlayerController.SwitchTeam
PlayerController.ServerChangeTeam
PlayerController.ChangeTeam
PlayerReplicationInfo.SetPlayerTeam
TeamInfo.AddToTeam
TeamInfo.RemoveFromTeam
ROAIController.SetTeam

I don't want to start a fight there. Seriously, that just doesn't make sense. If that is representative of the rest of your code (and so far I've seen too many files with 1000+ lines of code), that is a major issue. You should consider hiring a software architect. I've been working in (real) flight simulators, with hundred thousand code files, and it was easier to understand than this... You need to split things up and reuse code better than you do now. I hope that you will consider seriously what I'm saying. And as I said, I don't want to start a fight here, but if you want your applications to be more reliable, more flexible, more manageable, more reusable and easier to debug, review your software architecture.

You will get more suprised by the fact that most of those functions aren't even used at all. This is also why some of the hooks in Mutator.uc (our starting point) are never fired at all. You can overload them in your derived class, but zip will happen

 

[[TW]Strago]

I'm trying to figure out what to call, when, to create a mutator to "balance teams" the way it should work. (see this)

Try modifying ROGameInfo.CheckBalanceTeamsOnDeath()

 

[Ducky]

Try modifying ROGameInfo.CheckBalanceTeamsOnDeath()

Would that not mean that he has to replace the ROGameInfo class with his own derived class and copy all properties run time from the original object to his replacement object? ROhame.Info has a lot of properties. Will be a terrible job to do . Also does it often get updated with SDK changes. How long will the validity of the mutated object stand keeping in mind any future SDK updates?

 

[-=THOR=-]

Try modifying ROGameInfo.CheckBalanceTeamsOnDeath()

If I modify the function with clear details of what I changed, could you integrate it in a future update? Would probably be simpler than developing a mutator.

 

[Yoshiro]

If I modify the function with clear details of what I changed, could you integrate it in a future update? Would probably be simpler than developing a mutator.

Yes, it is possible.