RypeL

To be successful a project like Ren-X needs someone who doesent crack under pressure, someone to rally the team when it matters, someone to remain calm and collected and someone to steadily follow a vision against all odds. Havoc has been this person from day 1. Others did regularly quit, took breaks or started much later. Havoc is the only one that has been activly working on Ren-X all years, every year and always with big contributions and a vision. His personality and the sheer amount of work he put in gained him the respect of everyone. Thank you Havoc, it has been a pleasure working with you and i wish you the best of luck for your new projects!

It wasent random but it might have felt that way because often there might be less room in front of you cause of other tanks, rocks or other cover that your squeezing your tank against, then behind you. So then the system needed to find alternative spots to exit you and those probably felt kind of random. Behind you (more specific: opposite side your looking at) more often is open space so the system doesent need to find alternative locations.Thats my theory atleast why it might have felt more random before.

It was exiting you to the same side till about a year or so ago. I changed it to opposite side exactly for this reason as to make it easier and saver to jump out for repairs in battle. It might be annoying when you are somewhere safe, but it seemed more annoying to first have to run arround your tank to get in cover before you can safely start repairing.

A simple bad word filter should be easy to do and could start simple by obfuscating single words like gay when they stand alone.

Super cringe responses.... Especially for a thing that should be this easy to fix.

Also just here to clarify: The current balancer doesent just balance based on score. It takes a combination of score and amount of kills into account. I think I already posted the formula in the forums sometime somewhere. The posted code is only half the picture that’s why it doesent Show any kills beeing taken into account. And yeah, RX devs don’t get paid so you can’t do it for life and disagreements in the dev team can get to you too. Part of the reasons I left and since i was handling most of that balancer there aren’t much people left who could work on it so ya. @kiraI added enough mutator hooks to the balancer so that it’s possible to change or completely replace it with a mutator. So if you really would wanna take the time to get into it you could get full control over it with a mutator and could try it out that way without having to wait for game updates etc.

They can. Those are map specific settings for both AGT and Ob.

The Ob Prioritizes things it can kill in the next shot. That’s why it will sometimes pick an infantry over a healthy tank. This also means that it will kill off a damaged tank in a rush more often then wasting the shot on a healthy mammoth. So there are pros and cons to this. I’m pretty much the only one ever working on the Obelisk/defenses code and I don’t know how the orig Ob picked targets so I made my own decisions and the thinking was that going for a less healthy target produces situations where it’s beneficial for the defenders and sometimes situations where it can go against them. In the end I hoped it balances itself out and also for the experienced RenX player it might be something they can take strategic advantage of. I had to tell it how to prioritize targets somehow and that’s what I came up with. Prolly surely not perfect but on the other hand probably every decision the ob can make can have advantages and disadvantages to either attackers or defenders. If you wanna propose changes go ahead, though as I think I finally retired for good with no chance of another comeback, you’d have a hard time finding a active dev willing and skilled/experienced enough for picking it up.

I´d also like to say goodbye for having to deal with too many frustrations lately and some dev posts and decisions i dont agree with. Maybe im too picky (possible), but i´m out. As my last gift to the community i modified the mapvote to filter the available maps by current playernumber (customizabel per server) as part of the next patch. It was quite a journey and i´m not sure if i will never return, but unfortunatly i think it would need a few culture changes for me to be able to feel at home again even though the devteam mostly still consists of great people. I´ve never been ingame arround the community much, so you might be wondering who this guy even is. For my own reference and if you wanna find out more about the journey that goes into specifically coding and finetuning something like RenX i attached a list of those of my contributions that i could still g et a hold off. RypeL_Commits_2008_to_2020.txt

My proposition is also suggesting lowering the current respawntime in some situations like low player count. In like a 20 player game one could argue that respawntime should be lowered or removed completly. But for 64 player matches that turn into a stalemate and dont want to end it is a different story.

hmmm ... maybe. But this could lead to too much of a disadvantage for new players i feel.

I cant be doing such tiny improvement to such tiny tiny niche product forever. I started RypelCam 15 years ago (and im a RenX dev for 12). I cant just be there for my old projects forever. Nowadays everything i still do on this projects has to be considered as exceptional bonus that shouldnt be taken for granted. Its really up to new guys to pick up if they want. I dont want to spend my time anymore on such low impact changes, too old for that. And no i cant fix the clock. Its a engine problem, not a RypelCam problem. Also RypelCam for RenX got out of my focus cause the game started to lagg in demos at some point and nobody knows why, wich degraded its usefullness even more.

The question is not about who doesent want to wait. Ofcourse noone really wants to wait. But, like other games that have respawntimes, they are there for a reason and for the bigger picture, for balancing and for ending games timely. Its a strategy game with progression and not just a deatmatch shooter.

Dont use seekTo. Use seekToFrame instead. Its much more accurate (the normal clock gets often broken when fast forwarding). RypelCam displays the framenumber. You can calc what time is roughly what framenumber by deviding framenumber by the framerate If i remember correctly you can use the console command 'ViewPlayer playername' to directly switch to a specific player

I dont think we are making the most of the respawntime atm. Atm it just increases from a min of i think 3 seconds to a max of 8 seconds based on elapsed game time. However it doesent take into account number of players or player veterancy. I think the system would be better off factoring in both and i would like to know what you think. Suggestion: Scale respawntime based on playercount. So if theres just like 6 players respawntime should be lower and shouldnt even go up to the current 8 seconds max. With 64 players the game could benefit from higher respawntime though i feel as it would reduce the players on the field a bit. I would suggest a respawntime scaling factor of like 0.1 at 0 players and 1.0 at 64 players. So that it would be just a linear scaling. Additonally i would suggest to scale respawntime based on veterancy level. Meaning a heroic would have a higher respawntime then a veteran etc. This would serve two things: Killing a higher level player gives you a bigger reward and some good kills could make your team come back more easily If everyone is heroic and the game drags on everyone having a bit higher respawntime should result in good rushes with good kills meaning more and beeing more likely to end the game. So scaling respawn time based on veterancy could i think help ending like 64 player stalemates or stomps more timely I would be happy to hear about your honest oppinions. This would be increadibly easy to implement so if we could come to terms we could add this in the next patch without problems.