[Coders needed] Colored light sources

[mauvebic]

I personally disagree with hmmm too. I know he cares for things to be coded properly and the right way... but like I told him, if we want to add a feature then we need to add it in the best way *possible*, even if overall that might not be the best way (my own opinion). He doesn't like how we'd be using 3 more bits in the mapgen to store light I think, but I see no major problem with that.

That leaves you with 3 options im aware of:

A) Find the better way. That probably involves recruiting help from the outside - might be worth poking around a few indie game forums.

B) Issue a patch. Which would work for me personally, as far as gaming goes.

C) Fork. Which i dont think is worth it for one feature.

A viable fork would likely be one that does away entirely with the constraints of operating on old hardware - a minetest for modern rigs.

[PilzAdam]

And i dont wanna waste time putting together a pull just to get the prestidigitator treatment.

The problem with prestidigitator was that he had coded everything on his own without talking to us.
If he had talked to hmmmm earlier, then he problably wouldnt have wasted so much work.

[mauvebic]

And i dont wanna waste time putting together a pull just to get the prestidigitator treatment.

The problem with prestidigitator was that he had coded everything on his own without talking to us.
If he had talked to hmmmm earlier, then he problably wouldnt have wasted so much work.

I somehow get the feeling it would just have afforded him the opportunity to say no sooner. In this case we did discuss it before going down any particular path, and he still flatly rejected the idea, without offering any alternatives or compromises. I would be pleased to be proven wrong on this.

[4aiman]

And i dont wanna waste time putting together a pull just to get the prestidigitator treatment.

The problem with prestidigitator was that he had coded everything on his own without talking to us.
If he had talked to hmmmm earlier, then he problably wouldnt have wasted so much work.

The problem is every time someone wants something, one of the core devs or major contributors or just a moderator mocks he/she and say that he/she should code it on their own.
So why bother talking to any of mentioned earlier people if you already know what they would say?
Personally I heard things that meant this:
- Go code yourself.
- Do not bitch about this feature - we'll never code this just for you and a hundred or two end-users who desperately want this, cause: 1) we don't like this; 2) there're thousands who don't care a bit about this feature get added; 3) if you still want - then fork MT and maybe we'll be so generous to accept this after some time... if your code's good enough for us... so, see point (1).
- It's a no. Discussed to death. So do not even try. No matter Lua is slow.
- Why?? (Like always, "why" instead of "why not try if it doesn't kill performance?")
- No, we won't code this, and even if you'll code we won't add.
etc.

So either one who got likewise comments does nothing or does in a secret (hoping his/her work will be noticed and merged).
The fact prestidigitator wanted to make a "gift" to Minetest community by releasing ready-to-use features doesn't crossed hmmmm's mind, does it?

It seems that core devs can't decide whether they DO trust people and make a community project or they do not.
If there are some strategy for adding features then post in on WIKI. And show to everyone who want smth different.
Make some rules if you ought to. But don't use random yes/no attitude from a single person as one of that rules.

Attention, all moderators and contributors!
Once you'll spot some new idea in feature discussion and decide to implement it on IRC, MAKE A NOTE ON WIKI!
Once you'll spot some new idea in feature discussion and decide NOT to implement it on IRC, MAKE A NOTE ON WIKI!
That will save a lot of nerves to you and to people who want to add smth.
Once someone read that a certain feature is NOT welcome- he/she will make a fork or shut up.
Once someone read that a certain feature IS welcome - he/she will make a fork or shut up.
We all will know how to behave if we'll have a guideline which will tell us what to expect from core devs team and what is a tabu/veto or simply forever forbidden.
No one can stop mods from appearing, but engine features should have that guideline.
Please, STOP this random development and this random attitude!

PS: We definitely need a "participate in a poll or be not able to enter MT forums" feature. So every active member of the community WILL answer whether he/she wants to add a feature that already have been coded or not. 1 poll per 24 hours. GMT +0. Also an announcement of the next poll in the current one and through RSS. Public log of results with a link in the main menu at forums and in the main menu of the home page.

And if he bans me, so what? This is a COMMUNITY BASED GAME.

[PilzAdam]

I dont see the point in adding such a list in the wiki. All development of Minetest is discussed in IRC. If people are not or only sometimes in IRC (like prestidigitator) they cant participate in development correctly.

