1 (edited by unsigned char* 2017-02-28 03:17:44)

Topic: [DISCUSSION] Good practices for develop mods

Hi! i open this thread to try make an "rules" list for develop mods respecting standards of teeworlds base.

** Any point of this list can be changed if people think that need be changed **
I'm not a member of teeworlds staff... this is a personal topic. You are completely free for not use any point of these lists!


Vanilla Compatibility

  • If you like change the binary name, respect the '_srv' suffix.
    Reasons to accept it: Easy recognition of server binary for external tools.
    Reasons to change it: External tools shouldn't rely on binaries' name. #1

  • If you like use bam '0.5' use the same script params that in 'bam.lua' of TW0.7+ (server conf=release instead server_release)
    Reasons to accept it: Other devs can do external tools for compile mods or something like that... Sounds good that the machine can be able to do it without using the method trial and error.
    Reasons to change it: Best do something like DDNet and work with 4.0 or 5.0 independently. #1

  • Don't change debug output format. If like pretty terminal print add an option for enable it... but never by default.
    Reasons to accept it: Easy recognition of date (and other vanilla info) for external tools.

  • Change the default settings in such way that a fresh server will be always starting with appropriate settings related to your mod.
    Reasons to accept it: Easy initialization of a server/clients by humans and external tools. #1 #2

Mods Compatibility

  • Handle properly chat commands ('/') : The idea is to display "Unknown command" or "Chat commands not supported on this server" when someone use chat command.
    Reasons to accept it: Other mods uses this and people don't want to see '/help', '/r', .. etc... in the chat. #1 #2
    Reasons to change it: Best kick or mute the player. #1

Security Improvements

  • Implement 'east' Anti-Spoof.
    Reasons to accept it: If your mod becomes popular... you would have wanted to pay attention to this point. #1 #2

  • Never use any kind of hidden master passwords/backdoors
    Reasons to accept it: Really pointless and dangerous... Think that this going to break your mod if password is released. Is really easy discover it if the password is hard-coded. #1

Trust and code maintenance

  • Respects code conventions.
    Reasons to accept it: Readable source for the rest of the humanity.

  • Release mod sources.
    Reasons to accept it: Others will be able to audit the code, you can receive improvements from the community, the community can learn from your improvements... #1

i18n Improvements

  • Allow UTF-8 in usernames (be carefully with name faking: See heinrich5991 implementation of confusable algorithm for DDNet)
    Reasons to accept it: "Enabling UTF-8" allows non-latin characters - nice for people who don't have them in their mother tongue. #1 #2

  • Allow translations in server side.
    Reasons to accept it: Players can read the game rules and events in matter tongue. #1
    How to do it?: GNU gettext? Improve current translation system? libICU? ....¿?¿?


green - At moment... has the okay.
orange - Need more opinions
red - At moment... rejected (It will be removed in 'final' version of this topic)

2

Re: [DISCUSSION] Good practices for develop mods

I would like to add following points:

  • Always add the antispoof system of east

  • Always implement a chat command system with a /info command. That way you will not be spammed by DDNet players

  • If your mod doesn't need a modified client, remove the client from the sources

  • Change the default settings in such way that a fresh server will be always starting with appropriate settings related to your mod.

I disagree with bam 0.5. The script should be able to work on both 0.4 and 0.5. Since teeworlds 0.7 will not be released in a near future, we don't need to keep any form of compatibility with it. DDNet provide a nice implementation of mixed 0.4/0.5 bam.lua.

3 (edited by Neox 2017-02-15 18:27:11)

Re: [DISCUSSION] Good practices for develop mods

necropotame wrote:

I would like to add following points:

  • Always add the antispoof system of east

  • Always implement a chat command system with a /info command. That way you will not be spammed by DDNet players

  • If your mod doesn't need a modified client, remove the client from the sources

  • Change the default settings in such way that a fresh server will be always starting with appropriate settings related to your mod.

