Aug 16 2013, 12:26 pm
|
|
Paffci0
 |
Ok thank you very much, so I cannot check more arguments at once with only one in operator but why? Is there any reason for that??
|
One technique I saw in SS13 long ago was to store each effect duration in a var, and decrease it once every second if it was greater than 0. No problem with saving and loading, but it requires the character to be periodically updated, which would add a constant overhead (though probably small).
| |
Uristqwerty wrote:
One technique I saw in SS13 long ago was to store each effect duration in a var, and decrease it once every second if it was greater than 0. No problem with saving and loading, but it requires the character to be periodically updated, which would add a constant overhead (though probably small). And this is why SS13 is a resource-hungry game. Ex and company more often than not chose the worst possible method of doing something. | |
Paffci0 wrote:
Hello again, I have a lil bit newbie question, how can I get this work properly? > checkMove(mob/Me) For "stunned" everything is going well but for "feared" it doesn't. I suppose it should be written in a different way. Please correct me. Thanks! As FKI points out, you need to separate out each check into their own clause. Why is that so? (when it would be so much more convenient to be able to do it this way) Well, if you look at that check again in a slightly different way, here's what it is saying: if("stunned") or if("feared") or if("taunted") or if("frozen" in list) It evaluates each thing between the "or" operators ( || ) as a separate check. As for the difference between the operators, || means "or" and && means "and". if(this || that) will pass if either one of "this" or "that" is true. if(this && that) will only pass if both "this" and "that" are true. | |
SuperSaiyanGokuX wrote:
> function_removecompletely(mob/source, cc) This will remove only one kind of cc. To remove all kinds should I overwrite list with empty list? function_removeall(mob/source) ? | |
There are special pre-defined procs for list control. Among those is list.Cut(), which will empty the list.
You can also do the same via a for() loop, but just don't specify what exactly to remove: for(var/whatever in list) As long as "whatever" doesn't have a value, then that will remove everything in the list item-by-item. | |
Ter13 wrote:
And this is why SS13 is a resource-hungry game. Ex and company more often than not chose the worst possible method of doing something. SS13 is a resource-hungry game because it tries to simulate too many systems to scale to the map sizes and player counts it is normally played with. According to recent profiles, it runs calculations on at least 1500 machines and air simulation on at least 2500 turfs every second, on average. For counting debuff times, though, you need to consider both average and worst case performance. Worst case, a bunch of players are fighting, and therefore trying to move multiple times per second. If you use a list, that means doing a string compare on each element of their debuff list, every time they try to move or take an action that can be altered by the presence of certain debuffs. Therefore, the list approach has a higher cost to check on a non-empty list, but no constant overhead when the player does not have any active debuffs, and a low overhead when at least one debuff is present (the cost of one waiting spawn() for each instance of each debuff). The approach used by SS13 has a low cost to check debuffs (one integer compare against 0), but a small constant overhead whether a character has any debuffs or not. However, if the character is being updated every second anyway (which is entirely possible), that overhead is basically the cost of an integer compare (you could even store the presence of each debuff in a bitmask, to further optimize for the case where the character doesn't have any). Note that one global update loop is assumed, rather than one spawn()ed loop per character. For the possibility where an integer is used to count how many instances of a specific debuff is present, the check cost is also one integer compare against 0, but the constant overhead is one waiting spawn() per debuff instance. And the method of storing the time when the debuff will end has a cost of one integer compare against the current world time to check, and no constant cost since it will just time out at the end. However, CPU cost while in-game isn't the only consideration. There is the programmer time cost to implement saving: SS13-style: Just save the value, it'll resume as if nothing happened. List and integer count plus spawn(): Unless BYOND can track the active spawn()s for you, you either need to store the start time of each debuff, or discard all active debuffs while saving/loading. Storing end time: On save, you need to note the current world time, and on load you need to adjust all buff counts based on the difference between the saved and current time. And for removing a specific debuff: SS13 and end-time: set the value to 0 (or the current time) List: remove all instances. while(L.remove(debuff)); Counters: set count to 0 Instance counters/list note: You still have active spawn()s, which will decrement/remove instances of the active debuffs that no longer exist. For counters, this can mean a negative value. For both of them, this means a debuff ending early if a new instance is applied before all of the spawn()s have ended. Displaying debuffs to users: List has words already, so you can show them to the player directly. Non-list does not, so you have to specifically write code to add their names. List and instance counts do not have an easy way to display debuff time remaining, but SS13 and end-time do. Finally, only the list approach directly handles an arbitrary number of unique debuffs automatically, the others require adding a new var for each debuff type (or using list associations, though it would add some CPU overhead for each access). Therefore, either counting the time left and decrementing, or storing the end time are easier to implement saving properly and avoid subtle bugs when a spawn() remains after a debuff has ended early. The list approach is most flexible for dynamically added debuff types, and the non-list approaches are better if you expect to be checking for specific debuffs very frequently, and especially if you expect characters to usually have at least one debuff active. Also note that there are probably other methods, and that there are countless variations with different trade-offs available. | |