Communication is the key. If you have a feature suggestion, tell us in #minetest or in the forum.
If you have a feature suggestion and are able/willing to code it, contact core developers in #minetest-dev.

Personally, I often play arround with the code. When Im done with something, I ask other core devs what they think. If they say "no" (e.g. https://github.com/PilzAdam/minetest/tree/fencelike), then Im not frustrated and quit the development.
But for big features, I always talk to others first before I start coding, to not waste my time.
Other people should do that too.

And for people who want to suggest features: Please expect a "no" or "if you code it" answer.
There are way more people that suggest features than actual coders. We cant code every feature request. There are other, maybe more important things to do. Its simply not possible that the few core devs code every random idea of every user in this forum.
We also need to think about Minetest as a game. We cant throw every single features in. We have to decide wich features are good for what we think where Minetest should go. All the core devs have somewhat the same idea what Minetest should be.

To sum it up a bit: Features will be addded if:
1) At least 2 core devs agree on it and no other core dev objects.
2) Either the one who suggested the feature or one core dev codes it. Note that the feature has to be very good/important for the latter one to happen.
3) The code for the feature is good / suits Minetests code guidelines.

For the colored light: 2) and 3) seems to be the problem.

[Traxie21]

I'd have to agree with 4aiman entirely. Adam, some people avoid IRC like hmmm avoids the forums. IRC is not a good place to 'store' important information and guidelines.

When I'm on IRC and coding at the same time, I get easily distracted due to my tendancy to talk.

[Casimir]

All development of Minetest is discussed in IRC. If people are not or only sometimes in IRC (like prestidigitator) they cant participate in development correctly.

Fascinating. You are able to verbalize the problem but you don't understand it.

[PilzAdam]

All development of Minetest is discussed in IRC. If people are not or only sometimes in IRC (like prestidigitator) they cant participate in development correctly.

Fascinating. You are able to verbalize the problem but you don't understand it.

You have to live with that. You have to be in IRC to develop Minetest's core properly, like you have to know c++.

[hmmmm]

I personally disagree with hmmm too. I know he cares for things to be coded properly and the right way... but like I told him, if we want to add a feature then we need to add it in the best way *possible*, even if overall that might not be the best way (my own opinion). He doesn't like how we'd be using 3 more bits in the mapgen to store light I think, but I see no major problem with that.

We are definitely _not_ doubling the size of a MapNode. There are better ways of accomplishing the same thing which don't require doing this and modifying half the codebase - just because you can't figure out how to do hardware lighting effectively, doesn't mean somebody else can't come along and find a way to make it work. Again, there is *NO HARM* in maintaining your own fork for such a radical change like this.
Getting all upset over this is pretty senseless.

[mauvebic]

2) Either the one who suggested the feature or one core dev codes it. Note that the feature has to be very good/important for the latter one to happen.
3) The code for the feature is good / suits Minetests code guidelines.

For the colored light: 2) and 3) seems to be the problem.

Re :
2) When we try to code it, were told the idea is no good and it wont get pulled, before having seen any code. Which gives me the impression ya'll don't want us to code it. When we discuss how to code, were told such things as "you all talk like you're solving some sort of problem" so, instant roadblock. I guess the only acceptable outcome is one where a core dev codes it.

3) code guidelines don't apply yet because were never allowed to get that far. The feature does seem important as a majority of users and moderators polled are in favor of it. It's no more out of place than nodeboxes or entity attach. It's also a feature you can get in Minecraft, which is usually enough for many including yourself.

[PilzAdam]

The problem with the colored light is that it will double the size of a MapNode if its not done with hardware lighting.

[mauvebic]

We are definitely _not_ doubling the size of a MapNode. There are better ways of accomplishing the same thing which don't require doing this and modifying half the codebase

But you refuse to elaborate your solution to this. It's somewhat frustrating since we don't want to place the burden of coding it on people who don't want to or might not have the time, which is entirely understandable. So we're left with the one bad solution, and no progress is being made.

just because you can't figure out how to do hardware lighting effectively, doesn't mean somebody else can't come along and find a way to make it work. Again, there is *NO HARM* in maintaining your own fork for such a radical change like this.
Getting all upset over this is pretty senseless.

