Final Release Final release of white-listed DynamicMapRotator mutator

[Cat_in_da_Hat]

I also have had problems with RedOctFactory loading with the map rotator.

I had it sitting second in my map list after Apartment and before Spartanovka.

Tonight my server crashed during RedOrctoberFactory which I am putting down to issues with the antilag mutator, however when the server restarted back to Apartments, it then skipped RedOctFactory and moved on to Spartanovka.

Server ran all fine then for another six maps and then had another crash at the end of the map cycle, PavlovsHouse.

I think the crashes are antilag mutator related but my bloody server is not collecting its serverlogs so who the frack knows.

 

[Ducky]

I also have had problems with RedOctFactory loading with the map rotator.

I had it sitting second in my map list after Apartment and before Spartanovka.

Tonight my server crashed during RedOrctoberFactory which I am putting down to issues with the antilag mutator, however when the server restarted back to Apartments, it then skipped RedOctFactory and moved on to Spartanovka.

Server ran all fine then for another six maps and then had another crash at the end of the map cycle, PavlovsHouse.

I think the crashes are antilag mutator related but my bloody server is not collecting its serverlogs so who the frack knows.

Both servers of the [40-1] clan did also crash on RedOct., Comm.House, Pavlov and FallenF. The crashes stopped after they turned off the antilag mutator. Maybe it has something to do with the AT riffles, but that's just a wild guess.
What I like to know is if you have tanks enabled on your server?

 

[-=THOR=-]

On our server tanks are enabled, but it doesn't change a lot because atm we play the small maps, so no tanks. We only had crashes between commissars house and redoctoberfactory, although we have all the maps in our rotation (except gumrak).

 

[Mekhazzio]

Both servers of the [40-1] clan did also crash on RedOct., Comm.House, Pavlov and FallenF. The crashes stopped after they turned off the antilag mutator. Maybe it has something to do with the AT riffles, but that's just a wild guess.

One of the logs they sent me unquestionably showed a crash occurring after an AT rifle shot a tank, but it was about 5 functions deep into stock code and was ultimately caused by a "file not found" error - which is the same error that 2fjg got, and they have tanks disabled. It's not conclusive, unfortunately.

 

[Cat_in_da_Hat]

I think i might disable tanks on my sever for the time being.

Never done that before, is there a master setting for the tanks in the ROGame.ini or do you have to go the section below for each map and make it infantryonly for 32 and 64 players?


[TE-FallenFighters ROUIDataProvider_MapInfo]
MapName=TE-FallenFighters
FriendlyName=FallenFighters
GameType=ROGame.ROGameInfoTerritories
PreviewImageMarkup=<Images:ui_textures.menus.HostGame.ui_hostgame_mapselect_FallenFighters>
Description=Fallen Fighters Map
LoadMapMovie=LoadScreen_FallenFighters
MapTips=TEFallenFightersTip1
MapTips=TEFallenFightersTip2
MapType16=ROMT_InfantryOnly
MapType32=ROMT_CombinedArms
MapType64=ROMT_CombinedArms

 

[Ducky]

I think i might disable tanks on my sever for the time being.

Never done that before, is there a master setting for the tanks in the ROGame.ini or do you have to go the section below for each map and make it infantryonly for 32 and 64 players?


[TE-FallenFighters ROUIDataProvider_MapInfo]
MapName=TE-FallenFighters
FriendlyName=FallenFighters
GameType=ROGame.ROGameInfoTerritories
PreviewImageMarkup=<Images:ui_textures.menus.HostGame.ui_hostgame_mapselect_FallenFighters>
Description=Fallen Fighters Map
LoadMapMovie=LoadScreen_FallenFighters
MapTips=TEFallenFightersTip1
MapTips=TEFallenFightersTip2
MapType16=ROMT_InfantryOnly
MapType32=ROMT_CombinedArms
MapType64=ROMT_CombinedArms

You can do that in the web-admin tool. There is some page where you can allow/disallow vehicles.

 

[-=THOR=-]

If you ever create another version of this mutator, I suggest that you add a URL parameter that would force an update of the LastMapIndex variable, based on the current map in the URL. This way, say if I want to go to TE-Apartments, I would call:

