| Time |
Nick |
Message |
| 00:10 |
|
SitDog joined #minetest-dev |
| 00:37 |
|
Octupus joined #minetest-dev |
| 00:41 |
|
sema4_ joined #minetest-dev |
| 01:00 |
|
Octupus_ joined #minetest-dev |
| 01:26 |
|
sema4 joined #minetest-dev |
| 02:34 |
|
kotolegokot joined #minetest-dev |
| 02:37 |
|
sema4_ joined #minetest-dev |
| 03:22 |
|
Taoki joined #minetest-dev |
| 04:36 |
|
SitDog_ joined #minetest-dev |
| 05:10 |
|
VanessaE joined #minetest-dev |
| 05:46 |
|
celeron55 joined #minetest-dev |
| 05:47 |
VanessaE |
celeron55: this may be more to your liking: https://github.com/celeron55/minetest_game/pull/64 |
| 06:05 |
|
rsiska joined #minetest-dev |
| 07:27 |
celeron57 |
mese should have no ingots |
| 07:29 |
celeron57 |
mese can't be smelted in any way, it's melting point is so high you can't get there in the game (except maybe with a nuclear bomb or something) |
| 07:30 |
celeron57 |
when you make a mese pick, you just use three mese crystals; let's say they will form a pick that way because the crystals like forming into picks |
| 07:32 |
celeron57 |
i'd say a single crystal put onto the crafting grid should make crystal pieces and general stuff (that does not require the expensiveness of a single crystal) should use them |
| 07:33 |
celeron57 |
or maybe mese smelt in a furnace would break into pieces |
| 07:48 |
yunfan |
celeron57: i'd like the idea |
| 07:49 |
yunfan |
all metal tools should could be smelt back to the original masterial by furnace |
| 10:13 |
|
serengeor joined #minetest-dev |
| 10:32 |
|
Calinou joined #minetest-dev |
| 11:19 |
|
PilzAdam joined #minetest-dev |
| 11:29 |
celeron57 |
hmm, interesting |
| 11:31 |
celeron57 |
i just started minetest 0.3.1 (the one shipped by debian) as a quick udp network test, and could kind of feel the game in it |
| 11:31 |
celeron57 |
because i know it contains mobs 8) |
| 11:34 |
celeron57 |
and spawned in a jungle |
| 12:00 |
|
celeron56 joined #minetest-dev |
| 13:09 |
thexyz |
what's the good way of implementing something like this? https://github.com/minetest/minetest/commit/8a97505b870d5d710ddeafcdf08fd18aa5f885c1 |
| 13:10 |
thexyz |
should i make separate thread for it? |
| 13:16 |
celeron56 |
i guess there is no need for threads if it's done at connect-time |
| 13:17 |
celeron56 |
(thread-safety can be a real bitch and i don't even want to start shouting at people doing it wrong and then having them not even understand me) |
| 13:20 |
thexyz |
the problem is that everything freezes |
| 13:22 |
celeron56 |
and? |
| 13:22 |
thexyz |
and I don't know other way to fix it |
| 13:22 |
thexyz |
is it fine? |
| 13:22 |
PilzAdam |
the "media" stays at 0% |
| 13:22 |
thexyz |
that's what I meant |
| 13:26 |
celeron56 |
hmm |
| 13:26 |
celeron56 |
that is true |
| 13:28 |
celeron56 |
by the way, didn't you remove CE_TEXTURES_UPDATED for the case of receiving the stuff the old way? |
| 13:29 |
celeron56 |
that isn't right |
| 13:30 |
celeron56 |
anyway, yes, there could be a thread for that |
| 13:31 |
thexyz |
i didn't remove anything, should i? |
| 13:31 |
celeron56 |
you moved it to be only done if the curl way is used 8) |
| 13:31 |
celeron56 |
as far as i can tell from the messed up diff |
| 13:32 |
thexyz |
oh |
| 13:32 |
thexyz |
seems so |
| 13:33 |
celeron56 |
also, remote_media would be better called http_media |
| 13:33 |
celeron56 |
because that is what it is |
| 13:33 |
celeron56 |
or... ehm |
| 13:34 |
thexyz |
well, curl also supports ftp, https, etc.. |
| 13:34 |
celeron56 |
but it's not like the current media wasn't remote |
| 13:34 |
thexyz |
it's remote from minetestserver |
| 13:35 |
thexyz |
the name is weird though |
| 13:35 |
celeron56 |
external might be better, but still odd |
| 13:36 |
thexyz |
so, the new thread should populate some list with resource name and its data and then client in step() should do loadMedia, correct? |
| 13:40 |
celeron56 |
feed the list of stuff to the thread in TOCLIENT_ANNOUNCE_MEDIA, start the thread, poll for results in... i guess step() (that is, call loadMedia and handle m_media_receive_progress, and set m_media_received = true and stop the thread when all is done) |
| 13:40 |
celeron56 |
(or, well, the thread should stop itself of course, or go into an idle state) |
| 13:41 |
thexyz |
ok |
| 14:25 |
|
SpeedProg joined #minetest-dev |
| 14:47 |
|
kosc joined #minetest-dev |
| 14:53 |
thexyz |
celeron56: https://github.com/minetest/minetest/commit/89ab66763bd68170460df9b758882c95c81be4f2 |
| 15:17 |
|
hmmmm joined #minetest-dev |
| 15:30 |
|
celeron55 joined #minetest-dev |
| 15:48 |
|
celeron55 joined #minetest-dev |
| 16:01 |
|
celeron55 joined #minetest-dev |
| 16:29 |
|
celeron55_ joined #minetest-dev |
| 16:38 |
VanessaE |
celeron55_ / celeron56 : Done per your suggestion. |
| 16:38 |
VanessaE |
(see pull request #64) |
| 16:38 |
celeron55_ |
hmm |
| 16:39 |
celeron55_ |
how about making mese blocks from 9 crystal fragments? |
| 16:39 |
celeron55_ |
9 crystals is kind of... much? not? 8) |
| 16:40 |
thexyz |
celeron55_: did you see my message? |
| 16:40 |
VanessaE |
no |
| 16:40 |
VanessaE |
that's too cheap. |
| 16:40 |
thexyz |
https://github.com/minetest/minetest/commit/89ab66763bd68170460df9b758882c95c81be4f2 |
| 16:40 |
VanessaE |
that would be the equivalent of making it out of 3 whole Crystals which is slightly cheaper than a pickaxe |
| 16:40 |
VanessaE |
(which needs sticks also) |
| 16:42 |
VanessaE |
celeron55_: remember I'm trying to aim for balance between the behavior of mese and how mods use it, and what really should be now. This is getting pretty damn close imho :-) |
| 16:43 |
celeron55_ |
which brings me to the fact that the mese crystal should be named default:mese |
| 16:43 |
celeron55_ |
and PilzAdam's two first points |
| 16:44 |
celeron55_ |
or is there a particular reason to make mods that require the previous single mese block to require the new very expensive block? |
| 16:46 |
darkrose |
it's about not breaking maps, which would happen if all the mese in existing maps suddenly turned to crystals |
| 16:47 |
VanessaE |
simple: |
| 16:47 |
VanessaE |
old mods should *not* use the mese block. |
| 16:48 |
VanessaE |
they should use mese crystals or mese crystal fragments |
| 16:48 |
VanessaE |
the block is kept as decorative, which is how people use it in practice when they aren't crafting with it. |
| 16:48 |
VanessaE |
crystals should *not* be named default:mese at all, and PilzAdam's ideas suck :-) |
| 16:48 |
celeron55_ |
"old mods should not use the mese block" <- ehm... that is the only mese the old mods have had available |
| 16:49 |
VanessaE |
nononononononon |
| 16:49 |
VanessaE |
that isn't what they used, technically |
| 16:49 |
VanessaE |
they used "mese". |
| 16:49 |
VanessaE |
which was just whatever you put in there, right? |
| 16:49 |
VanessaE |
so now, they use "mese crystal" instead. |
| 16:49 |
VanessaE |
or they shouldm |
| 16:49 |
celeron55_ |
hmm, i see default:mese is now the ore |
| 16:49 |
VanessaE |
yes. |
| 16:49 |
VanessaE |
or rather, it's a bunch of crystals embedded in stone |
| 16:50 |
VanessaE |
which is more or less how you would find them in practice. |
| 16:50 |
VanessaE |
so this way, old maps don't break |
| 16:50 |
VanessaE |
and that alias I had before isn't needed anymore |
| 16:50 |
VanessaE |
breaking old maps is BAD, mmkay? :-) |
| 16:50 |
celeron55_ |
default:mese should now have node_sound_stone_defaults |
| 16:50 |
|
Calinou joined #minetest-dev |
| 16:51 |
VanessaE |
I'll leave it to you to change the sounds, I don't know how those work |
| 16:51 |
celeron55_ |
and default:meseblock too |
| 16:51 |
VanessaE |
(never messed with them - that's why most of homedecor objects sound like leaves or wood :D ) |
| 16:51 |
celeron55_ |
just change the line, how hard can it be? |
| 16:51 |
VanessaE |
but I do agree |
| 16:51 |
VanessaE |
ok, I'll change it. |
| 16:51 |
VanessaE |
sec. |
| 16:51 |
celeron55_ |
the two lines |
| 16:52 |
celeron55_ |
then there is PilzAdam's second point, which should be considered very carefully |
| 16:53 |
celeron55_ |
"default_stone.png^default_mese.png" is simply wrong |
| 16:53 |
celeron55_ |
it must be "default_stone.png^default_mineral_mese.png" or what ever the convention is; that way texture packs won't make it look like a mese block that it isn't |
| 16:54 |
VanessaE |
gotchya. |
| 16:55 |
VanessaE |
hrm |
| 16:55 |
celeron55_ |
but the mese block shouldn't have default_mese.png as the texture (like it now doesn't), because naming conventions are good and texture packs can just supply it doubly if they want to support multiple versions, and falling back to the default one on old packs is fine |
| 16:55 |
celeron55_ |
BUT, default:meseblock should not have default_mese_block.png |
| 16:55 |
celeron55_ |
either meseblock or mese_block; is there a convention for this? |
| 16:56 |
celeron55_ |
hell, steel block is made that way |
| 16:56 |
PilzAdam |
coal_lump |
| 16:56 |
VanessaE |
it seems materialblock is the convention. |
| 16:56 |
VanessaE |
actually strike that |
| 16:56 |
celeron55_ |
"default:steelblock" -> default_steel_block.png 8D |
| 16:56 |
celeron55_ |
that is full of shit |
| 16:56 |
Calinou |
you should change it :P |
| 16:56 |
VanessaE |
looking at my collection of mods, they seem to be more or less evenly divided between XXXblock and XXX_block |
| 16:56 |
PilzAdam |
and the legacy mod grows and grows... |
| 16:56 |
Calinou |
this trolls people who use /give since 2011 |
| 16:58 |
celeron55_ |
i wonder if steelblock or steel_block is the expected name |
| 16:58 |
VanessaE |
tiles = {"default_steel_block.png"}, |
| 16:58 |
Calinou |
steel_block probably |
| 16:58 |
VanessaE |
that's what we have now. |
| 16:58 |
VanessaE |
but, |
| 16:58 |
VanessaE |
minetest.register_node("default:steelblock", { |
| 16:58 |
celeron55_ |
given that there are "default:steel_ingot", "default:clay_brick" and the like, it should be default:steel_block |
| 16:58 |
Calinou |
else steel_ingot would be named steelingot |
| 16:58 |
thexyz |
>naming conventions are good |
| 16:58 |
Calinou |
thexyz: GNOME developers agree! |
| 16:58 |
|
Calinou left #minetest-dev |
| 16:58 |
VanessaE |
so it's without the underscore in the node name, but has an underscore in the texture file. |
| 16:59 |
darkrose |
rename it to block_steel just to confuse people |
| 16:59 |
thexyz |
lua api agrees too |
| 16:59 |
|
Calinou joined #minetest-dev |
| 16:59 |
Calinou |
accidental ctrl+w press |
| 16:59 |
VanessaE |
now about default_stone.png^default_mese.png <--- default_mineral_mese.png is wrong too. |
| 16:59 |
celeron55_ |
minetest is full of things that completely inverses current ways of doing things |
| 16:59 |
VanessaE |
mese crystals in stone isn't a mineral, to name it that way is wrong |
| 17:00 |
celeron55_ |
VanessaE: mineral is close enough |
| 17:00 |
darkrose |
default_crystal_mese.png |
| 17:00 |
VanessaE |
meh |
| 17:00 |
VanessaE |
ok |
| 17:00 |
celeron55_ |
we're programming here, not writing english dictionaries |
| 17:00 |
PilzAdam |
VanessaE, naming conventions are more important than logic |
| 17:00 |
VanessaE |
darkrose: there's already default_mese_crystal.png for the dropped crystal object :-) |
| 17:00 |
VanessaE |
I'll change it to default_mineral_mese.png then |
| 17:00 |
PilzAdam |
VanessaE, btw: the textures are ugly |
| 17:01 |
VanessaE |
PilzAdam: they're better than what we had before. |
| 17:01 |
darkrose |
make mese purple! |
| 17:01 |
PilzAdam |
but not good enough |
| 17:01 |
PilzAdam |
the old mese was so strange that it was funny |
| 17:01 |
celeron55_ |
anyway, it should be default:mese_block, and default:steelblock should be renamed (in an another commit) default:steel_block and an appropriate alias added to minetest_game/legacy |
| 17:01 |
VanessaE |
darkrose: noooooooo! |
| 17:01 |
celeron55_ |
i hope not many mods use the steel block for anything |
| 17:01 |
celeron55_ |
or, more like, guess |
| 17:02 |
VanessaE |
celeron55_: ok, I'll make it mese_block then |
| 17:02 |
PilzAdam |
celeron55_, we will add an alias to legacy so other mods can still use steelblock |
| 17:02 |
darkrose |
eh, modders can just sed the change... it's breaking maps that's problematic |
| 17:02 |
celeron55_ |
PilzAdam: it doesn't work in that direction in every place |
| 17:02 |
|
kosc left #minetest-dev |
| 17:03 |
celeron55_ |
darkrose: map loading takes aliases into account |
| 17:03 |
celeron55_ |
and inventory loading |
| 17:03 |
VanessaE |
darkrose: exactly, and I refuse to break old maps. |
| 17:03 |
celeron55_ |
everything else is somewhat undefined |
| 17:09 |
VanessaE |
celeron55_: how does this look? |
| 17:09 |
VanessaE |
https://github.com/celeron55/minetest_game/pull/65 |
| 17:10 |
VanessaE |
(I've been re-cloning/re-adding changes to keep them condensed into one commit, since I'm not familiar with rebasing) |
| 17:11 |
PilzAdam |
you can craft default:mese? |
| 17:11 |
PilzAdam |
you cant craft the iron and coal in stone |
| 17:11 |
VanessaE |
PilzAdam: a workaround for old mods. |
| 17:11 |
celeron55_ |
now the only problem is the textures 8) |
| 17:11 |
VanessaE |
PilzAdam: so that people can still use them until they're updated. |
| 17:11 |
VanessaE |
celeron55_: hey now, I think the textures look good thank you :-) |
| 17:12 |
VanessaE |
besides, it was either this or go photorealistic ;) |
| 17:12 |
celeron55_ |
there should be a comment above the default:mese recipe |
| 17:12 |
celeron55_ |
saying why it's there |
| 17:13 |
VanessaE |
*cries* |
| 17:13 |
PilzAdam |
what do you do with the fragments? |
| 17:13 |
VanessaE |
your pull request log is gonna hit 100+ before this it done with :D |
| 17:13 |
darkrose |
9 crystals = 1 block, dig the block = get 1 crystal back |
| 17:14 |
VanessaE |
PilzAdam: those are to be used by mods that need mese but don't genuinely need the full power of a mese crystal |
| 17:14 |
celeron55_ |
fragments are good, no need to discuss about them! |
| 17:14 |
darkrose |
oh, no ignore me |
| 17:15 |
PilzAdam |
the fragment looks like a carrot |
| 17:15 |
celeron55_ |
i thought it was a pen |
| 17:15 |
VanessaE |
I've never seen a bright yellow carrot before :-) |
| 17:15 |
celeron55_ |
we need a good pixel artist here, where's cisoun when you need thim? 8) |
| 17:15 |
celeron55_ |
-t |
| 17:15 |
PilzAdam |
rename the description of the fragment to Mese Carrot, eastereggs ftw |
| 17:16 |
Calinou |
we're 4 horrible pixel artists! let's make a better texture |
| 17:16 |
darkrose |
should be purple, that'd solve the carrot problem |
| 17:16 |
Calinou |
PilzAdam: "fragment"... let's rename it to "NTFS Partition" |
| 17:16 |
VanessaE |
darkrose: purple? no, it has to be yellow - for the sake of nostalgia :-) |
| 17:16 |
celeron55_ |
if you write on paper with the mese pen, you get the MESEFS Specification and you can use it on a mesecon hard drive |
| 17:17 |
VanessaE |
hah! |
| 17:17 |
PilzAdam |
VanessaE, is there any reason to spread the definitons over the whole init.lua? |
| 17:17 |
|
nyuszika7h joined #minetest-dev |
| 17:17 |
VanessaE |
PilzAdam: I was trying to keep them more or less grouped with related parts of init.lua |
| 17:17 |
VanessaE |
(except mese block got moved before and no longed needs to be) |
| 17:18 |
PilzAdam |
crystal and fragment could be at the same position |
| 17:19 |
celeron55_ |
the next changelog is going to contain the line "Absolutely perfected MESE Lua definitions" |
| 17:20 |
VanessaE |
*sigh* :-) |
| 17:20 |
VanessaE |
celeron55_: just commit the damn thing and make your texture changes then :-) |
| 17:20 |
celeron55_ |
(by VanessaE, PilzAdam, celeron55, darkrose, Calinou and 10 other contributors) |
| 17:20 |
VanessaE |
lol |
| 17:20 |
|
sema4 joined #minetest-dev |
| 17:20 |
thexyz |
i feel ignored, everybody talks about this mese stuff instead of curl media fetch, which really improves something |
| 17:21 |
VanessaE |
mese is easy to fix :-) |
| 17:21 |
VanessaE |
as long as celeron55 doesn't make me lose all my hair first! |
| 17:21 |
celeron55_ |
thexyz: it's on a tab of my browser, right next to more important things like mese and internet kittens |
| 17:21 |
VanessaE |
:D |
| 17:21 |
thexyz |
sure |
| 17:22 |
PilzAdam |
Mod idea: old_mese |
| 17:24 |
celeron55_ |
thexyz: one thing i saw earlier is that you didn't update clientserver.h with the additional parameter of the... announcement or something |
| 17:24 |
celeron55_ |
it's our only reasonable protocol summary and should be correct 8) |
| 17:25 |
thexyz |
ok, will do |
| 17:25 |
|
SpeedProg1 joined #minetest-dev |
| 17:28 |
Calinou |
talking about announcement, why not remake the MOTD stuff in lua and allow multi-line MOTDs |
| 17:28 |
Calinou |
it's just a message that appears when connecting... very easy to do actually :p |
| 17:29 |
PilzAdam |
how would you save that in minetest.conf? |
| 17:29 |
celeron55_ |
thexyz: i have a TCP socket class hanging around; i guess i'll commit it upstream so somebody can implement a very simple media server with it to the minetest server |
| 17:30 |
thexyz |
i don't think this could be useful, there're already many web http servers |
| 17:30 |
VanessaE |
celeron55_: please push that commit so I can relax :-) |
| 17:30 |
thexyz |
the whole point of this was to reduce server load |
| 17:30 |
Calinou |
PilzAdam: several strings with ""? |
| 17:30 |
thexyz |
*minetestserver |
| 17:30 |
Calinou |
separated with , |
| 17:30 |
celeron55_ |
but it also gets rid of the slowness of the UDP network stack of minetest |
| 17:31 |
celeron55_ |
so there definitely should be an out-of-the-box solution for getting the speed benefit |
| 17:31 |
celeron55_ |
it's just a small additional thread anyway |
| 17:32 |
celeron55_ |
it would be totally insane to not implement it |
| 17:34 |
thexyz |
well, i personally don't really want to do it; anything else about this implementation? |
| 17:35 |
celeron55_ |
you don't have to 8) |
| 17:40 |
celeron55_ |
do you think having 8 threads has any benefit over having, like, 2? |
| 17:40 |
|
doserj joined #minetest-dev |
| 17:41 |
* VanessaE |
looks at her 6-core processor... |
| 17:41 |
VanessaE |
;) |
| 17:41 |
celeron55_ |
...these are i/o threads, you silly |
| 17:42 |
* VanessaE |
looks at her SSD also... ;-) |
| 17:42 |
* PilzAdam |
looks at his 8 core processor |
| 17:42 |
celeron55_ |
VanessaE: they grab stuff over the network |
| 17:42 |
VanessaE |
celeron55_: I'm just kidding, jeez :-) |
| 17:42 |
VanessaE |
ok, time to head out. |
| 17:43 |
VanessaE |
bbl |
| 17:43 |
celeron55_ |
i guess the 8 threads are kind of reasonable when the same http connection isn't reused |
| 17:44 |
thexyz |
celeron55_: nah, just a random number |
| 17:44 |
thexyz |
it is, of course, has benefits over having two |
| 17:49 |
thexyz |
8 threads — 12 seconds, 2 threads — 30 seconds (using minetest_game + ambience) |
| 17:49 |
celeron55_ |
what server? |
| 17:49 |
celeron55_ |
http, that is |
| 17:50 |
thexyz |
nginx/1.2.3, minetest.ru |
| 17:50 |
celeron55_ |
well, whatever; it's because of the overhead of establishing tcp connections compared to file sizes - an another way of fixing it would be to reuse the http connection |
| 17:50 |
celeron55_ |
which curl probably can do too |
| 17:51 |
celeron55_ |
but i guess that doesn't matter too much |
| 17:55 |
celeron55_ |
hmm |
| 17:55 |
celeron55_ |
one thing does come to mind |
| 17:56 |
thexyz |
https://github.com/minetest/minetest/commit/486b40a363716fd0c6c662a3c29030d56c42eaa3 |
| 17:56 |
celeron55_ |
it would be useful if it could download everything from some place and fall back to the classic download (or an another location?) for those that are not found |
| 17:57 |
celeron55_ |
hmm, that wouldn't actually be very hard |
| 17:58 |
celeron55_ |
just have a list of failed downloads in the threads, combine them into core::list<MediaRequest> and send a TOSERVER_REQUEST_MEDIA instead of TOSERVER_RECEIVED_MEDIA |
| 17:59 |
celeron55_ |
there's potential for much awesomeness in this 8) |
| 17:59 |
thexyz |
ok |
| 17:59 |
celeron55_ |
don't do that now |
| 17:59 |
celeron55_ |
unless you want |
| 18:00 |
thexyz |
why not? |
| 18:00 |
celeron55_ |
go ahead then :P |
| 18:00 |
celeron55_ |
no reason other than laziness |
| 18:02 |
celeron55_ |
(there are more ways to extend this too, like sending a list of media locations that would be tried in order (that would allow having a fast centralized repo for stuff and still-quite-fast one for stuff that isn't there); probably useful for some configurations) |
| 18:03 |
celeron55_ |
...that wouldn't be hard either, actually |
| 18:04 |
celeron55_ |
the only nontriviality is that the configuration file format does not natively support lists :P |
| 18:05 |
hmmmm |
std::list Settings::getList("blah") |
| 18:05 |
thexyz |
that also wouldn't be too useful ATM |
| 18:05 |
hmmmm |
parses a comma separated value thing |
| 18:05 |
hmmmm |
"a", "b","c","d" |
| 18:05 |
hmmmm |
what's wrong with that |
| 18:06 |
celeron55_ |
that should allow something more like: a, "b",foo bar, "d" |
| 18:06 |
celeron55_ |
but yeah, not hard |
| 18:06 |
celeron55_ |
just one thing more to be implemented |
| 18:07 |
hmmmm |
should it return a copy of a std::list it creates? |
| 18:08 |
celeron55_ |
well, copies are fine, it's not like a list of things would be requested at a high interval |
| 18:09 |
hmmmm |
i am pretty sure you have ->getStuff() inside of loops |
| 18:09 |
hmmmm |
i dunno, this is just me, but i think g_settings should be made up of actual variables that are retreived upon startup, once, just once |
| 18:10 |
celeron55_ |
settings are always read to variables for tight loops |
| 18:10 |
hmmmm |
tight loops, yes, but in general, not the case from what i've seen |
| 18:10 |
celeron55_ |
hmmmm: it's very useful to change them during runtime and development is much easier when it's completely dynamic |
| 18:11 |
celeron55_ |
you'll have very hard time proving Settings would consume any considerable CPU anywhere |
| 18:12 |
hmmmm |
it kind of rustles my jimmies when i see something like that, though |
| 18:12 |
hmmmm |
can't help it |
| 18:12 |
celeron55_ |
you should code more in dynamic languages 8) |
| 18:12 |
celeron55_ |
a good few thousand lines of python and javascript should make you reasonable 8D |
| 18:12 |
celeron55_ |
few ten thousand* |
| 18:12 |
hmmmm |
i try to avoid anything like that if possible |
| 18:13 |
celeron55_ |
that wasn't hard to guess :-) |
| 18:13 |
hmmmm |
in my code i put a lot of thought into ways of not duplicating work |
| 18:14 |
celeron55_ |
duplicating, in what way? |
| 18:14 |
hmmmm |
dunno, i guess when a bit of code calculates the same exact result as it did previously in most cases |
| 18:15 |
hmmmm |
instead of making the case where it has a different result the exception |
| 18:15 |
celeron55_ |
some people consider the worst duplication being that when you write the same stuff by hand in many places |
| 18:16 |
hmmmm |
well, duplicating source code is bad too, it is the sure mark of a novice |
| 18:16 |
hmmmm |
the golden rule is "don't repeat yourself" |
| 18:16 |
celeron55_ |
anyway, i generally just draw a line at 90% of the computation time of a program and anything that goes under it is optimized enough; no need to optimize them in any other way than making them optimized for writing code |
| 18:19 |
hmmmm |
this happens with bigger applications all the time |
| 18:19 |
hmmmm |
they keep adding small, slow bits to the program that are only, say, 40% slower than another 'optimal' alternative |
| 18:19 |
hmmmm |
and then they keep piling up and piling up and all of a sudden the whole thing is 40% slower |
| 18:19 |
celeron55_ |
of course sometimes when you go and optimize the one using 50% of time, some of the 10% will become more than 10% and then they need to be reconsidered once again |
| 18:19 |
hmmmm |
and you can't fix it either because it's too late because the slowness is absolutely everywhere |
| 18:20 |
celeron55_ |
well, there needs to be some fixed standard of "good enough" |
| 18:20 |
hmmmm |
of course |
| 18:21 |
hmmmm |
i get stuck on details like this all the time and i hardly ever finish my own projects |
| 18:21 |
celeron55_ |
better of which is wasted work and worse of which is a cpu bottleneck |
| 18:21 |
hmmmm |
(or i get bored) |
| 18:21 |
sema4 |
don't you know the two things about optimization? 1) never optimize 2) optimize only when you have to :) |
| 18:21 |
hmmmm |
that's absolutely retarded |
| 18:22 |
celeron55_ |
i know, and it pisses off people like hmmm 8) |
| 18:22 |
hmmmm |
always optimize, when you can |
| 18:22 |
Calinou |
sema4: buy us a xeon then :P |
| 18:22 |
hmmmm |
it's usually not hard to optimize |
| 18:22 |
hmmmm |
just don't do stupid stuff |
| 18:22 |
celeron55_ |
"don't do stupid stuff" is a good rule |
| 18:22 |
hmmmm |
you guys make it sound like "oh, well optimizing, gonna have to sit down for an hour and figure out how to make minute improvements" |
| 18:23 |
hmmmm |
i think i can sum my point up this way: |
| 18:23 |
celeron55_ |
sometimes people have come here and told something has to be optimized that doesn't make any sense at all |
| 18:24 |
sema4 |
well i guess it's a difference of always writing optimial code by default vs eeking out extra cycles in a chunk of code |
| 18:24 |
hmmmm |
write good code the first time and you won't have to 'optimize' |
| 18:26 |
sema4 |
yeah i think "the two things" adage depends on what you just said, hmmmm |
| 18:26 |
* sema4 |
shrugs |
| 18:27 |
hmmmm |
i'll admit that when i was younger i used to do stupid things like initialize variables by doing int i = i^i;, which would fall under your first of the "two things" |
| 18:27 |
hmmmm |
if you frame it in that context, i guess it makes more sense |
| 18:28 |
celeron55_ |
there is no silver bullet, but rather a rather finite list of things to get right |
| 18:29 |
celeron55_ |
to me, interfaces are always the most important thing |
| 18:29 |
celeron55_ |
as long as an interface is good, you can always rewrite either side of it |
| 18:42 |
|
jin_xi joined #minetest-dev |
| 18:43 |
thexyz |
celeron55_: https://github.com/minetest/minetest/commit/d3325834bb2346d991439d56dd3a309174d1920d |
| 19:03 |
|
sema4 joined #minetest-dev |
| 19:39 |
|
Taoki joined #minetest-dev |
| 19:54 |
thexyz |
celeron55_: https://github.com/celeron55/minetest/pull/354 |
| 20:40 |
|
rsiska joined #minetest-dev |
| 21:14 |
VanessaE |
back... |
| 22:07 |
|
cy1 joined #minetest-dev |
| 22:18 |
PilzAdam |
celeron55_, you deleted my commit that all dropped items are 3D; Minecraft has added this in the latest snapshot: http://youtu.be/beCgkWkULrA?t=7m17s |
| 22:19 |
hmmmm |
you really want to extrude all items like that!? |
| 22:19 |
hmmmm |
that can be really slow if there are lots of transparent pixels |
| 22:19 |
hmmmm |
think of how many verticies you'd have to define |
| 22:20 |
celeron55_ |
PilzAdam: i saw that today; this makes me want to never ever do that |
| 22:56 |
|
sema4 joined #minetest-dev |
| 23:09 |
cy1 |
celeron55_: nice |
| 23:53 |
|
sema4 joined #minetest-dev |
