| Time |
Nick |
Message |
| 00:09 |
|
kaeza joined #minetest-dev |
| 01:25 |
|
iqualfragile joined #minetest-dev |
| 02:19 |
|
Naked joined #minetest-dev |
| 04:53 |
|
RealBadAngel joined #minetest-dev |
| 05:03 |
|
ecube joined #minetest-dev |
| 05:47 |
|
salamanderrake joined #minetest-dev |
| 06:37 |
|
neko259 joined #minetest-dev |
| 07:39 |
|
Calinou joined #minetest-dev |
| 08:01 |
|
darkrose joined #minetest-dev |
| 08:01 |
|
darkrose joined #minetest-dev |
| 08:22 |
|
Taoki joined #minetest-dev |
| 08:32 |
|
Jordach joined #minetest-dev |
| 08:52 |
|
sapier joined #minetest-dev |
| 09:00 |
sapier |
hmmm I've got some ideas to get mobf even faster but as there's conflict about movement mechanism to use I'm not sure if they ever will be added. Basicaly there are two ways to do movement |
| 09:00 |
sapier |
1) velocity/path based (with optional client side smoothing in path mode) --> simple mobs uses velocity |
| 09:00 |
sapier |
2) acceleration based (client already does prediction) --> mobf |
| 09:00 |
sapier |
both have advantages and dissadvantages |
| 09:01 |
Jordach |
disadvantages for 1 |
| 09:01 |
sapier |
first one for example is more usefull if a mob tries to get to a special location while second one is very good to get a random movement |
| 09:01 |
sapier |
disadvatages for one is you can't get smooth movement if you don't use paths while you will get outdated movement if you use paths |
| 09:04 |
sapier |
you should consider most mobs beeing in random move mode almost 100% of time |
| 09:06 |
sapier |
and of course you could combine acceleration with paths too ... it'd just get even more complex ;-) |
| 09:07 |
Jordach |
minecraft uses a acceleration system |
| 09:07 |
Jordach |
as if youre running from a creeper, they have smooth turns like a vector |
| 09:08 |
sapier |
jordach I already added a pull request that'd make same in minetest ... its about half a year old |
| 09:09 |
sapier |
but as long as pilzadam and me didn't agree for a movement mechanism patches improoving acceleration based movement aren't added that fast ;-) |
| 09:09 |
sapier |
-didn't + don't |
| 09:43 |
proller |
sapier, add players number to serverlist please! |
| 09:49 |
sapier |
vanessae already complained about the flags so I don't think it'll get better if I add playernumber too ... we need to find a better way to show that information |
| 09:51 |
|
adc_ joined #minetest-dev |
| 09:59 |
proller |
players number is most important |
| 09:59 |
proller |
it was before formspec without problem |
| 09:59 |
proller |
FLAGS 5/100 server namee e e ee ee |
| 10:07 |
Taoki |
sapier: I support the movement wat which allows for least lag and most normal movement. Since currently that's what I found to be the biggest issue with mobs in Simple Mobs at least |
| 10:07 |
Taoki |
I don't use mobf cuz the default animals don't have such nice models. simplemobs has artistically accurate animals |
| 10:07 |
Taoki |
I should try the other one too though |
| 10:08 |
Taoki |
Acceleration based sounds a bit better though. Should be more realistic movenent |
| 10:16 |
Taoki |
I also think mobf has excessive items and such. Like vombie trap, net, etc. Those would be too much for default IMO |
| 10:23 |
sapier |
mobf is a framework, any mob is a single mod |
| 10:23 |
sapier |
so by default mobf has not any item ... except of path marker |
| 10:24 |
sapier |
and lag is an issue for all movement styles ... depends on current situation which one will "hide" the effects of lag better ... I don't think either one is better in general |
| 10:25 |
sapier |
proller indention issue is even worse for player numbers as they don't even have a fixed digit count |
| 10:26 |
sapier |
maybe font used before is different than now |
| 10:26 |
proller |
but server list without players - its stupid and useless |
| 10:26 |
proller |
add witout identation, then think how to fix |
| 10:28 |
sapier |
already did that for flags and got complains, until this is fixed I won't make it worse by a single request ... I always have to add additional features to fix issues added by a request of a single person ... if you manage to gett supporters I gladly add it but as long as its 1:1 I don't add it |
| 10:29 |
proller |
it was before your changes |
| 10:29 |
proller |
you broke it |
| 10:29 |
sapier |
and now it isn't. |
| 10:29 |
proller |
then add it now |
| 10:29 |
sapier |
I never intended to create a 100% identical replacement but provide a base for custom changes |
| 10:30 |
sapier |
and I told that from begining if you want this feature then add it and fix all issues resulting from your changes |
| 10:30 |
Taoki |
Trying mobf now. Focusing on the system though |
| 10:30 |
Calinou |
inb4 crash |
| 10:30 |
Taoki |
The most huge issue of mobs imo is the lack of angle smoothing. Which is also an issue for players and of course all lua entities |
| 10:30 |
Taoki |
Why do we have movement smoothing but no angle smoothing yet? |
| 10:31 |
sapier |
taoki there's a pull request |
| 10:31 |
Taoki |
What's the link? And why isn't it in yet? |
| 10:31 |
proller |
sapier, identation - its not issue |
| 10:31 |
sapier |
proller it is ask vanessae |
| 10:31 |
proller |
VanessaE, !!! |
| 10:33 |
sapier |
taoki https://github.com/minetest/minetest/pull/418 |
| 10:33 |
Taoki |
thanks |
| 10:33 |
Calinou |
Taoki: I tried doing angle smoothing once, and epicly failed 8) |
| 10:33 |
* Calinou |
would like to see entity pitch too |
| 10:33 |
sapier |
but I don't know if it aplies cleanly I last rebased it in may |
| 10:33 |
Calinou |
and a visual representation of pitch |
| 10:33 |
Calinou |
(rotate model by 25% of pitch?) |
| 10:33 |
Taoki |
Angle smoothing is needed for players too a lot |
| 10:33 |
Calinou |
yes |
| 10:34 |
Calinou |
try coding it, you're probably better at C++ than me :P |
| 10:36 |
Taoki |
It will probably be put on hold for months like my fog color is, so I feel a bit less motivated to work on code now |
| 10:36 |
Calinou |
le "just now" comment |
| 10:38 |
sapier |
taoki I'm not sure if current mobf version uses the automatic rotating completely as the lua style rotation needs to be disabled to get full benefit of automation |
| 10:38 |
sapier |
and I can't diable lua rotation while the patch isn't added |
| 10:38 |
Taoki |
sapier: The code isn't in so it can't use it |
| 10:39 |
Taoki |
Even Lua rotation would look good however, if only there was angle smoothing in >.< |
| 10:39 |
Calinou |
it's probably easy to do |
| 10:39 |
Taoki |
And no one did it for years :P I need to do other things since I'll be away soon, so can't really look into it now |
| 10:39 |
sapier |
in most cases you don't need smooting a cow for example looks into their movement direction 99% of time ;-) |
| 10:40 |
Calinou |
Taoki: this is FOSS 8) |
| 10:40 |
Calinou |
noone does anything for years |
| 10:40 |
Taoki |
heh |
| 10:40 |
Calinou |
sapier: you do |
| 10:40 |
sapier |
what shall I do? |
| 10:44 |
Taoki |
Uh... even vombies lag all over the place in singleplayer :( |
| 10:44 |
sapier |
vombies are agressive animals those require a lot of cpu power |
| 10:45 |
sapier |
did you try with current git or 0.4.7? |
| 10:45 |
Taoki |
I wonder if for movement we could add a direct data stream system. And only leave tcp packets for one-time things |
| 10:45 |
Taoki |
That would be of most help |
| 10:46 |
sapier |
mobf is only tested against 0.4.7 don't know if git added regressions |
| 10:47 |
Taoki |
le server crash in singleplaer (prolly vombies, everything just stopped working) |
| 10:47 |
Taoki |
yah, can't even shut it down, prolly gotta kill the process |
| 10:47 |
sapier |
yes I know there's a bug in 0.4.7 stopping agressive animals from work at all |
| 10:48 |
Taoki |
And minetest is stuck at 13% CPU usage |
| 10:48 |
Calinou |
Taoki: tip: hyperthreading fakes CPU usage |
| 10:48 |
Taoki |
And about 800 MB of ram |
| 10:48 |
Calinou |
you should double it to get "actual" CPU usage |
| 10:48 |
Calinou |
if you use HT |
| 10:48 |
Taoki |
ok, then 26% :P |
| 10:48 |
Calinou |
you use HT? |
| 10:48 |
sapier |
doesn't change situation ;-) |
| 10:48 |
Taoki |
yeah, had to kill minetest |
| 10:48 |
Taoki |
mob framework is not even SAFE >.< |
| 10:49 |
sapier |
no it's as safe as it can be with core bugs causing a crash ;-P |
| 10:49 |
sapier |
I already workaround lots of core bugs sorry for missing one |
| 10:49 |
Calinou |
for work |
| 10:50 |
Calinou |
ITT: mobf is NSFW |
| 10:50 |
sapier |
guys stop complaining and report errors |
| 10:51 |
sapier |
and by reporting errors I don't speak about "it's slow" and "it doesn't" work .... especialy if after days of investigation result is that some other mod you happened to install same time skrewed up |
| 10:53 |
sapier |
mobf has lot's of features I ain't capable of achieving 100% feature test on my own anymore if there won't be help it's most likely gonna die some time in future |
| 10:53 |
sapier |
at least if I have to fight against mobf haters same time :-P |
| 10:56 |
Taoki |
Yeah. I can quickly tell Simple Mobs is SO much more consistent and even realistic (only except movement) |
| 10:56 |
Taoki |
And way less intensive |
| 10:56 |
sapier |
ok so simplemobs is consistend except of MAIN feature? |
| 10:57 |
Taoki |
It seems to be less intensive and even locally, less laggy |
| 10:57 |
sapier |
it IS less intensive as working around that glitches sm has requires cpu power |
| 10:57 |
sapier |
this is wash me but don't get me wet argument taoki |
| 10:58 |
Taoki |
hmm? |
| 10:58 |
sapier |
mobf checks for all that invalid movement states that occur in sm ... checking can't be done without using cpu |
| 10:59 |
sapier |
therefore mobf does require more cpu power |
| 10:59 |
Taoki |
ok |
| 11:00 |
Taoki |
I still tend to like it more currently. Just think movement and collision detection needs some improving though |
| 11:00 |
sapier |
if you improove simple mobs in that areas you end up at mobf |
| 11:00 |
sapier |
because that are the main (performance) differences |
| 11:01 |
Taoki |
hmm... |
| 11:01 |
sapier |
second main difference is sm requries any mob to implement same functions over and over again while mobf already contains it |
| 11:01 |
sapier |
so if I fix a bug it's fixed for ALL mobs |
| 11:01 |
Taoki |
prolly some architecture difference too. Mob defnitions seem a little easier to understand in simple mobs. Not saying mobf is bad though... surely both are good |
| 11:01 |
* Taoki |
nods |
| 11:02 |
sapier |
yes they are more easy as things you have to implement in sm can just be enabled by definition in mobf |
| 11:02 |
Taoki |
Ah, and I forgot you're the owner of mobf >.< Yeah, I'm not saying yours is bad that's for sure. Just thinking which seems to be most usable at this point |
| 11:03 |
sapier |
it's like deciding between a prototype not implementing challanging features to a full blown implementation needing bugfixing |
| 11:03 |
Taoki |
Sadly, I have to admit that mobf just crashed minetest earlier (had to kill the process) and got it stuck at 13% CPU usage + 600 MB of RAM. Which of course happens... nothing can be fully stable nd all, but just reporting it |
| 11:04 |
sapier |
mobf is in no state to be merged to core of course |
| 11:04 |
Taoki |
With simple mobs I seem to be at 11% CPU too, but (not sure if related) about 200MB of ram only |
| 11:04 |
sapier |
how much mobs are implemented in sm and mobf? |
| 11:04 |
sapier |
you need to compare same things taoki |
| 11:05 |
Taoki |
SM has fewer mobs, MOBF more. I do compare at the same quantity of existing surrounding mobs though |
| 11:05 |
proller |
meeelting https://github.com/proller/minetest/compare/master...weather |
| 11:06 |
sapier |
which isn't very accurate as it depends on what type of mob is around too |
| 11:07 |
sapier |
50 sheep for example are way less cpu consuming than 25 vombies wolfs or archers |
| 11:07 |
Taoki |
yeah |
| 11:07 |
sapier |
this results primary by sheep don't attack player thus don't need to look for players around them |
| 11:08 |
Taoki |
sapier: BTW. Are you considering making a version of MOBF with the mobs in SM? Mostly the same models and perhpas different functionality. |
| 11:08 |
Taoki |
True too yes |
| 11:08 |
Taoki |
I need to test the aggressibe mobs in SM |
| 11:08 |
Taoki |
But can't find any |
| 11:08 |
sapier |
call mobf_settings you can disable them by checkbox |
| 11:08 |
Taoki |
There are some sand monsters but they're being nice >.< |
| 11:08 |
sapier |
I don't see any benefit of removing mobs if it's that easy to disable ... the model thing is on my list yes |
| 11:09 |
Taoki |
ok. Will mob definitions from SM work in MOBF? |
| 11:10 |
Taoki |
Noticed a little something else: In SM mobs can jump to bet up blocks. In MOBF they just appear a step higher (same issue in Minecraft IIRC) |
| 11:10 |
sapier |
no they never will work |
| 11:10 |
Taoki |
ok |
| 11:11 |
sapier |
it's completely different |
| 11:11 |
sapier |
mobf definition for most sm's is way more simple in mobf |
| 11:12 |
Taoki |
Trying to get something to attack me in sm but no mobs are |
| 11:12 |
sapier |
jumping up is difficult but possible |
| 11:13 |
sapier |
no not difficult .. but require additional cpu power again :-) |
| 11:13 |
Taoki |
Anyway, I hope my test pointed out one of the bugs. mobf can crash the server with latest Minetest GIT, so something goes wrong |
| 11:13 |
sapier |
a mob needs to decide if it wil be able to reach the block above by calculating it's distance acceleration andvelocity |
| 11:14 |
sapier |
hmm latest git you say? mobf is 0.4.7 only atm but I guess I need to fix that issue for 0.4.8 anyway :-) |
| 11:15 |
sapier |
did you do anything special to crash it? |
| 11:15 |
Taoki |
Also having mobf from git |
| 11:15 |
|
PilzAdam joined #minetest-dev |
| 11:15 |
Taoki |
sapier: No. Just walking around with 4-5 vombies around me |
| 11:15 |
Taoki |
Then suddenly, all fell to silence |
| 11:15 |
sapier |
hmm I wonder if that bug in 0.4.7 isn't fixed in core yet |
| 11:16 |
sapier |
but I need to complete mainmenu first |
| 11:19 |
Taoki |
sapier: Well a bunch of sand monsters are attacking me in sm. No intensivness however |
| 11:19 |
sapier |
I guess pilzadam did completely different agressive handling |
| 11:19 |
Taoki |
The way they're running after me is also very good looking |
| 11:20 |
Taoki |
But again I'm not saying your mod is bad :( You did a nice work on mobf too |
| 11:20 |
sapier |
did you try what happens while different player attack sandmonsters? |
| 11:20 |
sapier |
or you have a sibling attacking sandmonsters along with you? |
| 11:20 |
Taoki |
Trying in singleplayer now, no one else to test with |
| 11:20 |
sapier |
I don't think sm is prepared for this |
| 11:21 |
sapier |
I know you can do attacking very simple ... maybe mobf just checks "too much" and players are completely ok with the glitches that occur that way |
| 11:22 |
sapier |
or maybe there are even major bugs in |
| 11:22 |
Taoki |
Well... barely and CPU usage or memory usage or slowness with 2 sand monsters attacking me |
| 11:23 |
sapier |
I'll have a look what pilzadam does there but fighting is quite advanced in mobf ... I guess sm does the basic thing I added first ... about a year ago |
| 11:24 |
Taoki |
True. The intensivness in mobf is likely because it's more advanced indeed |
| 11:24 |
PilzAdam |
sapier, it always attacks the nearest player |
| 11:24 |
sapier |
so most simple way as I guessed |
| 11:24 |
Taoki |
3 sound monsters now. minetest is barely using any resources :P |
| 11:25 |
sapier |
mobf doesn't stop attacking a player once it started attacj |
| 11:25 |
sapier |
unless player runs away to far |
| 11:25 |
Taoki |
But yeah... if any system is to be added to builtin, I am in favor of sm. Mobf can be very useful too for anything that needs more complexity, so it would not be useless |
| 11:25 |
sapier |
latest version even usses aggro to decide whom to attack |
| 11:25 |
* Taoki |
would feel bad if mobf got lost, since sapier prolly put a lot of work into it too |
| 11:26 |
sapier |
if sm was added I'm gonna drop mobf as it'd be wasted time to continue |
| 11:26 |
Taoki |
That would suck :< |
| 11:26 |
sapier |
this is not a threat but just a consequence |
| 11:27 |
Taoki |
I wonder if there's any way to slowly improve sm with code from mobf, and perhaps get to a merge between the two mobs. That results in simplest but also most complete functionality |
| 11:27 |
sapier |
mobf never ever will have a chance against a in core mob implementation |
| 11:27 |
Taoki |
I know, it makes sense |
| 11:27 |
Jordach |
or: move mob ai to core |
| 11:27 |
sapier |
it'd end up at mobf complexity |
| 11:27 |
Jordach |
problem solved, and have extra stuff inbetween |
| 11:27 |
sapier |
with exactly same issues |
| 11:28 |
Taoki |
I think mobf features could slowly be moved over to sm. Testing each one for how much resource usage it adds and how well it works |
| 11:28 |
sapier |
and of course you understand I'd not be very glad with "simple mobs by pilzadam" while all the challanging issues are taken by mobf ;-P |
| 11:28 |
Taoki |
I am curious though: What extra feature does mobf has over sm? Without looking at the code, I se ethe same detail in both. Including how mobs attack me |
| 11:28 |
Taoki |
sapier: I know. I'd feel bad if your work got lost... I know how I'd feel if that happened to me :( |
| 11:29 |
PilzAdam |
Jordach, ok, then please write the API (not the code, but the docs) for it |
| 11:29 |
sapier |
collision detection, movement prediction, drop prevention |
| 11:29 |
sapier |
siblings |
| 11:29 |
sapier |
ridable mobs |
| 11:29 |
Jordach |
PilzAdam, i can do that in a day |
| 11:29 |
PilzAdam |
Jordach, go ahead |
| 11:29 |
sapier |
guards |
| 11:29 |
sapier |
patrol mode |
| 11:29 |
Jordach |
sapier, scale the model down then up again |
| 11:29 |
Taoki |
nice. Lack of collision detection is what I dislike most in smobs |
| 11:29 |
sapier |
yes can be done in mobf too |
| 11:29 |
PilzAdam |
sapier, movememnt prediction cant be done without client side changes |
| 11:30 |
sapier |
it can |
| 11:30 |
Taoki |
What's movement prediction do exactly? And what does drop prevention mean? |
| 11:30 |
PilzAdam |
and collision detection is builtin in core.... |
| 11:30 |
sapier |
acceleration is predicted by client |
| 11:30 |
Taoki |
oh |
| 11:30 |
sapier |
collision detection is done within mobf to decide where to reroute a mob too |
| 11:30 |
PilzAdam |
no, not acceleration, velocity is predicted based on acceleration |
| 11:31 |
sapier |
drop prevention means a mobf mob won't drop into water for example |
| 11:31 |
sapier |
flying mobs |
| 11:31 |
sapier |
fish |
| 11:31 |
Taoki |
Well again, I really don't want to make you feel bad about mobf >.< But those sound like they can be added to smobs easily too. Possibly in a not so intensive way |
| 11:31 |
PilzAdam |
acceleration always stays the same until you get a new package from the server |
| 11:31 |
Taoki |
smobs doesn't have flying and fish? |
| 11:31 |
Taoki |
Ah, so not falling off cliffs and stuff |
| 11:32 |
Taoki |
PilzAdam: We really need angle smoothing, the same way we have position smoothing. For both players and mobs |
| 11:32 |
sapier |
taoki yes once work has been done what to do some features can be added ... others won't be possible as design doesn't match |
| 11:32 |
Taoki |
I don't get why in years it wasn't added, since it should be pretty basic :P |
| 11:34 |
Taoki |
PilzAdam: When could collision detection be added in simple mobs? In a simple way of course (since that's the point of SIMPLE mobs) but enough to keep them from blindly going into walls. Also perhaps drop avoidance, sop they don't jump off cliffs like fools |
| 11:34 |
sapier |
and no I won't help developing sm just because its a core developer mod |
| 11:34 |
PilzAdam |
Taoki, the collisiondetectioin is built-in in the core |
| 11:34 |
Taoki |
sapier: I don't like or dislike it because it was made by a core dev, that has no influence on me. I just... like the design more I guess |
| 11:35 |
Taoki |
PilzAdam: Ah, so it already should work? Last time I saw a sheep pushing int a wall |
| 11:35 |
Taoki |
Or maybe sm doesn't use this builtin option yet |
| 11:35 |
PilzAdam |
they dont go through the wall, thats collission detection |
| 11:35 |
sapier |
Taoki you like the designe because it's still simple due to lack of features |
| 11:35 |
Taoki |
ok, maybe I saw an older version then |
| 11:35 |
sapier |
what you're talking about Taoki is collision prediction not detection |
| 11:36 |
Taoki |
sapier: Truth is I don't feel a lack of features in practive between mobf and smobs. Both seem to have the same features. Again, from what I can feel without knowing the code |
| 11:36 |
Taoki |
In both mobs roam around, in both they attack, etc |
| 11:36 |
sapier |
Yes you don't feel it because it's the minor glitches that cause 99% of work |
| 11:37 |
Taoki |
The ONLY differences I noticed is that in mobf, mobs turn around more gradually as they walk, whereas in smobs turning is very stiff (I don't mind though). Also that in smobs mobs jump, whereas in mobf they just appear off higher blocks |
| 11:37 |
sapier |
it's no effort to get mobs running aroud I did this in a day |
| 11:37 |
* Taoki |
nods |
| 11:37 |
Taoki |
Oh yes, and mobf has birds and fish. I don't know if smobs can do those yet |
| 11:38 |
Taoki |
That is indeed a nice thing |
| 11:38 |
PilzAdam |
sapier, I did whole simplemobs in a day |
| 11:38 |
sapier |
I did mind about the stiff movement that's the main reason for acceleration based movement .. if you don't care about it go with sm ... but this issue can't be fixed there |
| 11:38 |
sapier |
PilzAdam you did read mobf first |
| 11:38 |
PilzAdam |
of course not |
| 11:38 |
Taoki |
I meant stiff rotation. But stiff movement is true too; smobs have no acceleration |
| 11:38 |
PilzAdam |
nobody understands your code :-p |
| 11:39 |
Taoki |
PilzAdam: Can acceleration be added as well to smobs? |
| 11:39 |
sapier |
Yes I know you even asked about git access to mobf code before you startet sm |
| 11:39 |
PilzAdam |
oO |
| 11:39 |
sapier |
so don't tell me you didn't look at it |
| 11:39 |
Taoki |
Great... what a nice reason for a dev fight again >_> |
| 11:39 |
* Taoki |
le sigh |
| 11:39 |
sapier |
it's not a fight ;-) |
| 11:39 |
PilzAdam |
I asked you to put it in a repo so its easier to keep it up to date |
| 11:39 |
PilzAdam |
Taoki, :D |
| 11:40 |
sapier |
no acceleration can't be added because sms design doesn't match to it |
| 11:40 |
Taoki |
BTW: Do either of the mods allow spawning mobs with chat commands? |
| 11:40 |
sapier |
both do |
| 11:40 |
Taoki |
nice |
| 11:40 |
Jordach |
/spawnentity mobs:sheep |
| 11:40 |
Taoki |
Just got 5 sand monsters lashing after me lol |
| 11:40 |
PilzAdam |
sapier, can you explain me how mobf uses acceleration? |
| 11:41 |
sapier |
PilzAdam looking at how many mods you cloned you'd created a own mod either way ;-) |
| 11:41 |
sapier |
mobf doen't set velocity but acceleration |
| 11:41 |
Taoki |
haha, 6. Still no extra cpu usage though. I like testing this ^^ |
| 11:42 |
sapier |
to do that in a sane way it periodicaly checks where a mob will be in and adjusts it's acceleration to avoid collisions or drops |
| 11:42 |
PilzAdam |
sapier, and how does that add prediction for moving in a not straight way? |
| 11:42 |
Taoki |
sapier: Truth be told, I am a bit unsure how much acceleration is needed for *mobs*. I mean in real life when you walk, you barely have any noticeable acceleration. You just get up and walk... in less than a second you're running at "chosen speed" ;) |
| 11:42 |
Taoki |
Even if it is a nice addition sure |
| 11:43 |
Taoki |
Acceleration woulkd be useful for large mobs like dragons however |
| 11:43 |
sapier |
actually that "less than a second" matters it's one of those minor issues humans notice and realize as artificial |
| 11:44 |
Taoki |
Well less than half second or so. Though it can be noticeable yeah |
| 11:44 |
Taoki |
PilzAdam: Where could the mobement be changed to acceleration in smobs too? Doesn't what work at all for smobs? |
| 11:44 |
Taoki |
Can't test it now thought since I'll be more busy till I head off in a week |
| 11:45 |
sapier |
it's not enough to acceleration taoki you need to switch handling completely if you don't use velocity anymore |
| 11:45 |
Taoki |
ah |
| 11:46 |
PilzAdam |
sapier, are you going to answer may question? |
| 11:46 |
sapier |
I still try to understand your question ;-) |
| 11:46 |
PilzAdam |
bbl |
| 11:46 |
sapier |
what do you mean wit prediction in a non straight way? |
| 11:47 |
sapier |
if you use acceleration you always get fluent direction changes |
| 11:47 |
|
Calinou joined #minetest-dev |
| 11:48 |
sapier |
unless you use very high acceleration values but that's a problem for other reasons |
| 11:48 |
sapier |
did that answer your question or did I misinterpret it? |
| 11:49 |
Taoki |
sapier: Angle still can't be set fluently yet, sadly |
| 11:50 |
sapier |
I already told an hour ago there is a pull request that will do this |
| 11:50 |
sapier |
I can't do anything against core dev's not adding things |
| 11:50 |
Taoki |
Right, so nothing other than that pull request. ok |
| 11:51 |
sapier |
and maybe a small fix in mobf to disable the workaround in there |
| 12:17 |
proller |
https://github.com/proller/minetest/compare/weather |
| 12:18 |
proller |
PilzAdam, you must say "NOOOO" 8) |
| 12:19 |
proller |
or maybe only 2 commits - https://github.com/proller/minetest/commit/fad2b4e589a863a82196f81ec704484e25a82dea |
| 12:20 |
Exio4 |
can i ask why you change those NoiseParams? |
| 12:20 |
proller |
https://github.com/proller/minetest/commit/6d7daf9b4202d26e88e9bb4b0236911e08541a27 |
| 12:21 |
Exio4 |
and.. other thing |
| 12:21 |
|
sapier joined #minetest-dev |
| 12:22 |
Exio4 |
are you using the C API to wrap back to lua code? |
| 12:23 |
Exio4 |
https://github.com/proller/minetest/commit/6d7daf9b4202d26e88e9bb4b0236911e08541a27#L3R236 |
| 12:24 |
proller |
because heat not used now |
| 12:25 |
proller |
yes, it for dropping torch when ice below melt |
| 12:25 |
Exio4 |
if i understand correctly the code, that can be done inside lua |
| 12:26 |
Exio4 |
https://github.com/proller/minetest/commit/77f7c824025201d811dc923eb8cf03d973f5aba5#L4R306 |
| 12:26 |
Exio4 |
you don't just move a variable from private to public |
| 12:28 |
proller |
Exio4, done what? slow abm? |
| 12:28 |
Exio4 |
is it used directly in the ABM? |
| 12:28 |
proller |
yes, abm must call nodeupdate when melt |
| 12:29 |
|
iqualfragile joined #minetest-dev |
| 12:29 |
proller |
Exio4, why not move? |
| 12:30 |
Exio4 |
well, you are wrapping to lua anyway, i don't think that would matter.. |
| 12:30 |
proller |
but ok. will make get* |
| 12:30 |
Exio4 |
proller: the notation |
| 12:31 |
Exio4 |
proller: something "good" would be changing the code that uses the m_ though |
| 12:32 |
Exio4 |
as that would be a "small" cleanup :P |
| 12:40 |
Taoki |
https://github.com/proller/minetest/commit/77f7c824025201d811dc923eb8cf03d973f5aba5#L4R306 Why would antone HARD-CODE weather types >___< |
| 12:41 |
Taoki |
+ u8 getRain(ServerEnvironment *env, v3s16 p); |
| 12:41 |
Taoki |
+ u8 getSnow(ServerEnvironment *env, v3s16 p); |
| 12:41 |
Taoki |
Totally against if any words like "rain" or "snow" are added to the code. weather should only be defined in Lua IMHO |
| 12:41 |
Taoki |
Only thing I agree should be added for weather to the code is support for sky particles and fog color changes. |
| 12:41 |
Exio4 |
+ n.setContent(n.getContent() == c_water_source ? ndef->getId("default:ice") : ndef->getId("default:snow")); |
| 12:42 |
Exio4 |
+ map->addNodeWithEvent(p, n); |
| 12:42 |
Exio4 |
are you hardcoding ice and snow name |
| 12:42 |
Exio4 |
+s |
| 12:42 |
Taoki |
Even worse IMO |
| 12:44 |
Exio4 |
if the ABM needs to "know that much" about lua, it should be defined in lua, not C++ |
| 12:44 |
Exio4 |
neighbors.insert("default:furnace_active"); |
| 12:44 |
Exio4 |
you are hardcoding a hell lot of nodes |
| 12:47 |
Taoki |
proller: The idea itself is good. But it's very very wrong to hard code nodes at this day when we have the Lua API. Code is aimed at containing mechanics for defining things in Lua. Nodes, weather types (in this case), etc. must be defined in Lua only |
| 12:48 |
Taoki |
So the only thing that IMO should be coded is support for sky particles. And Lua-side fog colors, though those are part of another plan of mine to allow custom skies |
| 12:48 |
proller |
its version 0.001 |
| 12:48 |
proller |
in first i want to make something working |
| 12:49 |
proller |
in second - make some on uglua |
| 12:49 |
Taoki |
Oh, ok. If that's not intended to be final then sure |
| 12:50 |
Taoki |
Idea is, please don't hard code any nodes nor weather types. Just the system to allow weather., Types of weather, their sounds, their particles, their fog color, and all that should be in Lua scripts |
| 13:04 |
PilzAdam |
sapier, I want to compare your system to the one where you send the target pos to the client |
| 13:06 |
PilzAdam |
you get really smooth curves in the target system, while the accelration one will always delay |
| 13:13 |
PilzAdam |
proller, NOOOO! |
| 13:13 |
PilzAdam |
:-p |
| 13:13 |
PilzAdam |
why do you do that in core? |
| 13:13 |
PilzAdam |
it would work perfectly fine in lua with this slow interval and low chance |
| 13:20 |
|
sapier joined #minetest-dev |
| 13:22 |
proller |
PilzAdam, its faster |
| 13:23 |
PilzAdam |
it doesnt need to be fast with this low chance and slow interval |
| 13:28 |
proller |
its must analyze blocks around |
| 13:28 |
proller |
and it must freeze big oceans |
| 13:29 |
PilzAdam |
and you hardcode nodenames? oO |
| 13:29 |
PilzAdam |
bbl (sry) |
| 13:32 |
proller |
harcode for melting |
| 13:33 |
proller |
for preserve level |
| 13:33 |
proller |
_flowing-> snow |
| 13:33 |
proller |
_source->ice |
| 13:33 |
proller |
or maybe add melt definition |
| 13:33 |
proller |
and freeze |
| 13:40 |
proller |
is any objections about first two commits? |
| 13:48 |
proller |
okay, willl commit |
| 13:48 |
Exio4 |
ehm |
| 13:49 |
Exio4 |
that is not |
| 13:49 |
Exio4 |
good |
| 13:49 |
Exio4 |
the idea of asking for other core dev is waiting for *him* to accept, not "objections" |
| 13:50 |
Exio4 |
silence doesn't mean "everyone is ok and happy with it in the actual form" |
| 13:51 |
proller |
but it works |
| 13:52 |
proller |
ok, accept it please! |
| 13:52 |
Exio4 |
http://dev.minetest.net/Git_Guidelines |
| 13:52 |
Exio4 |
You can push something to upstream [1] only if some other member of the core development team agrees on it [2] |
| 13:52 |
Exio4 |
*only* agrees, not nobody *disagrees* |
| 13:53 |
proller |
even if PilzAdam disagrees and somebody agrees? |
| 13:53 |
Exio4 |
in that case you'll need to hear to PilzAdam and try to see, maybe it is something trivial? but the change can be completly wrong or breaking other thing or so |
| 14:01 |
proller |
its 51% joke |
| 14:02 |
proller |
m_game_time returned |
| 14:03 |
Taoki |
http://forum.minetest.net/viewtopic.php?pid=99636#p99636 Might be an interesting improvement to consider |
| 14:06 |
Taoki |
PilzAdam: ^ Also related to mob movement, which IMO this could improve a lot |
| 14:19 |
PilzAdam |
Taoki, even the first sentence is wrong |
| 14:19 |
PilzAdam |
we use UDP |
| 14:19 |
Taoki |
PilzAdam: Oh, sorry about that. I remembered TCP for some reason |
| 14:20 |
Taoki |
Corrected |
| 14:20 |
PilzAdam |
proller, hardcoding node names is a complete nogo |
| 14:21 |
PilzAdam |
this neighbor thingy can be done in Lua too without any major performance regressions |
| 14:21 |
PilzAdam |
hardcoding these ABMs is just plain wrong |
| 14:22 |
PilzAdam |
and how is melting related to "weather"? |
| 14:22 |
proller |
its first step |
| 14:23 |
PilzAdam |
move these ABMs to minetest_game and add API calls for get_heat() etc. |
| 14:23 |
proller |
falling snow will fill all around without melting |
| 14:24 |
proller |
now minetest use 100-200% i5 cpu |
| 14:24 |
proller |
with this abm near ocean it will be 300+ |
| 14:24 |
Exio4 |
200%? how are you doing that black magic |
| 14:24 |
Exio4 |
proller: 100%, singlethread |
| 14:25 |
proller |
23:30 126.17% minetest |
| 14:25 |
proller |
now 4 threads |
| 14:27 |
PilzAdam |
your performance argument is wrong; Lua wont decrease the performance that much |
| 14:27 |
Exio4 |
yes, 126%, you can't make lua multithreaded |
| 14:27 |
Exio4 |
and with luajit, it can even be faster |
| 14:27 |
PilzAdam |
maybe the ABM itself is the problem, but hardocing wont help then |
| 14:30 |
PilzAdam |
!join #wolfgame |
| 14:30 |
PilzAdam |
oops |
| 14:35 |
|
NakedFury joined #minetest-dev |
| 14:36 |
proller |
PilzAdam, i make .frozemelt property for snow and waters |
| 14:48 |
|
Jordach joined #minetest-dev |
| 15:02 |
|
Kray joined #minetest-dev |
| 15:04 |
Taoki |
What's wolfgame even? I hear a lot about it here :) |
| 15:04 |
Taoki |
a minetest game? |
| 15:04 |
PilzAdam |
-> #minetest |
| 15:07 |
|
Naked joined #minetest-dev |
| 15:47 |
|
Jordach joined #minetest-dev |
| 15:54 |
kahrl |
Any news on #822/#827? I think it's quite an important issue because it prevents servers from running |
| 15:58 |
|
Calinou joined #minetest-dev |
| 16:01 |
proller |
removed hardcode https://github.com/proller/minetest/compare/weather |
| 16:04 |
proller |
and support for it in game: https://github.com/proller/minetest_game/compare/weather |
| 16:04 |
proller |
accept someone 8) |
| 16:04 |
proller |
its not final and disabled by default |
| 16:07 |
|
Kray joined #minetest-dev |
| 16:51 |
|
hmmmm joined #minetest-dev |
| 17:06 |
Jordach |
hmmmm, do you have your custom MGV7 lua settings? |
| 17:06 |
Jordach |
please pastebin me a copy, i could do with one atm |
| 17:07 |
PilzAdam |
Jordach, Pilztest uses v7 |
| 17:07 |
Jordach |
PilzAdam, i want to use minetest_game with MGV7 |
| 17:07 |
Jordach |
not your game |
| 17:07 |
Jordach |
so snow biomes, desert etc |
| 17:07 |
PilzAdam |
you can create them yourself |
| 17:08 |
Jordach |
logs it is then |
| 17:16 |
|
sapier joined #minetest-dev |
| 17:24 |
|
iqualfragile joined #minetest-dev |
| 17:27 |
Jordach |
PilzAdam, found it: http://pastebin.com/1kjU5tN7 |
| 17:49 |
proller |
Jordach, is this definitions in git? |
| 17:50 |
Jordach |
nope. |
| 17:50 |
Jordach |
no MGV7 defines in git# |
| 18:10 |
celeron55 |
kahrl: if it works and doesn't do anything that potentially breaks something, i'm okay with it |
| 18:17 |
kahrl |
well, considering there are some bad pointer accesses in minetest that can in theory overwrite anything with anything, any change can potentially break something |
| 18:18 |
kahrl |
if we assume those don't happen I'm quite certain my patch is safe |
| 18:18 |
kahrl |
though I neither proved it nor tested it exhaustively |
| 18:20 |
Jordach |
can we fix MGV7 so that trees grow out of the ground as they do in MGV6 |
| 18:20 |
Jordach |
without the need for a schematic |
| 18:21 |
VanessaE |
if 827 goes in, I'd suggest fixing the whole nodeid limit entirely as soon as practical |
| 18:21 |
VanessaE |
or at least, in the news post, make a mention that the "C++ exception" isn't so much a bug as an error message |
| 18:23 |
kahrl |
VanessaE: you mean the message old clients get on your server? |
| 18:24 |
VanessaE |
kahrl: I mean the news post you proposed |
| 18:24 |
kahrl |
well, to be frank, the C++ exception message is a bug |
| 18:24 |
VanessaE |
though if that's fixable too, you might want to at least catch it and...oh |
| 18:25 |
kahrl |
it's the serialization bug I explained yesterday or some time |
| 18:25 |
VanessaE |
right, I know |
| 18:26 |
VanessaE |
but it's only as much a bug as your willingness to allow > 4069 node ids :-) |
| 18:26 |
kahrl |
hmm? how would that change anything? |
| 18:26 |
|
whirm joined #minetest-dev |
| 18:26 |
kahrl |
the limit's there in old clients, can't change it now |
| 18:26 |
whirm |
Hi all |
| 18:26 |
VanessaE |
oh nevermind, I was trying to make a small joke :) |
| 18:27 |
kahrl |
sorry for not getting it :P |
| 18:29 |
whirm |
I'm having a very weird error, I have whole areas of my maps which are completely dark |
| 18:30 |
whirm |
torches work, but its just as if I was underground, the sky is dark, no stars or moon whatsoever |
| 18:31 |
kahrl |
whirm, I think that's more suited for #minetest |
| 18:33 |
kahrl |
once it's known that it's caused by the core and not by some malfunctioning mod, it can be discussed here of course |
| 18:34 |
whirm |
kahrl: I've tried creating a new map with the minimal game and its even worse |
| 18:34 |
whirm |
the whole map is dark |
| 18:35 |
kahrl |
very strange then, I've never seen this happen with just the standard mods |
| 18:35 |
whirm |
with technic_game there are both dark and normal parts |
| 18:35 |
kahrl |
whirm: and you're not using bumpmapping? |
| 18:35 |
whirm |
I've tried with irrlich 1.7 and 1.8 with the same results |
| 18:36 |
kahrl |
try enable_shaders = 0, enable_bumpmapping = 0 |
| 18:36 |
whirm |
kahrl: shaders are disabled |
| 18:36 |
whirm |
let me check bumpmapping |
| 18:36 |
kahrl |
shouldn't have any effect if shaders are already disabled |
| 18:36 |
* whirm |
tries just in case |
| 18:37 |
whirm |
nope, exactly the same |
| 18:37 |
whirm |
can a texture pack influence this? |
| 18:38 |
kahrl |
not really unless the textures are all dark... but you said there are lit parts too |
| 18:38 |
whirm |
yes, the textures are ok |
| 18:39 |
kahrl |
does this happen with all mapgens? |
| 18:40 |
whirm |
I had an old map that was OK, but I deleted it and any new I create its like this |
| 18:40 |
whirm |
kahrl: I think so, let me try |
| 18:41 |
kahrl |
on my end, I see lighting glitches like that with the math mapgen but not the others |
| 18:42 |
PilzAdam |
kahrl, I think the mapgen outputs pure dark areas, and plantlife in techinc forces recalc where trees grow |
| 18:42 |
whirm |
v6, v7, indev are completely dark |
| 18:43 |
whirm |
the math one is mostly OK above 0, but dark under water |
| 18:45 |
kahrl |
PilzAdam: this is without mods |
| 18:45 |
PilzAdam |
<whirm> with technic_game there are both dark and normal parts |
| 18:45 |
kahrl |
oh, you mean that |
| 18:45 |
PilzAdam |
just a guess |
| 18:45 |
kahrl |
that would explain it, right |
| 18:46 |
VanessaE |
I would think any of the objects routed through plants_lib would do that, really |
| 18:47 |
whirm |
VanessaE: yes, it looks like its not dark in areas where moretrees trees spawn |
| 18:54 |
whirm |
is there anything else I can do to help debug the thing |
| 18:54 |
whirm |
? |
| 18:54 |
kahrl |
whirm: I'm a bit stumped, sorry |
| 18:55 |
kahrl |
does this happen with a clean minetest.conf too? |
| 18:55 |
whirm |
kahrl: let me see |
| 18:56 |
whirm |
kahrl: yes, I deleted minetest.conf and its the same |
| 18:56 |
kahrl |
very weird |
| 18:57 |
kahrl |
if you have lots of time, you could try bisecting to find out when this started |
| 18:57 |
whirm |
indeed |
| 18:58 |
whirm |
kahrl: Ill try for a while |
| 18:58 |
whirm |
any point in particular you think I should start from? |
| 18:58 |
kahrl |
not really, but you could try the releases |
| 18:58 |
whirm |
ok |
| 18:59 |
kahrl |
start with 0.4.7 and go backwards |
| 18:59 |
whirm |
I think it was OK at 0.4.7 |
| 18:59 |
kahrl |
if it is, bisect between 0.4.7 and now |
| 19:00 |
kahrl |
there were lots of mapgen related commits since then so I can't point at a single one |
| 19:00 |
whirm |
kahrl: ok, I'm on it |
| 19:02 |
whirm |
0.4.7 is fine |
| 19:04 |
hmmmm |
do you think it could be your configuration file |
| 19:05 |
kahrl |
hmmmm: already eliminated that possibility |
| 19:05 |
hmmmm |
it could also be a mod, because mods can set mapgen flags now too |
| 19:06 |
proller |
hmmmm, why NoiseParams nparams_biome_def_heat {50, 50, v3f(500.0, 500.0, 500.0), 5349, 3, 0.70}; |
| 19:06 |
proller |
50,50 ?? |
| 19:06 |
proller |
average 50c ? |
| 19:06 |
hmmmm |
proller, that's my half-assed attempt to get it ranging from 0-100 with an average of 50 |
| 19:06 |
hmmmm |
but it's wrong |
| 19:06 |
proller |
why 0-100 |
| 19:06 |
hmmmm |
good question |
| 19:06 |
proller |
-70..60 on earth |
| 19:06 |
VanessaE |
hmmmm: the ramp is, as far as I could tell, something more like -25 to +150C |
| 19:07 |
kahrl |
proller: where is it s stated that it's celsius |
| 19:07 |
VanessaE |
(as defined by snow mod and plants_lib) |
| 19:07 |
hmmmm |
proller, vanessae, like i said it's wrong |
| 19:07 |
kahrl |
-s |
| 19:07 |
proller |
15, 60 - now works good |
| 19:07 |
VanessaE |
hmmmm: I know, just in case you feel like changing it I mean |
| 19:08 |
hmmmm |
i would fix them to have a sane range when i go to actually add in all the biomes |
| 19:09 |
proller |
https://github.com/minetest/minetest/pull/830/files want to commit |
| 19:09 |
hmmmm |
proller, i'd really appreciate it if you didn't go and change the noise params |
| 19:10 |
|
iqualfragile joined #minetest-dev |
| 19:10 |
proller |
no problem |
| 19:11 |
hmmmm |
when you change that, everybody's biome definitions are completely wrong |
| 19:11 |
hmmmm |
that's a great way to break things |
| 19:12 |
proller |
but now no biome defs in git |
| 19:12 |
hmmmm |
that doesn't matter |
| 19:13 |
hmmmm |
there are quite a few mods i can think of that already use it |
| 19:13 |
hmmmm |
even though it's completely undocumented and i never said anybody could... |
| 19:14 |
proller |
then you must change it to more correct |
| 19:14 |
proller |
it will be harder after, when more mods would use it |
| 19:14 |
hmmmm |
erm |
| 19:15 |
hmmmm |
i'm really not sure if weather should be something in the core |
| 19:15 |
VanessaE |
hmmmm: only if it doesn't rain/snow inside a building :) |
| 19:16 |
proller |
its long way to make complete weather |
| 19:16 |
hmmmm |
what's wrong with the weather mod? |
| 19:16 |
proller |
its first small steps |
| 19:17 |
proller |
and in pull- only freeze-melting |
| 19:17 |
whirm |
2e292b67a0a02b045969034c06aaf92b42a83a81 is the first bad commit |
| 19:17 |
whirm |
Add Lua on_mapgen_init callback, and minetest.set_mapgen_params API |
| 19:17 |
hmmmm |
proller, env->getMap().transforming_liquid_add(p0); |
| 19:18 |
hmmmm |
what happens if the server map is NULL? |
| 19:18 |
proller |
coredump? |
| 19:18 |
hmmmm |
or what if the environment doesn't exist yet? |
| 19:18 |
proller |
but how it can happens? |
| 19:18 |
hmmmm |
this would've been okay if env was still its own object |
| 19:19 |
whirm |
kahrl: ^^ |
| 19:19 |
kahrl |
proller: why is minetest.transforming_liquid_add even needed? |
| 19:19 |
kahrl |
it's not used anywhere as far as i can see |
| 19:19 |
hmmmm |
I suppose he wants to use it for the lua portion of his own weather mod |
| 19:20 |
proller |
now - not, can remove for now |
| 19:20 |
proller |
but it can be useful for something related to liquid |
| 19:20 |
hmmmm |
i don't really think these ABMs and what not should be in the core |
| 19:21 |
hmmmm |
something like liquid flowing, sure okay, i can see that |
| 19:21 |
hmmmm |
but where does it end? |
| 19:21 |
kahrl |
hmmmm: agreed |
| 19:21 |
hmmmm |
next someone's going to want to move lava cooling into the core |
| 19:21 |
hmmmm |
and then every time someone wants to add an ABM, where does it go? |
| 19:21 |
hmmmm |
if you start hardcoding things like this, hell, why not hard code door prediction into the client .... |
| 19:21 |
hmmmm |
then it'll be back to the way it was in 0.3.x |
| 19:22 |
proller |
its faster than lua |
| 19:22 |
hmmmm |
yeah... but.. |
| 19:22 |
kahrl |
whirm: only way I can see that commit introducing the bug would be if something sets the nolight mapgen flag |
| 19:22 |
hmmmm |
and these are such mundane ABMs, all they do is set a certain node to another node |
| 19:22 |
whirm |
maybe it gets set by default somehow? |
| 19:22 |
proller |
these abms must work with huge amount of blocks |
| 19:23 |
VanessaE |
proller: if something's just too slow but unsuitable for the core, there IS a way to do C++ mods now, kinda-sorta that is (in the form of loadable binary libs, ask RBA, he knows more about that) |
| 19:23 |
kahrl |
whirm: perhaps try grep -Ri nolight . |
| 19:23 |
kahrl |
in the minetest directory |
| 19:25 |
kahrl |
when I execute that it finds matches in minetest.conf.example, src/mapgen_* and some binary files |
| 19:26 |
whirm |
let me rebuild the bad commit |
| 19:26 |
kahrl |
I'm mostly interested in whether there's any lua files that contain nolight |
| 19:26 |
proller |
100000+ blocks of water and ice around me |
| 19:27 |
hmmmm |
proller, it's just that i don't want people to add ABMs as a knee-jerk reaction to a new feature |
| 19:27 |
hmmmm |
like here i guess it's fine because you need to do a lot of setting, but it's just that i don't really like how the core is becoming more... specific |
| 19:28 |
hmmmm |
and you have specific values set for fog/melting temp/freezing temp |
| 19:28 |
whirm |
kahrl: http://paste.debian.net/16061/ |
| 19:29 |
proller |
no problem to make adjustable this values, and make lavacooling on it |
| 19:29 |
proller |
but on next steps |
| 19:29 |
kahrl |
whirm: so nolight is enabled in the world "bad" |
| 19:30 |
kahrl |
don't know why but it is |
| 19:30 |
whirm |
kahrl: yes, this is a world created from the first bad commit |
| 19:31 |
proller |
hmmmm, about env->getMap(). - its used in 10+ places in api |
| 19:31 |
hmmmm |
proller, yeah, that's something that should probably be fixed, but we should ask sapier first |
| 19:31 |
hmmmm |
(well, or test it) |
| 19:32 |
hmmmm |
couldn't be arsed to do minetest related things aside from chatting right now, sorry |
| 19:33 |
hmmmm |
whirm, i suppose you *tried out* a mod that turns off lighting and then it got written to map_meta.txt, and you removed the mod but the setting still stayed there |
| 19:33 |
hmmmm |
that could be the problem |
| 19:33 |
hmmmm |
do you guys see now why I didn't want lua to have control over mapgen settings? :( |
| 19:38 |
whirm |
hmmmm when bisecting I created a new world every step using the minimal game with no mods enabled |
| 19:39 |
celeron55 |
to me this sounds like an uninitialized variable |
| 19:39 |
kahrl |
celeron55: my thoughts, but I can't find that variable |
| 19:39 |
celeron55 |
(well, sounds until proven otherwise) |
| 19:42 |
hmmmm |
well, it's lua -> map_meta.txt -> world specific config -> global config -> config defaults -> constructor defaults in terms of precedence |
| 19:42 |
hmmmm |
and it's definitely not an uninitialized variable, that's basically impossible |
| 19:44 |
celeron55 |
it's valgrind time! |
| 19:45 |
celeron55 |
i have no idea what it could tell, but that's why one needs to try it |
| 19:46 |
hmmmm |
erm, a bunch of well-placed printfs would work way better than valgrind ever could |
| 19:46 |
hmmmm |
for this situation in particular |
| 19:46 |
celeron55 |
of course; my order of preference starts with valgrind though if i haven't been working on given code in a long time 8) |
| 19:48 |
celeron55 |
especially as such random behavior screams to me "memory corruption" |
| 19:51 |
whirm |
it doesnt look random to me, before that commit the maps are ok, after it completely dark, its not random |
| 19:52 |
hmmmm |
keep in mind this is *only* you having the problem |
| 19:52 |
hmmmm |
i'm going to say that it's due to some stealthy mod or an errant setting in the config |
| 19:53 |
whirm |
oh |
| 19:54 |
hmmmm |
"before/after that commit" isn't really significant, we know it's working like it should because you clearly have nolight in your map_meta.txt. the question right now is how it got there |
| 19:54 |
kahrl |
checked out 2e292b67a0, compiled with -O0, started valgrind, selected minimal, made new world, opened world, waited until I saw some generated blocks, closed game |
| 19:54 |
kahrl |
nothing that stands out in the valgrind log |
| 19:55 |
kahrl |
I mean, there are lots of uninitialized value warnings, but nothing mapgen related |
| 19:55 |
celeron55 |
whirm: so is the case that any new world started with a version before that commit does not have the problem, and any world started after it has? |
| 19:56 |
whirm |
celeron55: exactly |
| 19:56 |
celeron55 |
also i must say that these new minetest_game sounds are ridiculously bad |
| 19:56 |
hmmmm |
i personally think they're better than cracking eggshells |
| 19:56 |
celeron55 |
(i just compiled a new version since... a lot ago) |
| 19:56 |
hmmmm |
but it is still bad |
| 19:57 |
hmmmm |
it's hilarious, we have so many non-technical people interested in contributing to minetest but our sounds and textures suck really hard |
| 19:57 |
hmmmm |
whirm: did you check any other possible places where mapgen settings might be set? |
| 19:58 |
whirm |
hmmmm: for instance? |
| 19:58 |
celeron55 |
sand sounds like you're wealking in some kind of mud, and grass sounds like... nothing from real life |
| 19:58 |
hmmmm |
the gravel step sounds good at least |
| 19:58 |
hmmmm |
whirm, [03:42 PM] <hmmmm> well, it's lua -> map_meta.txt -> world specific config -> global config -> config defaults -> constructor defaults in terms of precedence |
| 19:58 |
celeron55 |
also on proper speakers grass actually is so loud on high frequencies that it's completely unenjoyable |
| 20:00 |
Jordach |
uhoh -- all formspecs in master are literally broken |
| 20:01 |
Jordach |
literal clean server running master + master of minetest_game: http://i.imgur.com/5SSt7wJ.png |
| 20:02 |
Jordach |
i'll try a more recent client, see if it fixes it |
| 20:02 |
whirm |
hmmmm: I have no minetest.conf, no mods enabled, using minimal_game and the world is new at each bisect iteration |
| 20:02 |
hmmmm |
what does that last clause of your sentence mean exactly...? |
| 20:03 |
hmmmm |
"at each bisect iteration" ?????? |
| 20:03 |
whirm |
hmmmm: I did a git bisect to find out which was the bad commit |
| 20:03 |
Exio4 |
proller: u32 get_game_time() { return m_game_time; } |
| 20:04 |
Exio4 |
should that function be called getGameTime or something like that? |
| 20:04 |
hmmmm |
whirm, the problem isn't finding the commit "that broke it" |
| 20:04 |
hmmmm |
the cause of this is exactly known |
| 20:04 |
proller |
Exio4, maybe yes, but its ugy make onemore name for var |
| 20:05 |
Exio4 |
what? |
| 20:05 |
proller |
game_time GameTime gameTime |
| 20:05 |
hmmmm |
just use the current master, start a new world without any mods that change mapgen flags, making sure your game-specific conf (if one exists) and global conf doesn't have nolight in mgflags |
| 20:05 |
proller |
camel sux |
| 20:05 |
Exio4 |
i don't like it but it is a guideline |
| 20:05 |
hmmmm |
proller, we do have code guidelines you know, right? |
| 20:06 |
proller |
ok |
| 20:06 |
hmmmm |
for like a half year it seems |
| 20:06 |
hmmmm |
http://dev.minetest.net/Code_style_guidelines |
| 20:08 |
proller |
fixed |
| 20:11 |
proller |
PascalCase, method names are camelCase., unix_lowercase_underscore_style(). -- 3 types in one gudeline |
| 20:11 |
whirm |
hmmmm: I compiled master, created a new world with no mods loaded, started it once, nolight was set, exited, removed the flag from the config file, deleted map.sqlite, started again, everything is fine. |
| 20:12 |
whirm |
I guess mods can't modify those flags even if I don't specifically enable them, right? |
| 20:12 |
hmmmm |
no, mods are able to explicitly modify any mapgen flags at creation time as they'd like |
| 20:13 |
whirm |
so I should delete the mods folder then I guess |
| 20:14 |
hmmmm |
I thought you said you weren't using any mods... |
| 20:14 |
whirm |
I wasnt using them, but I had them on the mods folder |
| 20:14 |
hmmmm |
try removing them and seeing if that helps |
| 20:20 |
whirm |
empty mods/ dir, only minetest_game on games/, still nolight set when creating a new world |
| 20:21 |
hmmmm |
and you're absolutely sure nolight isn't in a global config file, or something like that? |
| 20:22 |
|
adc joined #minetest-dev |
| 20:22 |
hmmmm |
by the way, which mapgen are you using? |
| 20:22 |
kahrl |
I think at this point we should try the printf debugging framework |
| 20:22 |
|
adc_ joined #minetest-dev |
| 20:23 |
hmmmm |
kahrl, right. whirm, you don't mind modifying source code, right? |
| 20:24 |
hmmmm |
in server.cpp:811, add printf("=== flags: 0x%08x", mgparams->flags); and add the same thing on line 816, after m_emerge->initMapgens() |
| 20:25 |
whirm |
hmmmm: there's no minetest.conf, where can it be if it's not there? |
| 20:25 |
hmmmm |
it could be in your home directory, hidden maybe, if it's not compiled with run_in_place |
| 20:26 |
Exio4 |
~/.minetest/minetest.conf |
| 20:26 |
whirm |
hmmmm: └──> find ~ -iname "*minetest.conf*" |
| 20:26 |
whirm |
gives no results |
| 20:26 |
whirm |
and its compiled with run_in_place |
| 20:27 |
whirm |
let me modify the shource |
| 20:27 |
kahrl |
it should at least print minetest.conf.example |
| 20:27 |
hmmmm |
maybe he doesn't have the source in his home directory |
| 20:27 |
whirm |
kahrl: its not in my home |
| 20:28 |
kahrl |
ah, okay |
| 20:28 |
hmmmm |
i don't think the install script installs the example |
| 20:28 |
kahrl |
what are the results when you run that find command on the source directory? |
| 20:31 |
whirm |
kahrl: ./minetest.conf.example |
| 20:31 |
whirm |
hmmmm: I'm not installing anything by the way |
| 20:32 |
celeron55 |
have you ever played around with the nolight flag anywhere? |
| 20:32 |
hmmmm |
he is indicating that he did not, i'm telling him to just add those printfs so we can see where it is being set exactly |
| 20:33 |
* whirm |
building |
| 20:33 |
celeron55 |
well it seems printfs would be the way to go in any case |
| 20:33 |
kahrl |
the game looks for $path_user/minetest.conf, $path_user/../minetest.conf, $path_user/../../minetest.conf |
| 20:34 |
whirm |
celeron55: I did some time ago, but nothing remains from then |
| 20:34 |
kahrl |
path_user is the minetest directory (that contains bin, src, ...) |
| 20:34 |
celeron55 |
whirm: as kahrl said, minetest has some sneaky (somewhat legacy) load paths for minetest.conf 8) |
| 20:35 |
whirm |
=== flags: 0x0000005f=== flags: 0x0000005f22:35:00: ACTION[main]: .__ __ __ |
| 20:35 |
hmmmm |
whoops, forgot \n |
| 20:35 |
hmmmm |
but whatever |
| 20:36 |
hmmmm |
so anyway it's being set in one of the config files |
| 20:36 |
hmmmm |
oh hey whirm, copy minetest.conf.example to minetest.conf in the directory and try that |
| 20:36 |
celeron55 |
whirm: when you start minetest with a deleted minetest.conf, it creates it to where you suppose it'd be, right? |
| 20:37 |
celeron55 |
if that is the case, then you don't have any sneaky config anywhere |
| 20:37 |
celeron55 |
if not, then you *have* |
| 20:37 |
hmmmm |
0x5f = 0x40 (nolight) | 0x1f (trees, caves, dungeons, jungles, biome blend) <-- these are the default flags |
| 20:38 |
hmmmm |
so you can see it's clearly not an uninitialized variable |
| 20:38 |
|
ecube joined #minetest-dev |
| 20:43 |
whirm |
so, it looks for the file on the parent dir of the source? |
| 20:43 |
kahrl |
that and the parent of that |
| 20:44 |
whirm |
fuck, this is where I had backed up the config file |
| 20:44 |
kahrl |
(the latter on in RUN_IN_PLACE builds) |
| 20:44 |
VanessaE |
isn't that a little...well...weird? |
| 20:44 |
kahrl |
only* |
| 20:44 |
Exio4 |
i don't use RUN_IN_PLACE builds because i like having ALL the configs in a single place, am i weird? :P |
| 20:45 |
hmmmm |
erm... why would anybody set nolight manually in the config |
| 20:45 |
VanessaE |
hmmmm: a moon map maybe? |
| 20:45 |
hmmmm |
the mod should do that then |
| 20:45 |
Exio4 |
nop |
| 20:45 |
Exio4 |
+e |
| 20:45 |
Exio4 |
nolight should be used only and only, and ONLY for mods |
| 20:45 |
Exio4 |
no? :D |
| 20:46 |
hmmmm |
you know something |
| 20:46 |
hmmmm |
it may be handy to include some sort of "spit out config" option to prevent future cases of this |
| 20:46 |
Exio4 |
"spit out" what would it do? |
| 20:47 |
hmmmm |
it'd output what the current settings are and what config file it was set in |
| 20:47 |
Exio4 |
ah |
| 20:48 |
hmmmm |
for example you'd have: CONFIG: mg_flags = "blahblah" - set by "../minetest.conf", and then CONFIG: something_other = "whatever" - set by "default setting" |
| 20:48 |
kahrl |
postfix has this and it can be really useful |
| 20:48 |
VanessaE |
hmmmm: absolute paths |
| 20:48 |
hmmmm |
ofcourse absolute paths |
| 20:48 |
VanessaE |
good idea at any rate |
| 20:49 |
VanessaE |
useful for bug reports in general, or if we get some kind of automated bug reporting tool some day like what ff has |
| 20:49 |
|
iqualfragile joined #minetest-dev |
| 20:50 |
whirm |
anyways, looking for a config file in so many places is unexpected, at least minetest should print which config file is it reading the config from, it would saved a lot of time |
| 20:50 |
hmmmm |
whirm, I definitely agree |
| 20:50 |
hmmmm |
also eduke32 could use the same |
| 20:52 |
hmmmm |
thus ends another case of "i told you so" |
| 20:52 |
VanessaE |
at this point, is there any real reason to read it from anywhere except minetest top level, ~/.minetest, or maybe some file in /etc ? |
| 20:52 |
hmmmm |
lol, minetest in /etc |
| 20:53 |
VanessaE |
hmmmm: I've seen stranger stuff placed there :) |
| 20:53 |
hmmmm |
if it were up to me it'd look in ~/.minetest, the current working directory, and that's it - absolutely nowhere else |
| 20:53 |
VanessaE |
yes. |
| 20:53 |
hmmmm |
but this is already an established thing and we need to work with what we're given |
| 20:54 |
VanessaE |
well, current working directory is iffy.. |
| 20:54 |
kahrl |
I disagree with current working directory |
| 20:54 |
VanessaE |
cwd might be minetestdir/bin |
| 20:54 |
VanessaE |
or just minetestdir |
| 20:54 |
hmmmm |
yeah, i don't like putting things in bin though |
| 20:54 |
hmmmm |
i mean, come on, it's two files |
| 20:54 |
hmmmm |
it'd make sense if there were 50000 DLLs and what not |
| 20:54 |
VanessaE |
true |
| 20:54 |
kahrl |
someone could place a specially crafted minetest.conf and mod directory in the current working directory that executes some malware lua code |
| 20:55 |
hmmmm |
such is the case for games in windows |
| 20:55 |
kahrl |
don't remember off the top of my head if minetest.conf can modify mod paths |
| 20:56 |
hmmmm |
sapier already had a lot to say about this and attempted to fix the problem but it never took off because it'd break backwards compatibility |
| 21:01 |
kahrl |
I'm going to push #727 now if no one objects |
| 21:01 |
VanessaE |
827* |
| 21:02 |
kahrl |
oops |
| 21:02 |
sfan5 |
kahrl: thats not how the "core dev must agree" thing is supposed to work |
| 21:03 |
sfan5 |
but #872 sems fine to merge |
| 21:03 |
Exio4 |
pilzadam tried and 'agreed' to it |
| 21:04 |
kahrl |
sfan5: celeron55 agreed to it |
| 21:04 |
sfan5 |
ah, ok |
| 21:04 |
sfan5 |
IIRC there were cases where someone just said "if nobody disagrees [...]" |
| 21:05 |
Exio4 |
proller' |
| 21:05 |
kahrl |
sfan5: yeah, without explicit agreement that should only be done for reasonably trivial commits |
| 21:05 |
sfan5 |
Exio4: thats what I wanted to avoid saying |
| 21:05 |
Exio4 |
or for things that are .. like v7 |
| 21:05 |
Exio4 |
in that case hmmmm has the right to do it without asking ;P |
| 21:07 |
Exio4 |
kahrl, sfan5, hmmmm, shouldn't that be "explicit"? for fixing documentation, trivial-and-simple changes and so on, that "rule" can be avoided? |
| 21:07 |
sfan5 |
yeah, probably |
| 21:09 |
kahrl |
yeah, that stuff can be pushed without asking, but sometimes you want to ask regardless |
| 21:10 |
Exio4 |
i think for fixing documentation, or cosmetic fixes (like changing comments, small "cleanup" like adding tabs, or so) should be explicited "noted" |
| 21:10 |
Exio4 |
i mean, just for noting it in a "paper", it won't hurt anyone |
| 21:11 |
kahrl |
yeah, it can be noted in http://dev.minetest.net/Git_Guidelines |
| 21:16 |
Exio4 |
yep :P |
| 21:20 |
hmmmm |
if a change might screw something up or you're changing other peoples' code, really |
| 21:20 |
hmmmm |
like if I'm going to modify the way scriptapi works for example, i'd ask sapier first because he'd know if it breaks anything |
| 21:21 |
whirm |
off to bed now, thanks for the help |
| 21:21 |
hmmmm |
if i were to modify the way the emerge manager works, i wouldn't necessarily ask anybody because i know that code best |
| 21:21 |
Exio4 |
the emergemanager guy ;P |
| 21:21 |
hmmmm |
the whole "ask another core dev" "rule" is misguided |
| 21:22 |
Exio4 |
yeah |
| 21:23 |
hmmmm |
for neutral code such as mapnode.cpp, a general consensus is needed more or less |
| 21:24 |
VanessaE |
yay! my server works again :) |
| 21:24 |
Exio4 |
haha |
| 21:24 |
VanessaE |
er, wrong channel |
| 21:28 |
sapier |
Taoki I investigated mobf slowness for vombies in current git ... for my system cpu usage drops drasticaly if pathfinding is disabled |
| 21:29 |
Exio4 |
if they are dumb they are fast8 |
| 21:29 |
Exio4 |
s/8/*/ |
| 21:29 |
kahrl |
making a News post, does this look fine? http://paste.dy.fi/ko6 |
| 21:32 |
sfan5 |
kahrl: looks fine to me |
| 21:32 |
VanessaE |
kahrl: I'm a little dubious about my server being singled out :P but seems okay otherwise :) |
| 21:32 |
kahrl |
VanessaE: well, how'd you phrase it? :P |
| 21:33 |
VanessaE |
you had to ask. :) |
| 21:35 |
VanessaE |
just leave those parts out entirely, since you already have a good explanation of what happens anyway |
| 21:35 |
VanessaE |
I already posted an update to my server thread......and ShadowNinja already signed on :D |
| 21:35 |
sapier |
PilzAdam if you want to re mobs in simplemobs while using your core dev privileges to add those features you need to do what mobf worked around due to not having chance to get fixes in quick do it... but don't expect me to do a lot of work in this area. I will maintain and improove mobf as long as there is any chance for it to be usefull ... if there's another implementation of mobs added to core I'll drop mobf ... this is same as micro |
| 21:36 |
kahrl |
VanessaE: well, not every player might look into your server topic |
| 21:36 |
kahrl |
especially if they found your server via the in game menu |
| 21:36 |
VanessaE |
true |
| 21:37 |
sapier |
VanessaE you can but the note in server description |
| 21:37 |
VanessaE |
there are a disturbing number of users who find it that way, even with the server thread link mentioned in the motd. |
| 21:37 |
sapier |
as the desscription is new atm users might tend to look at it for some days |
| 21:42 |
Exio4 |
does anyone know an easy way to add a 250ms "forced" latency? |
| 21:43 |
VanessaE |
Exio4: downgrade to 33.6k dial-up? :D |
| 21:43 |
kahrl |
Exio4: loopback or other interface? |
| 21:43 |
Exio4 |
kahrl: loopback, yes |
| 21:43 |
Exio4 |
VanessaE: my nether already has a 250ms latency to anywhere outside my lan |
| 21:43 |
Exio4 |
nether.. i mean network |
| 21:43 |
kahrl |
not easy in general, minetest has an INTERNET_SIMULATOR that could be extended like that |
| 21:44 |
Exio4 |
hm |
| 21:44 |
kahrl |
VanessaE: so, should I post my version or without mentioning your server? |
| 21:45 |
Exio4 |
i'll just run it on this server and a super-reduced game |
| 21:45 |
Exio4 |
(minimal's default only) |
| 21:45 |
VanessaE |
kahrl: it's up to you |
| 21:46 |
kahrl |
Exio4: try this: tc qdisc add dev lo root netem delay 50ms |
| 21:46 |
kahrl |
250ms* |
| 21:46 |
Exio4 |
kahrl: iirc it drops packets for adding delay |
| 21:46 |
kahrl |
Exio4: yeah, INTERNET_SIMULATOR only drops packets |
| 21:47 |
Exio4 |
is that desired? |
| 21:47 |
kahrl |
VanessaE: it's your server, so your choice |
| 21:47 |
kahrl |
Exio4: dunno, never used it |
| 21:47 |
Exio4 |
:P |
| 21:47 |
sapier |
it should be quite easy to add a random nanosleep to receive |
| 21:47 |
Exio4 |
i'll just run the server here (a "shell provider" of friend) |
| 21:48 |
kahrl |
sapier: that's not the same, is it? |
| 21:48 |
sapier |
if we use receive in blocking way this should be almost same (at least for a single client) |
| 21:48 |
kahrl |
you want to only increase latency, your solution would increase latency and decrease bandwidth |
| 21:48 |
sapier |
not for multiple clients of course |
| 21:49 |
kahrl |
it would decrease bandwidth even for a single client |
| 21:49 |
kahrl |
unless I'm misunderstanding |
| 21:49 |
Exio4 |
that is why adding client-side prediction is hard! :P |
| 21:49 |
Exio4 |
we need more lag! |
| 21:49 |
sapier |
it does but as far as I know we use synchronized client server communication not parallelizing requests |
| 21:51 |
sapier |
but maybe I'm wrong with that synchronized thing |
| 21:51 |
proller |
https://github.com/proller/minetest-mod-weather/tree/weather - now dynamic |
| 21:52 |
proller |
but needs my core and _game patches |
| 21:52 |
kahrl |
sapier: kind of right what you're saying, but every player movement packet would cause a random nanosleep |
| 21:52 |
sapier |
btw I guess those predicion things fail on a simple issue ... pathfinding is expensive ... too expensive |
| 21:52 |
kahrl |
this would add up quickly |
| 21:53 |
sapier |
but isn't that exactly what happens? |
| 21:53 |
kahrl |
a normal network doesn't increase its latency like that |
| 21:54 |
sapier |
if you use synchronized packed handling it does |
| 21:54 |
kahrl |
movement packets are not synchronized afaik |
| 21:54 |
sapier |
if we send multiple packets at once too the sleep should be done where decision to send multiple packets is done |
| 21:54 |
Exio4 |
well, other question, where is the chat predicted? |
| 21:55 |
sapier |
ok if there are different cases it's not that simple of course |
| 21:55 |
kahrl |
Exio4: Client::typeChatMessage |
| 21:55 |
Exio4 |
where is the "chat_backend->addmsg("<player> message")" :P |
| 21:55 |
Exio4 |
kahrl: k, thanks! |
| 21:55 |
Exio4 |
was searching in the wrong file |
| 21:57 |
sapier |
guy last call for decision if noone decides what to do about background/overlay thing I'm gonna implement it the way I think it's correct tomorrow |
| 21:58 |
Exio4 |
hmm, the client doesn't know anything about the commands managed by the server? |
| 21:59 |
sapier |
and I think celeron55's description of how it should be is more consistent |
| 22:04 |
kahrl |
Exio4: correct |
| 22:33 |
VanessaE |
another issue I'm seeing is the client crashing if you open the inventory while there's too much of the map being received all at once |
| 22:33 |
VanessaE |
probably requires "preload visuals" to be turned off. May require technic/unified inventory, but it's a client crash, not server. |
| 22:36 |
sapier |
VanessaE I'll implement overlay/background as celeron suggested ... as I wont start until tomorrow evening you may have a last chance to get a consens for your flavor to do it |
| 22:36 |
VanessaE |
if you wait several seconds after connecting before requesting the inventory, it does not crash. |
| 22:36 |
VanessaE |
sapier: eh? |
| 22:36 |
VanessaE |
oh the load order of the menu images? |
| 22:37 |
sapier |
yes I asked for comments 2 days ago I didn't get any celeron wants this you want that and pilzadam wants something similar to what you want |
| 22:37 |
sapier |
that's not anything I can rely on |
| 22:37 |
VanessaE |
well just go with whatever everyone else agrees on. |
| 22:38 |
sapier |
exactly that wont happen I'll do it a last time any further changes wont be my issue anymore |
| 22:38 |
PilzAdam |
sapier, I guess everybody agrees that singleplayer tab shouldnt fall back to default ones |
| 22:38 |
sapier |
exactly you "guess" |
| 22:39 |
PilzAdam |
well, I said so last time and celeron didnt complain about that |
| 22:39 |
sapier |
but only 3 ppl did even comment ant those don't really have a consens |
| 22:39 |
PilzAdam |
he only complained about overlay, and I dont care about that |
| 22:40 |
sapier |
I agree with not falling back to default too that was already in first of celerons suggestion |
| 22:44 |
sapier |
there are only 3 issues on my todo list for formspec menu all others are either major feature enhancements to formspec or things I can't fix ... after those are done I consider formspec menu finished |
| 23:09 |
|
sapier left #minetest-dev |
