[ColeMiner]

Quote:

Originally Posted by AlonzoTorres Thank you for the answer. I never said that I wanted to be spoon-fed nor did I say that I only wanted one word for an answer. I simply said that you could be more specific at times and make it easier for those who wants a quick answer. You could do this by segmenting the information with as you describe it, "dumb" or as I would say, clear statements at first followed by a more in-depth discussion. No need to feel insulted and no need for insulting me with silly statements such as "and not expect everything to be spoon-fed to you here"... Only trying to help out you know!

Fair enough. Sorry.

Quote:

Originally Posted by Gryphus One The main problem I see with this is there's a limit in the number of filterscripts you can run at the same time. By the way, Y_Less, there's something I want to know your opinion on: I too split my code into different includes, hooking the callbacks and leaving only a few lines in the .pwn file. And generally I'm happy with this way of scripting, however there's something that clearly is less optimized than if I were writing all my code in the .pwn file: loops. Imagine there are several includes in which I have a for loop in the same callback, for example I loop through all vehicles in OnVehicleSpawn. If I hook that callback in those includes and put a loop inside, that loop will be repeated for that callback as many times as includes have that code, however if all that code were in the .pwn file I could loop only once and put all the code from all those includes into that single loop, right?

Short answer: I don't know.

That is a VERY good question, and now you've got me thinking about possible solutions - I don't have one at this time sadly. Something like "ptask", which is explicitly designed for per-player timer would be good; or "PSF:" functions, which are a bit of a hidden feature in YSI but again abstract per-player functions. As for a more general solution for your question, I just don't know unfortunately.

However, you would have to look at how much overhead the actual loop introduces. Most of the time spent on loops is spent doing the code inside the loop, not spent on doing the looping itself. The time taken to run code within the loop will be the same whether you have it in 1 loop or 10 loops (more or less, excluding code that needs to be replicated). If you can use "foreach" for things as well you may even get close to having trivial additional overhead for the extra loops. Of course, it will never be as good as only having one loop.

I was trying to imagine a solution in which hooks could be made aware of inner loops and handle those too, but I don't think that is at all possible. For one thing you would need to handle code run before and after the loop to set things up and destroy them. For another thing, you would have to call each hook for every loop iteration. Both of those problems can be solved, but I think the code required to solve them would be greater and slower than the code used by extra loops, so you are better off sticking to them.

The final question is: Is it even a problem? Yes it is "slower", but is it actually "slow"? If the slower version still runs fast enough to run the server, it isn't something that needs worrying about. If this changes, THEN you can start trying to optimise - bear in mind that readable code is much more useful in the long term than optimised code.