And then we will realise nobody wants to use 0.8 despite of a particle system, raytracing and ability to recreate literally every game server-side because "0.8 is a shit and 0.7 is a bless of gods".(edited)
06:29
Learath2 will add SevenUp protocol to ddnet meanwhile.
DDNet would move to 0.7 if there was a clean way to mod 0.7. I spent atleast a month doing a rewrite on 0.7 though I just wasn't willing to invest more time into something that will become obsolete and impossible to upgrade
09:54
Eh, I was scrolled up a little, was replying to noby
The only feature of 0.7 I am missing now on ddnet is a newer skin system. Oh and maybe proper game states and matches, but that's fixable serverside.(edited)
I wonder which project will get ability to download custom additional tilesheets and use them as custom server-manageable entities?
The first wil make it will get a massive boost of mods I guess.
10:25
I still want to recreate battlefield mod but with proper tank/helis sprites instead of that jerky structures made of hearts.
I think one could make it backwards compatible. So far I think that downloadable sprites will be used as new custom types of projectiles/powerups. I think it's possible to make it as extension with a fallback to regular hearts and bullets.
Downloadable content would definitely need a compatibility break. In general it's a problem that nowadays breaking compatibility is such a huge problem. Adding new rather big features often isn't possible while still supporting old clients. For example a workaround like using hearts and shields instead of additional assets is just awful.
Even a modding api would not be perfect from the start. Extending it (in a proper way) would still require a break in some cases. IMO that should not be a big deal but the api should be as stable as possible, so mods can easily upgrade and use new features. Just extending the code without an api is kinda pointless today. Most mods are not written with updateability in mind. To be honest, that's rather hard with the current code base.
People will rather stick to ddnet or 0.7 and maybe we will see 0.6/0.7 to 0.8 bridges, which ofc do not support any new features
as long as the protocol matches a bridge can support any features they want. I think he means features that can not be replicated on across versions. (e.g. downloadable contents
@redix 100% agree with everything you said, that's the whole problem. Even if we release a brillant 0.8 with lots of mod capabilities if there is no content to offer people won't come
17:40
And the content is too old and too difficult to port (teeworlds code structure is partly to blame for that)
17:40
People's first arguments against moving to 0.7 was no teecomp, no antiping, no ddrace etc.
wasm would be good. One could use any programming language that compiles to webassembly and it should be pretty fast. But it still lacks some stuff. Building an easy to use api doesn't really work today(edited)
yeah but considering how much work was put into the javascript VMs (which are also used for wasm) in the last years, I guess these might be faster than lua
yeah but considering how much work was put into the javascript VMs (which are also used for wasm) in the last years, I guess these might be faster than lua
as long as we can design API i'm fine with it, at this point I have written in more languages than i have friends irl
for the start it might help to clean up the stuff in game/server/ so it's more modular, but the ideal case would really be a scripting api, so you can update the binary and reuse mods
Also any game engine or a game with an embedded interpreter was a pain to use. Its API always was incomplete, undocumented, full of side effects. And it doesn't matter what language it is, I've tried embedded python, ruby and thanks to tw, a lua. Last was the worst.(edited)
I've dumped lua out of my mod just because I've spend more time learning how lua to C++ bindings work and failed to grasp that complexity. I've invested like a month in it and didn't succeeded.(edited)
If we can avoid script AND get better prediction, that would be fantastic, and mods can still lives in C++ with better performance. so if you can, please do
19:01
The topic started with providing better prediction/antiping.
if there will be prediction rulesets like I've mentioned that would provoke other people to rewrite mods
I've had rewritten WaterMod on ddnet by using 0 lines of code and 4 rules of tune zones.
Having right tools is rewarding. I've made it just for fun, I knew I have all tools in codebase.
If we will add those tools then rewriting old mods will be a lot easier in newer tw.
would be so nice if we could have tunning parameters customizable per entity (not type)
currently tunes help mostly to stop prediction errors on a player character
tune zones bound to tiles only are limited, but if there would be a way to tell it affects that type of projectiles or even projectiles marked with some flag that would be super useful
for example I cannot make a real flight of a bat in infClass, it's just infinite jumps
but if I could bind to character a tune I could make it really fly and fly faster than general air_control_speed allows me(edited)
For example in infClass there is soldier and merc bomb explosion which are in fact a series of visuals and a HUGE radius ONE explosion that gives force based on distance from center to characters
19:32
on high ping you don't know when explosion will happen
so you cannot predict that is not there yet. But the second the client gets a snapshot it just adds a force to a character and that's all. job done(edited)
because I'd wanted to server be able to tell client "you're frozen, so if you press arrow key nothing will happen" and not to send it "ground_control_speed 0" instead(edited)
because I'd wanted to server be able to tell client "you're frozen, so if you press arrow key nothing will happen" and not to send it "ground_control_speed 0"
I just have fear that solution will require that level of expertise that 0-2 people of dev team would be able to do that.
And they will be the most busy persons ofc. So we will get VM in tw 10.(edited)
where to start and where to end? you would need to extend the protocol for it. You start with simple shapes, continue with custom assets, animations, more advanced shapes, text, custom physics...(edited)