TE-Apartments?mutator=DynamicMapRotator.DynamicMapRotator?DMR_ForceUpdate=true

When the mutator loads, it could look if DMR_ForceUpdate is true, and since it's the case, it would update LastMapIndex accordingly to the position of the TE-Apartments in the rotation. If the map is not part of the rotation, it does nothing.

It would allow to navigate to a specific map in the rotation and continue from there. It would also be useful to be able to use this parameter in the URL of the server start script... in the case of a server-restart, the dynamic map rotator index would adjust automatically.

Another option (more complicated for admins), would be to be able to specify a value for LastMapIndex in the URL. If the same map appears twice in the rotation (for some obscure reason), it would be possible to define which one is considered. But honestly, I don't like this option very much.

 

[Ducky]

If you ever create another version of this mutator, I suggest that you add a URL parameter that would force an update of the LastMapIndex variable, based on the current map in the URL. This way, say if I want to go to TE-Apartments, I would call:

TE-Apartments?mutator=DynamicMapRotator.DynamicMapRotator?DMR_ForceUpdate=true

When the mutator loads, it could look if DMR_ForceUpdate is true, and since it's the case, it would update LastMapIndex accordingly to the position of the TE-Apartments in the rotation. If the map is not part of the rotation, it does nothing.

It would allow to navigate to a specific map in the rotation and continue from there. It would also be useful to be able to use this parameter in the URL of the server start script... in the case of a server-restart, the dynamic map rotator index would adjust automatically.

Another option (more complicated for admins), would be to be able to specify a value for LastMapIndex in the URL. If the same map appears twice in the rotation (for some obscure reason), it would be possible to define which one is considered. But honestly, I don't like this option very much.

I had something like that in one of the earliest versions (but without that extra URL variable). It did work, but it did add some extra conditions which needs to be handled. For that reason I took it out with the following rationals:

• The valila map rotator does also not continue from the last played map if the map was changed by hand.
• Like you said: What if there are multiple map variants in the map cycle?
• What if the map isn't present in the map cycle?
• How often will a map be changed by hand? And is it that importaint to continue with the next one in the map cycle?

For those reasons I took it out. If there is really a request for this, then I can always put it back in again.

 

[-=THOR=-]

I kinda stepped off this conversation for a while, but I have a complete solution now:

1. Remove the index parameter from the config file.

2. Add the URL parameter DMR_NextIndex.
The role of this parameter is similar to the current config file variable. But instead of telling where we are, it controls where we should try to go after the map. So if an admin makes a map change, he can also define where the DynamicMapRotator should try to go after the map, if the number of players allow the map. If it is not allowed, it continues until it finds a map allowed.

3. Add the URL parameter DMR_AutoAdjustIndex.
If true, the mutator tries to find the first occurrence of the current map in the rotation, and tries to rotate to the next one after the map. If the current map is not in the rotation, it defaults to the first map of the rotation. DMR_NextIndex has the priority over DMR_AutoAdjustIndex=true. DMR_AutoAdjustIndex is considered false when DMR_NextIndex is defined, and has no impact. When none of these parameters are used, DMR_AutoAdjustIndex would be considered true.

Why having both? It's much simpler for admins to use DMR_AutoAdjustIndex=true, than having to calculate the index of the next map. However, in the rare cases that a server has the same map twice or more in the rotation, it is necessary to use DMR_NextIndex.

Also, a very important advantage (and probably the most important) comes from removing the index parameter from the config file: the mutator would not write to the config file anymore, so it would not be overwritten on every map change. In other words, the config file could be dynamically edited behind the scenes without requiring a server restart. Atm, if you want to modify the mutator configuration, you have to stop the server, modify, then restart. Server restarts are to be avoided at all cost. And it could be avoided with this solution.

If you don't have time to implement these modifications, but think they are interesting enough, I could make them and submit the files to you for review. If you have objections, then let's talk about it.

 

[Ducky]

This mutator is replaced as of Jun 22, 2012. For that reason it has been removed from the white-list. A newer white-listed version is available. The newer version can be downloaded here.