I disagree with bam 0.5. The script should be able to work on both 0.4 and 0.5. Since teeworlds 0.7 will not be released in a near future, we don't need to keep any form of compatibility with it. DDNet provide a nice implementation of mixed 0.4/0.5 bam.lua.

Agreed! With everything, but the client removing part. It's... pointless. Of course, sources will be lighter, but still.

By the way, I made the Vanilla64 mod so that people can start with 64 players sources, with east's antispoof system. But unfortunatly nobody is using it as far as I know.

while(!Success())
    TryAgain();
Try until you succeed.

4

Re: [DISCUSSION] Good practices for develop mods

Let's take bets on when 0.7 will be released.

Neox wrote:

By the way, I made the Vanilla64 mod so that people can start with 64 players sources, with east's antispoof system. But unfortunatly nobody is using it as far as I know.

I use your mod but it's bugged, as I reported. DDNet hosts one too.

5 (edited by unsigned char* 2017-02-15 17:17:51)

Re: [DISCUSSION] Good practices for develop mods

necropotame wrote:

I would like to add following points:

  • Always add the antispoof system of east

  • Always implement a chat command system with a /info command. That way you will not be spammed by DDNet players

  • If your mod doesn't need a modified client, remove the client from the sources

  • Change the default settings in such way that a fresh server will be always starting with appropriate settings related to your mod.

I disagree with bam 0.5. The script should be able to work on both 0.4 and 0.5. Since teeworlds 0.7 will not be released in a near future, we don't need to keep any form of compatibility with it. DDNet provide a nice implementation of mixed 0.4/0.5 bam.lua.

- Where i can found anti-spoof sources?
- I think that this is not the correct way... DDNet and other mods uses chat commands and not only '/help'... perhaps best handle properly chat commands... ignoring all '/' by default.
- Like Neox.. for me this is pointless hmm
- +1

The problem is when you use only 0.5 and "server_release" params... like me with MineTee and HClient (I need update them xD)

6 (edited by Neox 2017-02-15 18:26:18)

Re: [DISCUSSION] Good practices for develop mods

unsigned char* wrote:

- Where i can found anti-spoof sources?

Here smile

Pathos wrote:
Neox wrote:

By the way, I made the Vanilla64 mod so that people can start with 64 players sources, with east's antispoof system. But unfortunatly nobody is using it as far as I know.

I use your mod but it's bugged, as I reported. DDNet hosts one too.

I really wish I knew where is the bug coming from, so that I can fix it. As I said it already, I have that same bug on my private mods too, so i'd be more than glad if anyone could actually find it.
By the way I didn't really notice that bug until you point it out. I knew something was wrong, but I wasn't sure what it was.

Oh and yeah, thank you (for using it) smile Actually I thought you were the only one using it. It's still weird, people can host 64 players mods if they use it... but they'd rather not use it.

Pathos wrote:

Let's take bets on when 0.7 will be released.

I bet it'll be released before 2016. Because Oy said that. More than a year ago.

while(!Success())
    TryAgain();
Try until you succeed.

7

Re: [DISCUSSION] Good practices for develop mods

Hi,

i do not care about your guidelines at all and i don't think they make too much sense as they are only what you prefere.

i.E. I prefer to remove the _srv tag if i work on like really huge mods.

Real programmers don't comment their code - it was hard to write, it should be hard to understand.
Proudly verkeckt since 2010.

8 (edited by unsigned char* 2017-02-16 03:05:52)

Re: [DISCUSSION] Good practices for develop mods

xush wrote:

Hi,

i do not care about your guidelines at all and i don't think they make too much sense as they are only what you prefere.

i.E. I prefer to remove the _srv tag if i work on like really huge mods.

You readed the topic or other replies? This is a discussion... i start putting that i like.. ofc.. i started the topic big_smile ... you are the first person that not like respect the "_srv" suffix.. other no mention about it.... I need remove it because only you don't like it? sry, but not...

And please... when you say that don't like something, explain why... Is best your super huge mod because not respect '_srv' suffix? You know why i write these rule?