I'm all for hardware lighting, and i am looking for outsiders to help with either feature. Whether or not it's radical, from the POV of the code perhaps, but to playing members, it's one of many desirable features. Forking seems to me to be just as extreme as getting upset over it.


Aside, this forum could use multi-quote.

[mauvebic]

The problem with the colored light is that it will double the size of a MapNode if its not done with hardware lighting.

The problem seems be somewhat a moving target.

So given a full range of colors (not obligatory) its 3x

8 Bits - byte - range 0-255

What if the range for each value (r,g,b) was 0-25, or even 0-5, would that take up much space?

Perhaps the question is whether the proper solution is hardware lighting, or reducing the size/range of possible values.

[Inocudom]

I don't know if this will help, but maybe there are folks at PureZC and Mod The Sims that can help.
http://us.yhs4.search.yahoo.com/r/_ylt=A0oG7qcD4XJRhBsA965jmolQ;_ylu=X3oDMTBybnZlZnRlBHNlYwNzcgRwb3MDMQRjb2xvA2FjMgR2dGlkAw--/SIG=11a59t8fg/EXP=1366512003/**http%3a//www.purezc.com/
http://us.yhs4.search.yahoo.com/r/_ylt=A0oG7qcm4XJRj3sAu3RjmolQ;_ylu=X3oDMTBybnZlZnRlBHNlYwNzcgRwb3MDMQRjb2xvA2FjMgR2dGlkAw--/SIG=11fel19hj/EXP=1366512038/**http%3a//www.modthesims.info/

[4aiman]

I have one simple (yet nice) question to those who want a better solution. How light colour should be saved?

It's not about hardware lightening, it's all about size. So I prepared auxiliary questions:
Anyone who against this, can any of you actually guide us to the right side?
Or you just know that's not the way it should be, because it's not the way it should be?

Remember:
I'm not asking of you any code.
I'm not trying to make anyone code it. No.

Arguments against is well-known. But we still need to store colour somewhere and be able to read it fast.

[PilzAdam]

I have one simple (yet nice) question to those who want a better solution. How light colour should be saved?

It's not about hardware lightening, it's all about size. So I prepared auxiliary questions:
Anyone who against this, can any of you actually guide us to the right side?
Or you just know that's not the way it should be, because it's not the way it should be?

Remember:
I'm not asking of you any code.
I'm not trying to make anyone code it. No.

Arguments against is well-known. But we still need to store colour somewhere and be able to read it fast.

What you are now doing is exactly what you should do: Talk to others about what the code should look like.
If somone would just come up with the double MapNode size code, then it wouldnt be merged and everyone would be unhappy.
But if you talk about the code first, then you avoid this. prestidigitator had not done this, he just came up with his code.

[mauvebic]

What you are now doing is exactly what you should do: Talk to others about what the code should look like.
If somone would just come up with the double MapNode size code, then it wouldnt be merged and everyone would be unhappy.
But if you talk about the code first, then you avoid this. prestidigitator had not done this, he just came up with his code.

We are perfectly willing to do so, i just wish the naysayers would elaborate on the solutions they claim to know rather than leaving us guessing.

[4aiman]

Adam, so, you don't know either... What about Hmmmm? Or I should go to IRC to receive his answer? And celeron said core team isn't distant thing.

mauvebic, perfectly my point.

[PilzAdam]

#minetest-dev is definetly a better place to discuss this.

We are perfectly willing to do so, i just wish the naysayers would elaborate on the solutions they claim to know rather than leaving us guessing.

Hmmmm already said what he thinks is the solution: hardware lighting.

[mauvebic]

#minetest-dev is definetly a better place to discuss this.

We are perfectly willing to do so, i just wish the naysayers would elaborate on the solutions they claim to know rather than leaving us guessing.

Hmmmm already said what he thinks is the solution: hardware lighting.

That's news to me, and definately more open-ended than the response we got on IRC.

[PilzAdam]

Well, I admit that hmmmm tends to overreact when telling people that their features wont be merged / coded.
Maybe thats due to the massive flood of suggestions / pull requests the core dev team has to deal with.

[Jordach]

There's a reason why I haven't gone into development.

It's these random bullshit rules you have to follow. And for once, I agree with RealBadAngel:

<PilzAdam> see? you break compatibility
<RealBadAngel> see? we are DEVELOPING the game
<RealBadAngel> not maintainin national museum of minetest :P

