Byond 512 code#
The only benefit to having these be component-level objects is if you want to reuse the data structure in dozens of places in your code and don't want people using your code to have to reinvent it at every place it needs to be used. And those cooldown objects? They are inconvenient wrappers around basically a number now that I've had my way with them and fixed all the problems with them. Two, label resolution is going to slow down the execution, and three, it requires the developer to understand not only the structure of the mob itself, but the structure of cooldown objects. For starters, you lose code clarity and compiler safety when you call on a list like you are doing. The really annoying part about using this approach, is that embedding these behaviors into a datum of its own is cool and all, but really annoying from a usability standpoint for a number of reasons. Issue #5: The unsafe, ugly chain of operators If your cooldowns aren't meant to be used in a game with any kind of saving, you need to mark your variables temporary:Īnd now the whole persistence issue is completely fixed. There is an implicit second value with time, and that's now, or world.time. Which means you don't need the boolean anymore because we have time, and as I showed above, time can be used to not only fix bugs already in your current approach, but can completely replace the boolean because time is a quantity that can be derived down to a boolean value when paired with a second value on demand. This cannot be fixed with a boolean-based approach, so if you are going to add any kind of saving or persistence to these, you need to track the time that the cooldown will end. This is why boolean-based cooldowns and sleeps should never be used for timing at this level in a game that has any kind of persistence. They are stopped, and their cooldowns will save as they currently are, which in your system's case means they will never be set to not triggered again. When a player logs out, those slept procs don't save. One's a huge dealbreaker.īecause you are depending on sleep(), you need to account for what happens when you try to save a cooldown. After it's off duration we need to set triggered to FALSE againĪs cooldowns is just an example, this approach of code can be applied in so many different ways.Īlso, I wanted to point out two more major problems with this approach.
This is the sleep duration, before it can be cast again. Then flip the condition so it won't stack over itself If triggered is FALSE, it wont fulfill the statement of the proc, nor create a new object) (triggered is also used to inform a verb/ability() when it is allowed to cast a new object. We need to ensure the proc doesn't repeat itself. Triggered needs to be set to FALSE, so the ability can be used. * the ability using this cooldown dstum calls for "triggered" Each cooldown needs a reset(), in where variables is reset TRUE means it is ready to start a new cooldown Toggle explains the datum whether it is triggered or not. This holds the datums cooldown time, and to how long it will last. This acts as a name, in which it holds a name so we know which datum we are working with First we need to set a few variables to our datum However, the current stable build(v.511) will have a harder time doing what we want to achieve.
Byond 512 how to#
This tutorial will also show you how Lummox's latest build improves the usage of datums inside lists, and how to properly apply the changes. An other reason is, the cooldown datum is easier to handle if it is a fixed data to each player, and not a cooldown that is created then deleted over and over again. This is because we don't want every ability created to hold "unnecessary" information, as there would probably be hundreds of these objects created over time. We will not store the cooldown to the ability itself, but to the user casting it. In this example, we will use a fireball as an example. The way to store it is by adding it to a list, and save it as a string relative to the ability it functions for. Var/list/food = list( "bread" = new/bread())Ī cooldown acts as a datum which is stored for individual players. Bread/ proc/eat() world << "You eat some bread"
0 kommentar(er)
