26

Re: [DISCUSSION] Good practices for develop mods

Oh yeah, I thought "enabling UTF8" was like... well shortly I thought it was disabling it. Nevermind. smile

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

27

Re: [DISCUSSION] Good practices for develop mods

freaktee wrote:

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

Schwertspize wrote:

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

DDNet has protections against all that.

Neox wrote:

Oh yeah, I thought "enabling UTF8" was like... well shortly I thought it was disabling it. Nevermind. smile

"Enabling UTF-8" allows non-latin characters - nice for people who don't have them in their mother tongue.

28

Re: [DISCUSSION] Good practices for develop mods

list updated... correct me if I'm wrong about something ... try to give the reasons why it should be accepted wink

What do you think about separating the server and client code? And of the 64 players?
For me separating server and client is a pointless because it is a lot of effort for the benefit obtained.
I'm not at all sure about the 64 players....
Need more positive opinions about these points for add them.

Seeing the points that are being commented it seems that a good idea would be to create a fork of the 0.6.x with all this clean ... as you see?

@xush
I'm sorry if I offended you ... of course that doing these things is not an easy task ... and even more so that everyone is happy with how it is handled ...
Thx you MineTee have procedural maps :B

29

Re: [DISCUSSION] Good practices for develop mods

unsigned char* wrote:

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.

External tools shouldn't rely on binaries' name.
You only have to specify to the tool which binary to use and to manage.
Plus, for a server mod, there may be no client mod, so what's the point to keep _srv suffix if the name is not teeworlds_srv ?

30

Re: [DISCUSSION] Good practices for develop mods

I guess it will be rejected, but I think that any string that could be translated (in particular the ones sent by the server as broadcast or chat) should be written using a gettext-like function. I'm not saying that you should take care of translation or use a library for that, but using a function like _("my string"), and defined by "#define _(STR) (STR)" will help people to translate your mod. I don't care about the name of the function, but at least something to quickly find all strings.

Translation is important, and many people don't understand well English (in particular children). Make easier the work of translators is important for me. Such functions can help to create localized flavour, or true dynamic translation like in InfClass. I'm really just proposing some sort of writing convention, nothing more smile

31 (edited by Neox 2017-02-18 18:09:46)

Re: [DISCUSSION] Good practices for develop mods

necropotame wrote:

I guess it will be rejected, but I think that any string that could be translated (in particular the ones sent by the server as broadcast or chat) should be written using a gettext-like function. I'm not saying that you should take care of translation or use a library for that, but using a function like _("my string"), and defined by "#define _(STR) (STR)" will help people to translate your mod. I don't care about the name of the function, but at least something to quickly find all strings.

Translation is important, and many people don't understand well English (in particular children). Make easier the work of translators is important for me. Such functions can help to create localized flavour, or true dynamic translation like in InfClass. I'm really just proposing some sort of writing convention, nothing more smile

I am for it. I mean, I like it, but... I don't really understand how it works. I saw it in InfClass sources but I couldn't figure out how it works (I didn't try to figure it out, too).
Translation is great, but actually I don't know if a lot of people will want this, because... it looks a bit annoying to make. But as I said, I don't really know how it works.

This should be only for people that really want it imo.

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

32

Re: [DISCUSSION] Good practices for develop mods

Like I said, I'm not talking about making a translation system, but only TAG what should be translated.

In InfClass, I use libicu to take care of plural form, number formatting and Arabic, and a home made translation system similar to the one of TeeWorlds 0.7. The translation is done by the community on Crowdin. I strongly recommend to avoid my approach because libicu is a pain on Windows. Use it only if you want a very good quality for your internationalization system.

Concerning the number of people that use it, it's around 30% of players. Since in InfClass, you have to learn a lot, it's very important that players feels confident with the text. We also provide some help page for frequently asked questions, and it simplify a lot things.

33

Re: [DISCUSSION] Good practices for develop mods

@necropotame:
Currently Teeworlds use "Localize" function for translations (not used in server side)... What about GNU gettext? idk if is good on windows ?¿?
http://fedoraproject.org/wiki/How_to_do … gh_gettext
https://www.gnu.org/software/gettext/ma … t.html#Why

** Perhaps use these tools is a bad decision in games... where need be fast instead friendly hmm

34

Re: [DISCUSSION] Good practices for develop mods

The old version of InfClass used the client translator, and it's a good simple,but limited, method.
Gettext is nice, but can't handle multiple languages at the same time, at least in a simple way. However, the syntax of gettext "_()" and the tool xgettext to grab strings from sources are really good (I use both in both InfClass).

35

Re: [DISCUSSION] Good practices for develop mods

I would agree that removal of client code while server mod development is quote pointless. I don't see any real profit.

Regarding 64pl support: just make you client/server mod compatible with already existing server/client mods which have 64pl support

36

Re: [DISCUSSION] Good practices for develop mods

@necropotame: How you detect user language? Using the country flag?

37

Re: [DISCUSSION] Good practices for develop mods

Exactly. There is also a /language command

38

Re: [DISCUSSION] Good practices for develop mods

What about geoip?

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)

39

Re: [DISCUSSION] Good practices for develop mods

I've though about it, but you need to rely on some sort of online service, and I don't like that. In addition, the drawback are that same than with flags: you get a country, not a language, and in a lot of cases, it's meaningless (like for Belgium, Switzerland or India).

40 (edited by unsigned char* 2017-02-28 03:12:10)

Re: [DISCUSSION] Good practices for develop mods

@rand()
If you download a teeworlds mod that only includes a binary without "_srv" (or something like that) you try to run it like a client... if you see '_srv' you know at the moment that you have an server binary. Is good for humans and software.. in software you can make an list with the binaries and selected by default the "_srv".

@Schwertspize
Like necropotame says... depend of external services... hmm i do it in H-Client and need update the service address because changes the usage policies (pay for use) or offline...

@necropotame
I think that GNU gettext can handle multiple languages... and perhaps best do something for send the language selected on the client to the server...  ?¿?¿?

*** I will update the list with this point...

41

Re: [DISCUSSION] Good practices for develop mods

unsigned char* wrote:

@rand()
If you download a teeworlds mod that only includes a binary without "_srv" (or something like that) you try to run it like a client... if you see '_srv' you know at the moment that you have an server binary. Is good for humans and software.. in software you can make an list with the binaries and selected by default the "_srv".

I strongly disagree with a automated selection according to name suffix.
+ suffix may be useful for human, but assuming a dev change the name, there will be only a server binary. If you download a server mod, you know it is a server…