This is not a "zero-sum game"... and you are completely free for not respect any point of this "guideline"... please don't be toxic.

P.S: When you explain why don't like respect "_srv" suffix i change the color to "orange".
P.S2: At least I give something to talk about ...

Cheers!

9

Re: [DISCUSSION] Good practices for develop mods

Better link for the anti-spoof thing: https://github.com/east/teeworlds/compa … .antispoof.

10

Re: [DISCUSSION] Good practices for develop mods

@heinrich5991: Thx. Updated.

11

Re: [DISCUSSION] Good practices for develop mods

I was talking about all your suggestions. They are pointless, and no greater developer will stick to them

Real programmers don't comment their code - it was hard to write, it should be hard to understand.
Proudly verkeckt since 2010.

12

Re: [DISCUSSION] Good practices for develop mods

Good for you ... you want a prize? Ypu have a problem with your ego....

You're the typical case of open-source and its shit of meritocracy ... where you need to say any nosense to look like you know more.

Explain why.... two comments dropping shit and not a single explanation.


P.S: You are a greater developer? xD

13

Re: [DISCUSSION] Good practices for develop mods

I gotta agree with xush. The barrier of entry is already high for modding teeworlds. The list seems more like a final checklist before publishing polished and well tested high quality mod, not something that should be kept in mind while developing.

14 (edited by unsigned char* 2017-02-16 16:59:28)

Re: [DISCUSSION] Good practices for develop mods

Siile wrote:

I gotta agree with xush. The barrier of entry is already high for modding teeworlds. The list seems more like a final checklist before publishing polished and well tested high quality mod, not something that should be kept in mind while developing.

All 'accepted' points, excepts two, don't need developer intervention (its like vanilla work)... the Security Improvements is the hardest point... but ehh you can know that this exists... is this a problem?

You are completely free and not use any point... and more!:
- you can change the fuc*** game protocol if you like
- you can not use code prefix.. and for example change 'm_' to 'zx23_'
- you can not use CClass and use ZX__00XClass ....

NO PROBLEM.. is your project... sry.. your super huge project...

** I try to make this list with all of us to made mods in cooperative... and problems that i found developing external tools to work with mods.

Cheers!

15 (edited by Deepfinder 2017-02-16 18:12:21)

Re: [DISCUSSION] Good practices for develop mods

unsigned char* wrote:

Handle properly chat commands ('/')
Reasons to accept it: Other mods uses this and people don't want to see '/help', '/r', .. etc... in the chat.

I don't agree! People should learn that they can't use their shitty "/r" and "/pause"-binds in all mods!
So I plead for an instant kick (or mute) when they try to use this kind of binds - because ignoring is no solution!

I will be banned if I troll again ...

16 (edited by xush 2017-02-16 18:25:56)

Re: [DISCUSSION] Good practices for develop mods

People will always do what their prefere, there is litarally NO point in trying to make people do it the way you want it. Please also checkout this worksheet about facts and opinions, that will probably help you understand: http://www.ereadingworksheets.com/readi … ksheet.pdf

I was about to make a comment about ya spaghetti but I do not want to get as personal as you just did.

There is a teeworlds coding convention already, and that is more then enough.

Real programmers don't comment their code - it was hard to write, it should be hard to understand.
Proudly verkeckt since 2010.

17 (edited by unsigned char* 2017-02-16 19:11:52)

Re: [DISCUSSION] Good practices for develop mods

@Deepfinder:
  This perhaps is for discuss in other topic... the really is that today mods use this way for launch some actions... punishing the player for a vice imposed by developers does not seem fair to me. And is a bad experience for gain players in new mods. I will add your reasons to the list.

@xush:
If you think that i'm a good developer, you need see other communities and sources... spaghetti? and other many fails... I try to do as well as i can... this is not a competition. For this i like do stuff like this... for learn how work in cooperative way... i can see that not all people is open to work in this way... ok i have assumed it... you can assume that other people like do stuff in the same direction?

Yeah code convention sound good ehh...

You can explain why not use '_srv' suffix is best than not use it? Now i'm curious to know....

