StealthEye

I'd say you could just set up a normal (internet) server, and connect to it via the local IP using the "Join IP" feature of the launcher.

I guess that shouldn't be the problem then. How long do the freezes take? How often do you get them? Is the FPS normal in between the freezes? If the freezes take long enough, try to press caps/num lock and see if the light toggles while it is frozen. Also, does the sound continue to play?

If you are getting a lot of freezes, make sure your hardware is suitable to play Renegade-X, and check if you have the latest graphics drivers installed. If that doesn't help, your system may be overheating (do you play any other games where you get freezes?). My guess would be that the freezes cause the false positive message. For example, if you are walking at a speed of 1 meter per second, and the game freezes for 5 seconds, then when the game continues, it will cause your character to "jump" 5 meters to catch up for the 5 seconds that it froze (in which your character couldn't move). This jump is then detected and the message appears. You can probably ignore the message; the issue is caused by something else.

Nothing (apart from a decent computer). Just download it from http://renegade-x.com/download.php and install it.

That's probably true, but it's normally still good to know about less severe bugs too. Generally, a development team has different skills and disciplines, and less important bugs can sometimes be fixed by someone who cannot help solving the more severe ones, for example. Or it can be added to a list and be fixed later.

Perhaps it would electrocute you when attempting to pick it up. Or it is glued/nailed to the ground. (Ever noticed how long it takes to deploy it? That's why!) I think there should be a mod where you use the repair gun to remove the glue/nails only, and then have to pick up the beacon and run for it... Would solve the "should there be a period just before detonation during which the beacon cannot be disarmed?" discussion. irl, I guess planting a beacon just to get a GPS lock is probably a bit silly too

There is a "delete" button on posts you made, but I think it only appears if you posted it recently. You should probably ask a moderator to delete the post for you if there is no button.

Yes, that is possible, it is called dual booting. However, I would strongly recommend against installing XP nowadays. It is no longer supported by Microsoft and will not receive any (security) updates. What is the problem you are having with Windows 8? Perhaps it can be solved instead?

BlackIntel developed a team remix algorithm with the same intention for Renegade, but it swaps people based on the previous game's scores on game end. It does not use a global score or ranks, and does not propose swaps mid game. We also ported it to Renegade X and published in the private phase III beta forum. In our experience it works pretty well. I don't think Renegade X adopted it (yet?) though.

Eagle XI, try checking the points you get for the hits to see if it's real or not. Would be really weird if it were true, but nothing is impossible.

xxbullseyexx, you'd best start a new thread with more detail: what happens? does it crash? if so, when exactly? do you get any messages? what have you tried to resolve it? did anything change? what is the content of the log file? (recentmost file in UDKGame/Logs/)

Regarding 1., lag could also make it seem like the pistol killed you in one shot, whereas multiple shots were actually fired.

As far as I can see, Nod doesn't win? GDI wins twice! Did it appear otherwise ingame? It appears that nukes apply damage and points even after the game ended, and in this case it killed the last GDI building. (And perhaps timed C4 too? 756 points difference is 6 too many...)

Yes, that is probably the right conclusion if you are on old hardware. You could try looking up your graphics card's specs though, if your system isn't that old. I think SM3 has been common for 5 years or so now. Although not likely, the game could be mistaken.

Please post the most recent file(s) from UDKGame\Logs. Perhaps they show the reason.

It probably works for automatic gameovers but not for triggered ones. I see two assignments of OldRenScore, one only happens for non-triggered gameovers, the other just copies the value. What I meant in my previous post by "I don't really see why it is necessary" is that I don't see why OldRenScore is needed, as from what I can see, RenScore is not reset before Shuffle is executed (at least not in my tests). I may be wrong if there are cases in which they are reset though. I completely agree with using scores as a basis for shuffling, in fact I introduced the concept to Renegade. I account for bots separately mostly to force human players to be distributed evenly. Imo that is preferable even if scores may imply the bots would be on one team and the humans should be on the other. The inaccuracy occurs when the total number of players is odd. If GDI has 11 players, Nod has 10, and the newly assigned Team1 has GDICount==5 and NodCount==5, then Team1 will become GDI even though this will require 6 GDI->Nod + 5 Nod->GDI = 11 swaps whereas Team1 being Nod would only take 10. I thought the issue occurred in more situations, but it seems I was wrong. So far I could only come up with a counter example where teams are off by one player. It is a very minor issue indeed; I just named it because I noticed it and it's fixed in my version. So yeah, do with my algorithm whatever you like. I just think it's more efficient and gives more accurate results, so I thought I'd share it.

There seem to be some issues with the team remix code. I see at least a few issues: - OldRenScore does not get set correctly (I don't really see why it is necessary anyway). Currently players are all sorted as if they have score -1. - Bots are not swapped (will cause unbalance if one team had 6 bots and the other has 0) - The algorithm prefers (an inaccurate computation of) the least number of player swaps. For variation, I would say it should prefer the largest number of swaps. The attached script solves the issues. It can be integrated with something like: function ShuffleTeams() { local BITeamShuffler BITeamShuffler; BITeamShuffler = new class'BITeamShuffler'; BITeamShuffler.ShuffleTeams(self); } It assigns players to teams evenly, prefers the largest number of swaps, and then distributes the remaining bots evenly. BITeamShuffler.zip

I think that, if the group is too large, split it in two approximately halves. If it's small enough not to cause a balance issue, keep them together.

The BlackIntel system worked slightly differently, I'll explain it below and attempt to adapt it for clan support. Players would be sorted by score, highest to lowest, e.g.: 100, 50, 40, 30, 20, 10, and 0 (I denote players by their scores in my examples) Then, both teams would be cleared and each player would be assigned to the team with the smallest score in order: N: - G: - (both empty, assign player 60 at random) N: 100 G: - (GDI has least points, assign next player (50) to GDI) N: 100 G: 50 (GDI has least points again, assign 40 to Nod) N: 100 G: 50, 40 (GDI has least points again, assign 30 to Nod) N: 100 G: 50, 40, 30 (Now Nod has least points, so assign 20 to Nod) N: 100, 20 = 120 G: 50, 40, 30 = 120 (both have equal points, assign at random, say GDI** ) N: 100, 20 = 120 G: 50, 40, 30, 10 = 130 (now, GDI is full, so assign all remaining players to Nod) **: Actually, it might be better to assign to the smallest team here, although this virtually never happens anyway. This is a quick and easy approximation to get two teams of equal size with minimal score difference. The most notable difference between alternating players is probably that the 2nd and 3rd players usually team up. In my experience, this works very well for balancing the teams. There are some downsides though: balanced teams cause more deadlocks, and in smaller games when two players are significantly better than the rest, they will hardly ever be in the same team (fair, but not always enjoyable). I like the suggestion Gozy makes to attempt to put clan players in the same team. Our algorithm could be adapted to favor placing someone in the same team as their clanmates (perhaps only if the score difference is not too large?). It could also add extra score to the team if multiple clan members are playing together, to avoid too much imbalance. Alternatively, it could do a preprocessing step grouping clan members in a single "entity", and then assigning clans to teams. Splitting up the clan if the clan's players are responsible for too much of the score/player count (and also with a random probability to add some variation?). E.g.: A100, B50, B40, 30, B20, C10, and A0 B50, B40, B20 = 110 A100, A0 = 100 C10 = 10 30 N: B50, B40, B20 = 110, G: - (assign strongest clan B first) N: B50, B40, B20 = 110, G: A100, A0 = 100 (assign clan A) N: B50, B40, B20 = 110, G: A100, A0, C10 = 110 (assign clan C; a clan player would be considered "better" than a non clan player) N: B50, B40, B20, 30 = 140, G: A100, A0, C10 = 110 Just my first thoughts at adding clan support to our algorithm, I have not really thought this through... Should test it with a few scenarios and see if it gives good results I guess.