Dismiss Notice
Hi, you need to make an account with Steam to register and post on the forums. You can sign up with the sign up button which is shown on the forum's index page.

Scripting CW Dev Tips

Discussion in 'Discussion' started by TacticalToaster, Jun 4, 2019.

  1. TacticalToaster

    TacticalToaster Well-Known Member Regular Member

    To encourage more devs and more competent development for clockwork, I'm making a thread for people to post some tips they've learned when working with clockwork. I'll start off with something for beginners, but feel free to post stuff that may apply to even experienced developers.

    If you do not understand Lua or the specifics of GLua, then this tutorial is not for you. Try to become as familiar as possible with GLua and all the systems of GMod before starting development with GMod, or you will find it extremely difficult to do anything impressive. An understanding of the Source Engine and multiplayer Source, along with the client-server network model is also very useful, if not necessary to develop for clockwork.

    First, before starting working on anything for clockwork, check out the pinned threads in the development section of cloudsixteen. These contain the basics of working for clockwork, and are the best way to start out without getting someone to teach you step by step. Once you do that, it's important to know how to add custom functionality to clockwork through the hooks system. Essentially, all those functions in the kernel files are callable from the schema and plugins. The threads I mentioned show you how to call these functions in the schema and plugins. A good thing to remember is that you're not overriding these functions (only the returned value is overridden, so it returns something decided by what instance of the function is called last. This is explained with loading order), its just that they're called in a certain loading order

    The time they're called is according to the load order. It goes clockwork>cw plugins>schema>schema plugins. This means that if you want to add functionality to a certain schema through a plugin, you'll want to use the schema plugin folder. Remember, returned values are overridden by the hooks later in the order, so you can modify how storage containers work in clockwork if you changed what values are returned in a plugin for the schema, for example.

    If you got any tips you'd like to share, feel free to.
    • Like Like x 1
    • Agree Agree x 1
  2. zigbomb

    zigbomb Administrator Staff Member Administrator

    1. Know the difference between adding things to your schema, and adding it to a plugin. Plugins are highly situational, or rather, to one's own desire. It's all about efficiency and how you conduct your work. One might be inclined to essentially say that small edits to the schema or additions are suited for plugins, much more rather than complicated networking for the schema itself. It's of course up for you to decide these lines in your own ethics, but know that the principles of Schemas and Plugins are essentially the same.
    2. Schemas are just large derivatives of the framework. They are there so you do not have to edit the framework. If you want to edit it, simply override the hooks in the schema instead of hard coding the framework (unless something is fundamentally wrong with said framework).
    3. The line between putting items in the schema and putting items in a plugin is blurred, but items that don't correlate to the plugin (or items that are independent) should be put in the schema. Of course, if you wanted to group items together for specific tendering, (a plugin for each item category, such as: food, junk, medical, etc) then you'd probably be more inclined to do so.
    4. When making your first plugin, don't distribute something simple and relatively useless just to show that you can make a few items. Sharing specific items is also generally useless, in the future, I might release a few packs that include a hot 200 amount of items, or essentially something for everything HL2/CSS has to offer in terms of models, and something like that could be considered lucrative to have for some schema developers. You'll learn quickly that ritualistic and mundane tasks like creating items for schemas or gamemodes (I find the term schema kind of repulsive, it implies it's just a fresh coat of paint on something else when it has the potential to be much more) is actually quite excruciating and boring to do.
    5. Reinvent and distribute something that's new. If it's already been done, don't bother doing it. 'But better' is a title slapped on so much shit that was never worthy of said title, and I can't do anything but suggest you carve your own path; no matter what anyone tells you about it. They don't know shit. It's your project.
    • Like Like x 3
    • Agree Agree x 2