henningstone / hmod Goto Github PK

When a custom tune is applied to a tee, the client should be sent updated tuning parameters.

Commonly used feature on many mods; native support would certainly be greatly appreciated.

Might be useful for #11

Should follow DDNet's protocol for client compatibility.

You should take a look on that one.

The possibility to set the number of additional airjumps (or unlimited).

Make it possible for gametypes to add dummies to the server that can then be controlled through a handle. This is meant to provide a simple interface to hide away all the input logic in cases where it's not needed. The standard way of setting manipulating the dummy's input struct will of course still be available for granular bot development.

In order to correspond with master server rules, dummies on the server will not increase the player count in the server list, but instead decrease the number of slots available on the server. The server browser's scoreboard will group together all the bots into a single element at the top, just displaying SPEC < 5 bots > to inform potential new players that there are server sided bots on this server.

A call to Srv.Server:AddDummy(string Name, string ) will return a CPlayerDummy pointer. The CPlayerDummy class inherits from CPlayer and adds additional methods for easy dummy control.
These methods should include:

• WalkTowards(vec2 *Point) makes the dummy go towards the given point. There will no checks be done if the point can actually be reached, that's up to the scripter. If the dummy does actually reach the point, it will do it's best to stay there until instructed differently. Call with nil as the argument to stop moving.
• JumpIf( { function Eval(CCharacter DummyChr) *} ) The given function is evaluated every tick if a destination point has been set using WalkTowards. If the given function returns true, the dummy will jump. this and self are valid for the concerned dummy object.
• TargetPlayer(CPlayer *Player [, int AccDev]) will make the dummy target this player (i.e. aim at him) with the given accuracy deviation. 0 means aiming perfectly on the tee, higher values set a margin for randomization. Default is 0. Pass nil as the first argument to unset the target.
• Attack() makes the dummy attack the set target if it is in range of the dummy's current weapon. (This method only instructs it to shoot, no positional change will be performed in order to be able to hit the target). The dummy will keep on attacking until Peaceful() is called. If there is no target set, this function does nothing.
• AttackIf( { function Eval *} ) The given function is evaluated every tick after Attack() has been called. If Eval does not return true, the dummy will ignore that he's supposed to attack for the current tick. Call AttackIf with nil as an argument to unset the callback, which will make the dummy always attack. this and self are valid for the concerned dummy object.
• Peaceful() stops the dummy from attacking (but does not unset the target)

Possible events emitted by dummies include:

• OnTargetReached(vec2 Point) called when the dummy first gets closer than 32 to the point specified with WalkTowards. The point is passed as an argument; this and self are valid for the concerned dummy object.

// TODO: amend these lists with whatever comes to mind

A note about uncommon semantics used in this document:

• (1) An asterisk (*) to the left of an argument means that this argument can be nil.
• (2) Curly brackets ({}) around an argument mean, that this argument has to be an an array (i.e. a consecutively numerical indexed table) of elements of the denoted type.
• (3) An asterisk to the left of the closing bracket in (2) denotes, that you can pass a table, but also just a single element of the given type.

All tuning variables must be bound into the api read-only. Additionally, it should be possible to assign each character individual tuning parameters that gameplay will obey (not talking about faketune!).

ref #3

sv_spamprotection is part of vanilla, but it only allows you to toggle it on or off altogether.

A customizable spam protection allows to adjust the delay on every single aspect that's protected against spam by introducing additional config variables the server admin can use to change spam delays at will. For example, one may want fast emote switching (which makes it feel so much more snappy), but not fast chat spamming (which is just awful).

Many teeworlds servers use decentralized sql databases nowadays, so let's support that aswell.

In this issue i will collect all missing features of lua ^^.

• CNetEvent's (Like explosions) [wontfix; Explosions: 995c542]
• Chat Management [720c123]
• Config Vars [issue obsoleted, see new issue]
• Tuning Vars [issue obsoleted, see new issue]

If you miss some features too, write it in here! I will collect them and update this Issue.

At least the latter should already be in vanilla, but it's not. People may want to tell their players why the server has been closed, maybe it's just a little maintenance restart, and if noone knows they'll all be gone after that D:

When using the command sv_map in your autoexec.cfg, the server will load the map before startup and immediately reload it in the first iteration of the main loop.

This does not break anything and is just a minor annoyance.

Clients with custom access rights might get messages they're not supposed to see (e.g. lua errors)

I made some tests, and found out that the
MACRO_LUA_CALLBACK_RESULT_REF("OnWeaponFire", Result, m_ActiveWeaponSlot, ProjStartPos, Direction) is not working sometimes (Seems if my weapon got too less reload it simply dont launch the lua function at all!)
What i wanna say with that is, that lua didnt even got a call on that function an ofcourse can't return anything! This is ruining the most of my current mod which modifies all weapons and pretty much need that function/event.

I made a little test with debug prints (they show me that the code, which is only getting launched when i return not true at all) gets launched, but this is impossible because i always return true at all.

In my 2nd test i just modified the default value from false to true and it worked perfectly (it always printed my debug print in this function 👍 ). Ofc. it do not work at all if i delete my custom function and let the default value at true. This says to me that lua/the callback event must return nil at all.

Based on the fact that this phenomenon only occurs when i call this event in a short period of time i suppose it have to be something with a thread (or lua at all?).

Please take a look onto this.

I currently code a mod via lua and need much output. The chat is not optimal for that but a console.
The only console we can use on a server is the rcon. So I need a fake-auth in the rcon to give a player only player-related commands. (Player related voting menu is not exactly what i want).
You can compare this almsost with the ddnet rcon expect that every tee should gain a own fake-auth indeed of a auth-level. So we can write to each tee's rcon without a interference of the other rcon's.

You should just allow us a special auth-feature and 1 hardcoded command
login s to login as admin.
The other commands should be coded by lua and all tees must gain their own rcon via lua!

Hope this will came true! We will rise to a new era in Teeworlds with that :3

I think currently the global scope gets bloated with the userdata tables that are attached to objects on their creation but never get nil'ed out again

Now that would be pretty awesome if we are able to generate simple "images" in the map layers.
In combination with the issue #14 we could easely create something awesome!!
The reference to the mapconverter.
https://github.com/necropotame/teeworlds-infclass/blob/master/src/engine/server/mapconverter.cpp

Can be taken from the client.

Make sure rcon commands created by the gametype get removed again when the gametype is switched or reloaded so we don't end up with duplicate commands.

Redirect disk write requests to a 'sandbox'-like folder in our appdata directory so that the binary directory doesn't get cluttered up.

Each gametype has to get its own folder, and there should be an option for the end user to override the location and select the folder manually.

Bind all the existing config variables read-only into the api and make it possible for gametypes to add their own. The latter could use a similar system like the one used for registering custom rcon commands (config vars are just special commands after all).

ref #3

It would be neat if you could create custom entities with similar properties to characters in regards to physics collision with other entities and destroyability.
Sure this could be implemented solely in lua but it would be a lot of unnecessary code.