PilzAdam and the like dislike new coders as they won't follow the code guidelines; but WHO GIVES a SINGLE FLYING FUCK about the code; provided it works, it works, why bitch and moan when in the future it becomes a major feature. Also: if the code is not to your liking: clean the code yourself.

BlockPlanet intergrated nodeboxes, nodemeta and Formspecs WAY BEFORE Minetest went 0.4.x, yet, nothing got merged. It even had physics. Just because the devs were lazy cunts about it.

And this comes to a problem: the devs half ass everything.

[mauvebic]

Well, I admit that hmmmm tends to overreact when telling people that their features wont be merged / coded.
Maybe thats due to the massive flood of suggestions / pull requests the core dev team has to deal with.

So it's our fault good ideas get tossed out with the bad? I can't accept that. If that truly is the problem, then we need some sort of setup/guidelines for the triage of suggestions.

[mauvebic]

WHO GIVES a SINGLE FLYING FUCK about the code; provided it works, it works, why bitch and moan when in the future it becomes a major feature.

That is one of the points, I can't rely on what I find on the irrlicht forums since our lighting system isn't at all how those guys intended their lighting to be used. But now, colored lighting breaks some sort of self-imposed convention.

[Inocudom]

It is a sad truth, but I have seen in my life time and time again the destruction of ideas and improvements that were beautiful. That is why I am never optimistic about anything at all. Ever. The coders and supporters of hardware lighting and colored light-rays must keep trying if they want their goal to see the light of day. To everyone that reads this, consider the possibilities before concluding that such features are not worthwhile. People always need to consider possibilities, possibilities, possibilities.

I recently made a post in a topic on PureZC about the implementation of hardware lighting and colored light-rays. The link to that topic is below.
http://www.purezc.com/forums/index.php?showtopic=57000
I need at least one member of this community to post a reply in that topic. If you are already registered with PureZC, that should be a simple task. Simply post about how hardware lighting and colored light-rays would be beneficial to the game Minetest and see if anyone there can help the cause. Consider my posting at PureZC an attempt at calling in aid from the outside world. I believe that there are a few skilled programmers there.

[12Me21]

It seems like torch light is yellow and sunlight is blue in default minetest, is that actually true or is it just an optical illusion?

The way I figured that out was when I was mining deep underground and I had a strait mineshaft down to the cave I was in, so the sunlight would shine down into the area I was mining, and the way I got back to the mineshaft after exploring the cave was I looked for a blue-ish area.
One thing that should be fixed is the fact that sunlight can travel an infinite distance through a hole in the ground, which is not realistic.

[12Me21]

It is a sad truth, but I have seen in my life time and time again the destruction of ideas and improvements that were beautiful. That is why I am never optimistic about anything at all. Ever. The coders and supporters of hardware lighting and colored light-rays must keep trying if they want their goal to see the light of day. To everyone that reads this, consider the possibilities before concluding that such features are not worthwhile. People always need to consider possibilities, possibilities, possibilities...

What about having lightstones in mesecons emit colored light?

[mauvebic]

I caved, installed windows and bought blockscape, so i'm done here.

[Neuromancer]

I caved, installed windows and bought blockscape, so i'm done here.

I like both Blockscape and Minetest. Blockscape lets you create really realistic things, and the new snapshot brings insane realism to the terrain, but I like the gameplay and performance of Minetest better. What's your username on Blockscape forums? I'd like to keep my eye out for some of the stuff you create there.

[mauvebic]

I caved, installed windows and bought blockscape, so i'm done here.

I like both Blockscape and Minetest. Blockscape lets you create really realistic things, and the new snapshot brings insane realism to the terrain, but I like the gameplay and performance of Minetest better. What's your username on Blockscape forums? I'd like to keep my eye out for some of the stuff you create there.

I wasn't able to run the latest snapshot - though the stable version seems to perform better on win7 than MT on arch, as for gameplay, i'm still getting used to the much smaller blocks and different shapes :p Though what i like most is the positive attitude there. I use the same handle on those forums though i haven't posted anything yet - the link in my sig has a gallery of all the stuff i created in both games - tho with zimg down, and my linux partition temporarily cut-off, i haven't had a chance to re-upload pics of my last mt projects (ships and ocean liners).