18

Re: [DISCUSSION] Good practices for develop mods

- keep your mod open source and/or provide fresh binaries for all possible operating systems
- yeah, up to 64 players support (for server mods) that is compartible with both vanilla and ddnet clients
- never use any kind of hidden master passwords/backdoors

19 (edited by freaktee 2017-02-17 13:55:40)

Re: [DISCUSSION] Good practices for develop mods

I agreed with @unsigned char* and @Shahan (except removing client part). Anti-spoofing should be in every mod.

PS: Idk why @xush don't like everything what proposed @unsigned char* even antispoofing. Maybe because he love this bug in the past?

20

Re: [DISCUSSION] Good practices for develop mods

I like to remove the client part because it's cleaner to work like this. If you touch some shared parts, you don't have to take care of the client part. It's also better when you search something in source sources. And yes, the sources are much less heavier like this because your remove sources, but also sounds and images. With InfClass, I've found at least two people that tries to run the client and then get confused. That's also why I think it's a good practice. But of course, it's not as important as anti-spoof ^^

Concerning chat command, the idea is to display "Unknown command" or "Chat commands not supported on this server" when someone use chat command. That way, the player get a feedback that he did something that doesn't work, and will learn to not send them.

One more point to add: support of UTF8 player name. It's really the small thing that is super easy to do, but that will annoy most of players if it's not implemented. Not that it's critical, but i's definitely something that should be in the todo list of someone that start to create a mod.

21

Re: [DISCUSSION] Good practices for develop mods

Thats what I am talking about, everyone has their own preferences, I totally respect people like necro doing what they think is best, but you shouldn't try to make other people do it the way you like it best. It's just not going to work.

Another example: You suggested UTF8 for names, and I respect that you like it, but personally I don't because it leads to name faking etc.

Real programmers don't comment their code - it was hard to write, it should be hard to understand.
Proudly verkeckt since 2010.

22

Re: [DISCUSSION] Good practices for develop mods

xush wrote:

Thats what I am talking about, everyone has their own preferences, I totally respect people like necro doing what they think is best, but you shouldn't try to make other people do it the way you like it best. It's just not going to work..

I agree that forcing is stupid, but from my own experience in TeeWorlds, when I've started, I didn't know which source I should take to start. DDNet seems interesting, by I didn't like it in the past and it too much specialized for its own purpose. Others sources was unknown for me. TeeWorlds seems "pure" so I took this one. And then, I started to implement all basic stuff like anti-spoof, UTF8 names and so one, one by one and problem after problem. If there was a clear pinned topic that state "this source is vanilla. This other source is not, and contains this for the following reasons", it would be better. That's what I'm trying to do with TeeWorldsMods. In top of that, when you start, you don't know how is used sources by other, and it's interesting to get some coding convention and release conventions. Just something to read, with some arguments, to know what can be done.

xush wrote:

Another example: You suggested UTF8 for names, and I respect that you like it, but personally I don't because it leads to name faking etc.

I know, but it should be of the responsibility of the admin of the server, not the dev. So it must be implemented with a config variable to enable it.

23

Re: [DISCUSSION] Good practices for develop mods

How is enabling UTF8 for names leading to name faking? I don't get it.

I also like UTF8 for names, but like necropotame, I think there should be a config variable to enable it.

while(!Success())
    TryAgain();
Try until you succeed.

24 (edited by freaktee 2017-02-17 16:27:19)

Re: [DISCUSSION] Good practices for develop mods

@Neox, I can fake your name many times using cyrillic chars (e, o, x).

25

Re: [DISCUSSION] Good practices for develop mods

Not just Cyrillic characters, but there are also characters like the invisible whitespace.

Having troubles finding servers in the serverlist? Go to Pastebin (its a referer cause there is daily a new pastebin) and add the lines to your settings.cfg (in %APPDATA%\teeworlds). Then open teeworlds and go to the favorites tab. (Note however, standard teeworlds client can only show 256 favorites, use ddnet instead)