Better lighting and absolutely no 2D objects (this ain't 1995).Gaming Association wrote:What would everyone like to see in 0.5.0?
0.5.0
Re: 0.5.0
*boom* *pow* right in the kisser.
Re: 0.5.0
I wonder if there'd be a way to create an animated 3D mesh that somehow imitates a smoke effect that looks believable. Then that could be added to the torches and the smoke would be client side.jp wrote:Particle spawners are entirely server-side.
But yeah, it would be a hack and not a solution. A proper particle client-side api would be awesome, specially since we have a client-side option to enable/disable particles anyway, it doesn't make much sense for the server to do this.
Maybe such a system could make it viable to have foam in the water, proper smoke and maybe snow/rain.
The same applies to the calculations for ambiental sound effects.
Re: 0.5.0
An "animated 3D mesh" is called an entity in Minetest :)Ferk wrote: I wonder if there'd be a way to create an animated 3D mesh that somehow imitates a smoke effect that looks believable.
But yes, we could fake the particle effect by adding a mesh plane atop the torch model and set an animated texture which let appear a chronical spark on that plane. It would be truly client-side.
Re: 0.5.0
Yes, I know entities (and also nodes) can be meshes.jp wrote:An "animated 3D mesh" is called an entity is Minetest :)
What I was wondering is if the effect would be doable in blender in a way that doesn't look too obvious. My modelling skills leave much to be desired, I wouldn't be able to know whether it's even possible to make it look good as an animation, or if it would need to be in software to be decent.
It wouldn't have to be a truely 3D-looking model, just an animation of 2D planes that move around and have a texture that can use transparency so we could add different particles by changing the skin
Re: 0.5.0
The effect is doable in Blender but not usable in Minetest as a meshnode (an entity is necessary but it's not a good deal for decoration and other placeable stuff, entities are primarily ment for mobs).
But as I said, you can add a plane in the torch model (remaining a static model) and set an animated texture on it (over the Lua code) for the spark.
In black, the torch model.
In red, the 2D plane.
But as I said, you can add a plane in the torch model (remaining a static model) and set an animated texture on it (over the Lua code) for the spark.
In black, the torch model.
In red, the 2D plane.
Re: 0.5.0
I mean mainly knockback. That will make PvP more realistic and funny.Ferk wrote:Can you be more specific? What do you think would be a good way to improve combat?gravelman wrote:Better PvP.
Hopp Schwizz!
Re: 0.5.0
+1 on controlling Player acceleration.
- Calinou
- Moderator
- Posts: 3169
- Joined: Mon Aug 01, 2011 14:26
- GitHub: Calinou
- IRC: Calinou
- In-game: Calinou
- Location: Troyes, France
- Contact:
Re: 0.5.0
Stun is easier to code than knockback. Stun would result in slower movement for a limited time after receiving damage. This would work especially well on mobs.
Re: 0.5.0
Ferk: you would have to deal with server lag also.
-
- New member
- Posts: 9
- Joined: Mon Sep 28, 2015 21:25
Re: 0.5.0
Correct me if I'm wrong but the way I see it, client-side scripting should be a priority because of things like this. Couldn't the knockback effect be done by: (server side) accelerating the entity in the direction opposite to the blow, and (client side) predicting the final position of the entity that was hit and do the animation? I'm by no means an experienced modder but the "everything is done on server side" model seems very silly to me, not to mention that it makes the game feel overall very unresponsive.
- Linuxdirk
- Member
- Posts: 3219
- Joined: Wed Sep 17, 2014 11:21
- In-game: Linuxdirk
- Location: Germany
- Contact:
Re: 0.5.0
If it prevents THIS from happening I’m fine with whatever it takes …jp wrote:But as I said, you can add a plane in the torch model (remaining a static model) and set an animated texture on it (over the Lua code) for the spark.
To me this does not add any “charisma” or whatever you want to call it to the game. It only looks horribly outdated and last-century. Even Doom had better 2D objects.
- kaadmy
- Member
- Posts: 706
- Joined: Thu Aug 27, 2015 23:07
- GitHub: kaadmy
- IRC: KaadmY
- In-game: KaadmY kaadmy NeD
Re: 0.5.0
That wouldn't work, as players have no (Mod-changeable)velocity, and therefore cannot be pushed around. The current mobs_redo mod, however, does already do that.blockybison wrote:Correct me if I'm wrong
[...]
Couldn't the knockback effect be done by: (server side) accelerating the entity in the direction opposite to the blow
The server-side principal is a very good one and usually works well, but coupled with extreme lag/latency is disastrous.blockybison wrote:the "everything is done on server side" model seems very silly to me, not to mention that it makes the game feel overall very unresponsive.
- rubenwardy
- Moderator
- Posts: 6978
- Joined: Tue Jun 12, 2012 18:11
- GitHub: rubenwardy
- IRC: rubenwardy
- In-game: rubenwardy
- Location: Bristol, United Kingdom
- Contact:
Re: 0.5.0
That's why client-side prediction and server side reconciliation is used - Minetest just doesn't have that for mods yet.kaadmy wrote:The server-side principal is a very good one and usually works well, but coupled with extreme lag/latency is disastrous.blockybison wrote:the "everything is done on server side" model seems very silly to me, not to mention that it makes the game feel overall very unresponsive.
-
- New member
- Posts: 9
- Joined: Mon Sep 28, 2015 21:25
Re: 0.5.0
That is unfortunate. If you are familiar with the engine's design, can you tell me why that is, and what would be the challenges to be faced in order to add this feature?kaadmy wrote: That wouldn't work, as players have no (Mod-changeable)velocity, and therefore cannot be pushed around. The current mobs_redo mod, however, does already do that.
I think it's amusing that the project is really concerned about running smoothly on older machines, yet network issues are overlooked. I'd argue that nowadays the second is a bigger issue unless you play on geographically close servers and subscribe to a non-shit ISP (which are notoriously rare if the complaints you hear from people around the world are to be believed).kaadmy wrote: The server-side principal is a very good one and usually works well, but coupled with extreme lag/latency is disastrous.
The ability to do that sounds like a pretty big thing to overlook when you are building an engine that's supposed to be as bare-bones as possible and let the modders do everything else! (edit: but I don't know exactly how challenging it would be to implement decent client-side scripting capabilities so I can't complain too much)rubenwardy wrote: That's why client-side prediction and server side reconciliation is used - Minetest just doesn't have that for mods yet.
Re: 0.5.0
@Linuxdirk : it also grants a larger freedom to texture packs and overall tuning. 1/16 pixels are last century as well... If we were "2015-fad", Minetest would be not Minetest, but Rust. This is a simplistic abstract game anyways.
Re: 0.5.0
Actually I don't get why don't we have the "wielditem" visual available for nodes as well. The torches would probably look much better if they were displayed in the world the same way they are displayed when they are in the hands of the player. They would have some depth so they wouldn't disappear if you front-face them, and imho they would look pretty amazing already.Linuxdirk wrote:If it prevents THIS from happening I’m fine with whatever it takes …
My guess is that perhaps there's no animation system implemented for wielditem visuals?
- rubenwardy
- Moderator
- Posts: 6978
- Joined: Tue Jun 12, 2012 18:11
- GitHub: rubenwardy
- IRC: rubenwardy
- In-game: rubenwardy
- Location: Bristol, United Kingdom
- Contact:
Re: 0.5.0
The system of extrusion adds lots of faces, which causes an fps reduction.
RealBadAngel did some work on this.
RealBadAngel did some work on this.
Who is online
Users browsing this forum: No registered users and 39 guests