I don't care about method 3 being screwed, because there is only 1 map series (2 maps long) that I've seen using it. That will prevent the next parts being played due to players not completing the current part. On top of that to fix method 2, the nextmap plugin should not increment the cycle position if the time hasn't run out. If the nextmap cvar is defined (from a map), read it as the next one to play then delete the CVAR.Only increment the cycle position if the current position is being played.To fix both method 1, the nextmap plugin needs to take these rules into account: AMXX does not do this, it will skip 8 maps instead. The server DLL will notice that the next map in the cycle is not being played, therefore it holds the cycle position until the current series has finished (with both method 1 and 2). When projectg1 is played, 8 maps of the cycle will be skipped because AMXX reads the map cycle differently to the Sven Co-op server DLL. However, method 1 causes a problem with the AMXX nextmap plugin. Not all mappers are smart enough to see that method 1 is by far the best, neither is it practical for every Sven Co-op server admin to ripent every map to change them to method 1. The problem with 2 and 3 is that if the players don't complete the current map, the next one in the series is played anyway. The whole series must be placed in order within the map cycle file.The map config ( maps/ map.cfg) file sets a cvar nextmap for the server DLL to read.An entity in the map calls the next map (best).Maps have always had 3 ways to call their next map, that is if they are part of a series: When players complete this map, the next map in the series is loaded and played continuously until the series is over (example: projectg2, projectg3.projectg9, end).Īt the end map, the next map in the mapcycle file should be played. Sven Co-op has map "series", by which I mean one map is played (example: projectg1) and child maps after.
0 kommentar(er)
