[fysiks]

NEVER trust a pre-compiled plugin that you didn't get from compiling locally, using the webcompiler (@ amxmodx.org), or using the "Get Plugin" link for plugin attachments (in this forum). I've attached the plugin so that you can click on the "Get Plugin" link to get the .amxx file for this plugin.

Originally Posted by DynamicBits You'll have to compile it yourself on your server. The web compiler doesn't work and I can't fix it.

I'm not sure why you keep propagating this fallacious idea. There is no code in your version of this plugin that requires compiling locally. Previously, I tested your plugin using the "Get Plugin" link and it worked perfectly fine. Also, as of 30 seconds ago, it compiles without errors in the amxmodx.org webcompiler (copy/paste).

EDIT: Ironically, there seems to be an issue with uploading files via the "Browse" button on the webcompiler page (which is not related to the compiler itself). However, the copy/paste method works as stated above.

[DynamicBits]

Originally Posted by ViBE DynamicBits, will you continue the development? i'm just curious.

I never really stopped, but forward progress has been moving slower than I anticipated. I changed too much at once, and now when I go to work on it again, I have to spend too much time going over everything to understand what else needs changed. I've cleaned up a lot of code and added many more comments, so that helps. I don't think I've mentioned this on the forum yet, but since you're twisting my arm... the next release will be v4.0. There are Tries, one or two drastically smaller arrays (like 75 times smaller.. I don't know how I never noticed that problem), better support for mods other than Counter-Strike, some improvements in file reads/writes, among other changes.

Originally Posted by fysiks I'm not sure why you keep propagating this fallacious idea. There is no code in your version of this plugin that requires compiling locally. Previously, I tested your plugin using the "Get Plugin" link and it worked perfectly fine. Also, as of 30 seconds ago, it compiles without errors in the amxmodx.org webcompiler (copy/paste). EDIT: Ironically, there seems to be an issue with uploading files via the "Browse" button on the webcompiler page (which is not related to the compiler itself). However, the copy/paste method works as stated above.

Compile the following code locally and then with the web compiler:

#include <amxmodx>

new PLUGIN[]="\\\\\\\\\\plugin"

public plugin_init() {
    register_plugin(PLUGIN, "1.0", "author")
}

Look at the compiler output, specifically the value for "Data size." You'll notice that the web compiler always has a smaller value than code compiled locally. It strips out backslashes. There are backslashes in the DMM code. Removing those backslashes breaks things.

You actually responded to the user that originally reported this problem almost four years ago.

Edit: See Bugzilla bug 3211 from 2008.


--
Andy

[pizzahut]

Originally Posted by DynamicBits I have made some changes to the get_players() calls, and I haven't noticed any issues like what you're reporting. Would you mind sending me the code you were using before replacing "activeplayers" with get_players()? I'd like to make sure there isn't something else different in your code that could be causing this issue.

I don't think there's a bug in the code itself, just I found counting up and down using those client_ calls to be unreliable (as some of them may get dropped or in case of connect may happen multiple times for the same player) and thus I'm getting the absolute number from get_players. I've got a debug version which displays both numbers in console and activeplayers was much lower than the actual player count, all of them except one had spawned and were playing, too.

Not listed are some changes which I think Jolene did, like removal of early voting that I had added previously (but probably wasn't working right).

Search for "[DMM]" for the debug code.

For everyone else, do NOT use this code it's meant for debugging only.

[fysiks]

Originally Posted by DynamicBits Compile the following code locally and then with the web compiler: #include <amxmodx> new PLUGIN[]="\\\\\\\\\\plugin" public plugin_init() {     register_plugin(PLUGIN, "1.0", "author") } Look at the compiler output, specifically the value for "Data size." You'll notice that the web compiler always has a smaller value than code compiled locally. It strips out backslashes. There are backslashes in the DMM code. Removing those backslashes breaks things. You actually responded to the user that originally reported this problem almost four years ago. Edit: See Bugzilla bug 3211

The file size is not a metric that you can use to determine if two compiled plugins are the same (you were informed by YamiKaitou already).

I did test that example code you posted. And, yes, it does remove what PHP would consider an escape character (probably using stripslashes()). I did not previously test via the copy/paste method. The file upload method probably works (but I can't test that currently). So, since the upload method doesn't work, I guess you win on the argument of whether or not to use the webcompiler (for now).

The "Get Plugin" link when you attach a plugin to your post does not do this. Test your own example plugin.

[DynamicBits]

Originally Posted by fysiks Also, as of 30 seconds ago, it compiles without errors in the amxmodx.org webcompiler (copy/paste).

It may not output an error message, but the source code has been changed before being compiled. The screenshots in this post show the result. If you don't know exactly is affected, it can easily be overlooked. I've spent lots of time tracking the engine's support for text formatting codes. It varies between mods. It varies between Windows and Linux clients. It varies between different dates (mostly improving over time).

Originally Posted by fysiks The file size is not a metric that you can use to determine if two compiled plugins are the same (you were informed by YamiKaitou already).

I specifically mentioned "data size" in the compiler output, not actual file size. Data size is a usable metric.

Originally Posted by fysiks I did test that example code you posted. And, yes, it does remove what PHP would consider an escape character (probably using stripslashes()). I did not previously test via the copy/paste method. The file upload method probably works (but I can't test that currently). So, since the upload method doesn't work, I guess you win on the argument of whether or not to use the webcompiler (for now).

Yes, "for now." The web compiler problem was reported in 2008. I commented on the bug in 2011 to confirm the problem still existed. It still hasn't been fixed. I'm not holding my breath. If it gets fixed (which I hope it does), I certainly won't tell people not to use it. I have nothing against a working web compiler.

Originally Posted by fysiks The "Get Plugin" link when you attach a plugin to your post does not do this. Test your own example plugin.

Correct. When I say "web compiler," I am specifically referring to the page with the filename "webcompiler.cgi" and the heading "Welcome to the AMX Mod X Web Compiler."

If this plugin was composed of a single file, I wouldn't be using a zip archive and the "Get Plugin" link would be feasible. I'd like to avoid having multiple copies of the plugin spread throughout this thread to avoid confusion.


--
Andy

[fysiks]

Originally Posted by DynamicBits If this plugin was composed of a single file, I wouldn't be using a zip archive and the "Get Plugin" link would be feasible. I'd like to avoid having multiple copies of the plugin spread throughout this thread to avoid confusion.

Since you can't include the compiled plugin in the archive, it's actually more confusing to not have the .sma file attached by itself. There are people who run servers that don't want to nor need to know how to compile a plugin.

[ViBE]

Originally Posted by DynamicBits I never really stopped, but forward progress has been moving slower than I anticipated. I changed too much at once, and now when I go to work on it again, I have to spend too much time going over everything to understand what else needs changed. I've cleaned up a lot of code and added many more comments, so that helps. I don't think I've mentioned this on the forum yet, but since you're twisting my arm... the next release will be v4.0. There are Tries, one or two drastically smaller arrays (like 75 times smaller.. I don't know how I never noticed that problem), better support for mods other than Counter-Strike, some improvements in file reads/writes, among other changes.

good to hear. this is still the best map manager. yes as far as i remember you told only me this in PM. anyway i guess i found a bug. i don't know is it new or not. the plugin acts like allmaps.txt does not exist and it always read maps list from mapcycle.txt.

[pizzahut]

Speaking of bugs I have another issue with 3.23, haven't checked if it's fixed in 3.25.
If no one votes (empty server), DMM is supposed to follow the map cycle and it does this, however only until the last map is loaded. When this happens, it's stuck with the last map (i.e. the next map is the last map of the cycle again), unless I add a map specific cfg file (in the maps sub dir of the amxx config dir), containing

amx_nextmap <first map in cycle>

I'm not even sure if the bug is in DMM itself. Perhaps it's a HLDS / TFC thing (using the 2012 version), or maybe the nextmap plugin interferes, which I'm loading prior to DMM so it displays what the next map is if no one voted yet.

[ViBE]

found another bug. sometimes the plugin change to another map but not to the winner. 7 players voted on a map. 2 players to the first, 2 player to the secont and 3 players to the third. and then changed to the second map. very strange.

[ViBE]

another bug in version 3.25B, i guess it's well known: countdown HUD message before vote cause FPS lag. players also reported this to me.