| Time |
Nick |
Message |
| 00:01 |
|
nm0i joined #minetest |
| 00:04 |
|
nm0i joined #minetest |
| 00:25 |
|
Lesha_Vel joined #minetest |
| 01:00 |
|
Niklp joined #minetest |
| 01:00 |
|
smk joined #minetest |
| 01:25 |
|
YuGiOhJCJ joined #minetest |
| 01:53 |
|
MTDiscord joined #minetest |
| 02:50 |
|
v-rob joined #minetest |
| 03:09 |
|
amfl2 joined #minetest |
| 03:19 |
|
fluxionary_ joined #minetest |
| 03:52 |
|
Talkless joined #minetest |
| 03:54 |
hare_hare_yukai |
imagine a parody called MeinKraft |
| 03:54 |
hare_hare_yukai |
with germany and nazi memes |
| 03:54 |
hare_hare_yukai |
that would be funny eh lissobone? |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:00 |
[MTMatrix] |
<Blockhead256> https://www.youtube.com/watch?v=-1yzoiUIGGs |
| 04:01 |
hare_hare_yukai |
https://vndb.org/v7316 |
| 04:01 |
hare_hare_yukai |
https://vndb.org/v19616 |
| 04:24 |
|
vampirefrog joined #minetest |
| 04:49 |
hare_hare_yukai |
https://files.catbox.moe/y3y8vx.png |
| 05:34 |
|
TheCoffeMaker joined #minetest |
| 05:51 |
|
TomTom joined #minetest |
| 05:59 |
|
fling joined #minetest |
| 06:07 |
|
v-rob joined #minetest |
| 06:11 |
|
mrkubax10 joined #minetest |
| 06:22 |
|
TheCoffeMaker joined #minetest |
| 06:46 |
|
calcul0n joined #minetest |
| 07:01 |
|
sid0 joined #minetest |
| 07:16 |
|
Alnotz joined #minetest |
| 07:56 |
|
TheCoffeMaker joined #minetest |
| 08:16 |
|
syl joined #minetest |
| 08:49 |
|
appguru joined #minetest |
| 08:54 |
|
appguru joined #minetest |
| 08:55 |
|
mrkubax10 joined #minetest |
| 09:32 |
|
calcul0n joined #minetest |
| 09:38 |
|
TheCoffeMaker joined #minetest |
| 09:50 |
|
TheCoffeMaker joined #minetest |
| 10:07 |
|
TheCoffeMaker joined #minetest |
| 10:24 |
|
TheCoffeMaker joined #minetest |
| 10:32 |
|
s20 joined #minetest |
| 10:47 |
|
TheCoffeMaker joined #minetest |
| 11:05 |
|
TheCoffeMaker joined #minetest |
| 11:23 |
|
calcul0n joined #minetest |
| 11:46 |
|
Zambyte joined #minetest |
| 12:09 |
|
Trifton_ joined #minetest |
| 12:14 |
|
appguru joined #minetest |
| 12:21 |
erle |
luatic did you file the bad apple thing as a bug? |
| 12:50 |
|
definitelya joined #minetest |
| 12:58 |
|
calcul0n joined #minetest |
| 13:29 |
MTDiscord |
<luatic> no, but i may in about 2 days |
| 13:30 |
|
appguru joined #minetest |
| 13:41 |
|
calcul0n_ joined #minetest |
| 13:47 |
|
Sobinec joined #minetest |
| 13:53 |
|
fling joined #minetest |
| 13:53 |
erle |
luatic when enough dirt has accumulated? :D |
| 14:10 |
MTDiscord |
<luatic> erle: hehe |
| 14:10 |
MTDiscord |
<luatic> currently the memory doesn't like me (it segfaults) |
| 14:11 |
MTDiscord |
<luatic> will make it easier to report though, i suppose |
| 14:14 |
erle |
luatic what do you mean |
| 14:14 |
erle |
luatic have you tried using ubsan or asan |
| 14:14 |
erle |
or tsan or msan |
| 14:14 |
MTDiscord |
<luatic> i haven't, but i will probably |
| 14:15 |
MTDiscord |
<luatic> is there something like a compiler line you could drop me with all the sanitizers enabled? :D |
| 14:15 |
erle |
no, because that is a stupid thing to do |
| 14:16 |
MTDiscord |
<luatic> why? performance? |
| 14:16 |
|
e1z0 joined #minetest |
| 14:17 |
erle |
https://lists.llvm.org/pipermail/llvm-dev/2016-March/097144.html |
| 14:18 |
erle |
luatic i suggest to read up on how the sanitizers work and you will probably figure it out yourself |
| 14:19 |
erle |
it will also help you to interpret the output correctly |
| 14:19 |
MTDiscord |
<luatic> I have a feeling that sanitizers are implemented poorly |
| 14:20 |
erle |
is your spidersense telling you that? |
| 14:20 |
MTDiscord |
<luatic> yes, it's tingling |
| 14:20 |
MTDiscord |
<luatic> like i imagine i could write an interpreter for C which checks for all of these with maybe a ~10x interpretation overhead |
| 14:21 |
erle |
in interpreter for C, curious |
| 14:21 |
erle |
C, the famously interpreted language |
| 14:21 |
MTDiscord |
<luatic> i've also seen detectable illegal behavior in zig and it doesn't make me choose between detecting some illegal behavior or detecting other illegal behavior |
| 14:22 |
MTDiscord |
<luatic> so this seems like a shortcoming so far and i'm not sure what induces it; i will have to read up on it |
| 14:22 |
erle |
what's detectable illegal behaviour? |
| 14:24 |
MTDiscord |
<luatic> stuff that usually is just undefined behavior in C, but which in zig debug builds is well, detectable |
| 14:24 |
MTDiscord |
<luatic> such as accessing an inactive variant of a union |
| 14:26 |
erle |
look just start with ubsan right? |
| 14:27 |
MTDiscord |
<luatic> ok |
| 14:27 |
MTDiscord |
<luatic> still i will look into how sanitizers work and whether it could be done better ;) |
| 14:27 |
MTDiscord |
<luatic> the "red zone" approach for example seems pretty rudimentary to me |
| 14:27 |
erle |
how would you do it |
| 14:29 |
MTDiscord |
<luatic> i'd roughly attach metadata (such as array bounds) to pointers, and then do bounds checks; propagating the metadata may prove tricky however |
| 14:31 |
erle |
is that a thing you actually plan to do or is it about as real as SSCSMs? :P |
| 14:31 |
|
appguru joined #minetest |
| 14:33 |
erle |
i should probably add “progress is not possible without SSCSMs” to my list of common noob utterings hehe :D |
| 14:33 |
MTDiscord |
<luatic> about as real as SSCSMs |
| 14:33 |
lissobone |
I want to add an audiochat to minetest. |
| 14:34 |
MTDiscord |
<luatic> erle: it's imo pretty true, though; if we want to grow up to be a real game engine, we need a fully scriptable client, and that can only be achieved well with SSCSMs |
| 14:34 |
erle |
lissobone use mumble + 3d position CSM ig |
| 14:35 |
MTDiscord |
<luatic> i considered writing snake in LÖVE and Minetest just to drive this point home, but after writing it in LÖVE in ~1h (mind you, i had not used LÖVE before), i had absolutely zero motivation to do it in Minetest too |
| 14:36 |
erle |
try writing snake in svg |
| 14:36 |
MTDiscord |
<luatic> it would have been possible somewhat half-janky using HUDs / dynamic media / nodes / whatever, but it would've been much more work yet much more jank - simply strictly suboptimal for this simple purely clientside game! |
| 14:36 |
MTDiscord |
<luatic> erle: is svg turing-complete, or would i have to hardcode an obscene number of possible game states or abuse obscure features that are suspiciously useful for implement snake? |
| 14:38 |
erle |
no idea |
| 14:38 |
erle |
look at the source of this https://upload.wikimedia.org/wikipedia/commons/4/44/Balance_puzzle_SMIL.svg |
| 14:39 |
erle |
or this lol https://upload.wikimedia.org/wikipedia/commons/4/4d/Subtraction_game_SMIL.svg |
| 14:40 |
MTDiscord |
<luatic> lol |
| 14:40 |
erle |
or this https://upload.wikimedia.org/wikipedia/commons/9/9b/SMIL_missile_demo.svg |
| 14:41 |
erle |
i think “we need client side scripting” is not necessarily web developer brainrot, but surely inspired by it :P |
| 14:42 |
erle |
you can do a lot without turing-complete input languages |
| 14:42 |
MTDiscord |
<luatic> the rockets are not randomized... |
| 14:43 |
MTDiscord |
<luatic> erle: it's generally more work though |
| 14:43 |
erle |
surprise, not taking the ”everything turing complete” escape hatch is work |
| 14:43 |
erle |
compare websites that have CSS layout with websites that do layout in JS |
| 14:43 |
erle |
i mean, the latter are slow on every computer |
| 14:43 |
erle |
no amount of CPU is going to beat accidentally quadratic bullshit |
| 14:43 |
MTDiscord |
<luatic> yes, what should this work be made for? for security, it imo suffices to just (1) use a safe interpreter (write a simple scheme yourself if necessary); (2) validate all API calls very strictly |
| 14:44 |
rubenwardy |
CSS layouting is done by a turing complete language |
| 14:44 |
erle |
have you read the seven turrets of babel? |
| 14:44 |
erle |
if not, read it |
| 14:44 |
erle |
it's about turing complete *input languages* |
| 14:44 |
rubenwardy |
also, CSS is turing complete |
| 14:44 |
erle |
rubenwardy show and tell? |
| 14:45 |
erle |
i saw that claim repeated, but i think it needs a turing complete user |
| 14:45 |
MTDiscord |
<luatic> i definitely wouldn't bet on CSS layouting being linear |
| 14:45 |
MTDiscord |
<luatic> (linear time) |
| 14:45 |
MTDiscord |
<luatic> it's also much more intransparent than if i write code myself |
| 14:45 |
erle |
lol |
| 14:45 |
erle |
as olialina explained in her essay, a lot of systems become more powerful with a turing complete user |
| 14:46 |
MTDiscord |
<luatic> i have to trust the CSS layouting algo to be decent, whereas if i write imperative code myself i can ensure my algo is decent |
| 14:46 |
MTDiscord |
<luatic> yeah, SSCSMs would give modders a lot of power |
| 14:46 |
MTDiscord |
<luatic> many of them, esp. the noobs, won't wield this properly, but that is not a reason to not give it to the experienced modders :) |
| 14:46 |
erle |
lol |
| 14:47 |
erle |
“surely i am pure and will not abuse this power, or write code that runs on my computer, but not on a slower one” |
| 14:47 |
MTDiscord |
<luatic> indeed i am renowned for being the perfect programmer; it is virtually impossible that i write suboptimal code /s |
| 14:48 |
erle |
great, can you write my code too? |
| 14:48 |
MTDiscord |
<luatic> erle: if it's interesting enough, maybe |
| 14:48 |
erle |
anyways, i have yet to see CSM code that is both very useful and would be sent by a server |
| 14:48 |
MTDiscord |
<luatic> part of the problem is that our CSM API is shit |
| 14:48 |
erle |
i think lizzys server ticks thing is probably the only one i can remember |
| 14:48 |
|
jaca122 joined #minetest |
| 14:48 |
erle |
and that one can very simply be added to the client |
| 14:49 |
MTDiscord |
<luatic> as for "would be sent by a server": that's just for convenience so that we can continue our model of "you can just connect to servers and it works" |
| 14:49 |
rubenwardy |
see https://github.com/minetest/minetest/issues/8057 |
| 14:49 |
erle |
luatic you know that it results in “you have to run this CSM or you are not allowed on this server” and then the CSM starts mining bitcoins or other room-heating activities |
| 14:50 |
MTDiscord |
<luatic> i wonder whether i would be able to write a safe lua interpreter |
| 14:50 |
MTDiscord |
<luatic> most probably not, but lua 5.1 is small enough that there's a tiny chance that it could work |
| 14:50 |
erle |
the thing most often suggested is predicting movement client-side and i am pretty sure other engines just send like, a path to follow or so |
| 14:50 |
MTDiscord |
<luatic> erle: mining bitcoins is legit CSM behavior imo :) |
| 14:50 |
erle |
which btw minetest could also do |
| 14:50 |
celeron55 |
erle: just like websites do? wait, none of them do, of the ones you actually want to use |
| 14:51 |
erle |
celeron55 pretty sure that ”displaying obnovious ads” is also a thing that heats up my computer and makes it slow. i can not watch youtube videos on youtube on the thing i am writing from, but i can watch them on invidious or download them using youtube-dl and use mplayer. |
| 14:52 |
erle |
like, the computer is obviously fast enough to display videos, but the youtube bullshit makes it crawl to a halt |
| 14:52 |
MTDiscord |
<luatic> erle: The "engines" / "frameworks" (besides Minetest) I've used so far let you write client and server yourself. |
| 14:54 |
MTDiscord |
<luatic> The default "mode of operation" for most actual engines I've seen is "you build a client-side game". You can add a server to that later on if you wish. |
| 14:54 |
erle |
is that all web stuff? |
| 14:55 |
MTDiscord |
<luatic> no, I'm mostly thinking Pygame, LÖVE here |
| 14:55 |
celeron55 |
i still see it as a valid path in my mind to limit SSCSM into very small lua environments with very limited interfaces, only to allow doing stuff like vehicle specific physics and let's say custom 2D visuals or some such, which are then triggered by messages from the server |
| 14:55 |
celeron55 |
i think everyone should consider this option |
| 14:55 |
MTDiscord |
<luatic> Looking at perhaps the closest thing to Minetest - Roblox, which also does servers and clients for you - they also have client side scripting. |
| 14:55 |
erle |
celeron55 the thing is, if it is that limited, then i'm pretty sure there is nicer solution |
| 14:56 |
MTDiscord |
<luatic> (I don't know much about Roblox though. It's just that Roblox kids are a frequent occurrence on Lua forums now.) |
| 14:56 |
celeron55 |
erle: the only way you can prove it is to design it yourself |
| 14:56 |
MTDiscord |
<luatic> erle: well, it isn't that limited; we don't know what people want or will want to do with Minetest |
| 14:56 |
celeron55 |
erle: no other engine faces the same challenge as MT does. they all run game specific code on the client for these purposes |
| 14:57 |
MTDiscord |
<luatic> this ^ |
| 14:57 |
erle |
i don't know everything about openRA but i am pretty sure they have a declarative format of “traits” that are specified in an engine-version |
| 14:58 |
MTDiscord |
<luatic> Minetest's "the client is a sockpuppet of the server except for hardcoded features" is pretty unique in the engine space, I think |
| 14:58 |
celeron55 |
erle: i'm pretty sure if you make a game in openRA, you have to have a specific client build of it in order to play |
| 14:59 |
erle |
yeah, like with minetest |
| 14:59 |
erle |
not? |
| 14:59 |
erle |
the client has to understand the specific traits |
| 14:59 |
erle |
maybe i am wrong here, but i mean like “what kind of order can i give to this unit” |
| 15:00 |
celeron55 |
if you make the traits flexible enough, you essentially end up with tiny lua scripts |
| 15:00 |
celeron55 |
that is what i am proposing |
| 15:00 |
celeron55 |
make traits that are definable as small scripts |
| 15:00 |
MTDiscord |
<luatic> here's another thing i wanted to run on the client: character animations; they're much jankier if serverside |
| 15:00 |
celeron55 |
and send them as such over to the client |
| 15:01 |
erle |
celeron55 the traits are more like “which hardcoded attack behaviour is used” or “can this unit teleport” or “which cursor is displayed when hovering over a valid target” https://docs.openra.net/en/release/traits/ |
| 15:01 |
MTDiscord |
<luatic> CSMs may also allow offloading rendering work to the client. Consider your last mod, erle: It shouldn't be the server's business to render the text to a texture. Ideally the server could just send the text, and tell the client to render it. With a SSCSM, that would be possible. |
| 15:01 |
erle |
it turns out that the traits in openra are amazingly flexible, as in that some mods are just a bunch of yaml files and assets and totally change gameplay |
| 15:02 |
celeron55 |
totally change gameplay? i don't believe that |
| 15:02 |
erle |
like, i implemented a submarine for example once |
| 15:02 |
rubenwardy |
SSCSM combined with a new GUI/rendering API would allow for a wide range of possibiliities for GUIs |
| 15:02 |
celeron55 |
that's not a total change in gameplay |
| 15:02 |
erle |
by making an “activate” action and changing the activated state |
| 15:02 |
erle |
so that the submarine is underwater (different texture) |
| 15:02 |
celeron55 |
if you make a first person shooter or a visual novel with 3d animations in OpenRA, then i believe you |
| 15:02 |
erle |
and in that state it has different detection capabilities and is invisible |
| 15:03 |
celeron55 |
or at least a platformer |
| 15:03 |
erle |
i concede and assert the opposite, a non-total change in gameplay |
| 15:03 |
MTDiscord |
<luatic> first person shooters are a good example; they need much custom logic, and you want instant responses (client prediction) because everything tends to go fast in these |
| 15:03 |
erle |
yeah so if i go along with your point, why is there no main menu CSM tab? |
| 15:03 |
erle |
i mean that would at least be a starting point |
| 15:03 |
erle |
to expose it to more users |
| 15:04 |
MTDiscord |
<luatic> last time i tried to make a weapon mod i was fed up by even basically trivial things such as achieving a square HUD image with a scale relative to screensize being impossible |
| 15:04 |
erle |
also CSMs on CDB when lol |
| 15:04 |
rubenwardy |
because we want sscsm not csm |
| 15:04 |
erle |
rubenwardy ah, the users do not own their computronium! |
| 15:04 |
erle |
:D |
| 15:04 |
celeron55 |
i propose deleting the current CSM and beginning from scratch, to only allow SSCSM in small environments |
| 15:05 |
erle |
i do not see how SSCSM without an intermediate step of first-class CSMs can be viable, unless the wisdom of “how to design a CSM API well” falls from the sky somehow |
| 15:05 |
celeron55 |
i can design all the apis, that's a total non-issue 8) but i won't implement it |
| 15:06 |
erle |
celeron55 so why not expand the CSM API with downloadable CSMs from CDB and see what is actually used? |
| 15:06 |
erle |
like “movement prediction CSM” or so |
| 15:06 |
celeron55 |
because i think the current CSM API has a too large attack surface to be used for SSCSM without process level sandboxing |
| 15:06 |
MTDiscord |
<luatic> that's turee |
| 15:06 |
MTDiscord |
<luatic> throw it out the window |
| 15:06 |
celeron55 |
i want to either get rid of it, or to have process level sandboxing |
| 15:06 |
celeron55 |
only two options |
| 15:06 |
erle |
i mean web browsers do it |
| 15:07 |
erle |
stuff like <video> or <details> was added after flash or javascript added that |
| 15:07 |
celeron55 |
CDB CSMs are not an option to me, it goes against the core point of MT |
| 15:07 |
erle |
celeron55 sandboxing as in ”script can not affect the local environment” ? |
| 15:07 |
celeron55 |
if everybody insist on them and they are implement, i'll let it pass, but i will not help |
| 15:07 |
celeron55 |
implemented* |
| 15:07 |
erle |
well CSMs have so far been used for a bunch of non-cheaty purposes. like encrypted chat messages (which are obviously not possible securely if the server can just replace the CSM) |
| 15:08 |
erle |
or the thing where you see if someone targets you (by examining the view direction and figuring out if it intersects you hehe) |
| 15:09 |
erle |
or building without cheating yourself the materials, i.e. you have all the cobble and so on and already made the blueprints |
| 15:09 |
celeron55 |
leaving CSMs to be CSMs is fine to me also. but then people have to learn to distinguish between CSM and the-other-thing (let's call it programmable traits, or some such) |
| 15:13 |
celeron55 |
i have made a proof of concept of this, it's here https://github.com/minetest/minetest/compare/master...celeron55:minetest:client_player_physics_script |
| 15:15 |
|
appguru joined #minetest |
| 15:16 |
celeron55 |
as you can tell, i am not in a hurry |
| 15:18 |
erle |
celeron55 i see, it is for controlling, not only for prediction |
| 15:18 |
celeron55 |
well that is only the player physics trait, if you let my borrow that term from you |
| 15:19 |
celeron55 |
you obviously want to have the direct player input at your disposal, to get fast feedback to the player |
| 15:19 |
celeron55 |
me* |
| 15:20 |
erle |
the openra way here would probably be to preload the engine wtih a bunch of heavily-tested traits and only allow the server to specify which one |
| 15:20 |
celeron55 |
but there would be similar mini environments for some sort of hud stuff, and animations, or however we would happend to decide on allocating the apis |
| 15:21 |
erle |
with physics in particular i do wonder though what pitfalls exist for implementing this horribly |
| 15:21 |
celeron55 |
maybe one for dynamic sound generation |
| 15:21 |
celeron55 |
not sure what they would be, but that's the concept |
| 15:21 |
erle |
that one is easy, you have a tight instruction budget, no branching and your code has to deliver one sample (or a bunch of them) per time unit. like shaders. |
| 15:22 |
erle |
“easy” as in, easy to conceptually make it not very powerful for any other purpose than you want to have it |
| 15:22 |
erle |
i.e. lock it down |
| 15:22 |
MTDiscord |
<fatalisterror> What about sscsm? |
| 15:22 |
erle |
i have to go. i'll be back in a few days ig |
| 15:22 |
celeron55 |
shaders do have branching |
| 15:23 |
celeron55 |
and if you want to disallow loops, you also have to disallow functions to avoid infinite recursion and such. i am open to discussing about that and figuring out a way to do it |
| 15:23 |
erle |
sorry, i thought of no unconstraint loooping |
| 15:24 |
erle |
branching is easy because you can employ math trickery anyway |
| 15:24 |
celeron55 |
maybe lua isn't the right choice and a less flexible language would have to be used |
| 15:24 |
erle |
regarding loops: on the hardware i use (intel GPU) all loops are unrolled lol |
| 15:24 |
erle |
in shaders |
| 15:24 |
erle |
which kinda makes sense, given there is an instruction budged |
| 15:26 |
celeron55 |
the thing about these is, they wouldn't be run in any process sandbox or even a separate thread, which means they truly can block execution and ruin your day, if they have the capability to do so. if lua was used, then using threads would probably be required, in order to be able to catch infinite loops and stop them |
| 15:26 |
celeron55 |
however if they run in a thread, you get additional delay |
| 15:26 |
erle |
“be able to catch infinite loops and stop them” |
| 15:27 |
celeron55 |
i would like it if they were synchronous and instantious. it would make them simple and provide instant feedback to the player, not some thread-delayed buffered feedback |
| 15:27 |
erle |
i should re-read on computable numbers, with an application to the entscheidungsproblem |
| 15:27 |
erle |
i think it would probably be a good idea to figure out how other engines do it |
| 15:27 |
celeron55 |
there is no other engine with this problem like i already said, you will not find good examples |
| 15:28 |
celeron55 |
minetest is completely novel in this aspect |
| 15:28 |
celeron55 |
we're literally making an invention here, have been for a long time already |
| 15:28 |
erle |
i am pretty sure i have seen a lot of roguelike stuff that is just dumb terminals, but i also think it does not count |
| 15:29 |
erle |
anyway, i have to get that TGA stuff fixed first before i commit to anything else. because it can not stay insecure. also i have to go. was nice chatting, see ya in a few days! |
| 15:29 |
celeron55 |
(and as with most inventions, we'll probably be dead by the time the invention actually gets widespread use) |
| 15:30 |
erle |
the most things i want out of minetest is a) keep running on whatever computers i have that it already runs on b) not break my mods |
| 15:30 |
erle |
feature-wise i'm probably happier than most, because i am a slob |
| 15:30 |
erle |
my legos also don't have shaders |
| 15:35 |
MTDiscord |
<fatalisterror> SSCSM would absolutely change gameplay celeron55. Vehicles? My mod, for example, 4dguns being perfectly smooth? If we had access to camera matrix we literally could have full control over the camera with perfect smoothness. If we added sscsms with an entity API (which likely wouldnt be difficult), it would absolutely change gameplay. I agree by itself it doesnt do a lot, but the lengths ive had to go through to make 4dguns, and |
| 15:35 |
MTDiscord |
its this choppy still? Is ridiculous. Gunplay like in 4dguns with clientside support would be absolutely gorgeous. Can you imagine adding cars to MT? Bikes? Wall jumping? |
| 15:36 |
MTDiscord |
<fatalisterror> Totally disagree that it wouldnt change anything |
| 15:39 |
erle |
fatalisterror but would you prefer an engine that just gives you a vehicle trait so you don't have to worry about it? |
| 15:39 |
erle |
where you can set the static capabilities? |
| 15:39 |
erle |
(that does not enable walljumps most likely) |
| 15:40 |
|
olliy1or joined #minetest |
| 15:41 |
celeron55 |
i want to enable as much creativity as possible. engine-defined traits will never do that |
| 15:42 |
celeron55 |
but it has to be within a reasonable secure framework. it wouldn't provide all the apis you can imagine. only very specific ones that give the most bang for the buck in terms of improving responsiveness |
| 15:42 |
celeron55 |
and improving customizability |
| 15:43 |
celeron55 |
anything that can be reasonable implemented using server side apis, would stay server side |
| 15:43 |
celeron55 |
reasonably* |
| 15:45 |
MTDiscord |
<landarvargan> My current interest in SSCSM is network optimization. AFAIK HUDs are really good at clogging up the server<->client packet stream, and things like CTF's sprint HUD could be done entirely in CSM, because it's just changing the HUD at a set interval on AUX press/release |
| 15:47 |
|
olliy joined #minetest |
| 15:47 |
celeron55 |
doing custom instantaneous graphics on the screen based on local input fits my requirements |
| 15:48 |
celeron55 |
like, especially HUD stuff. it's super simple |
| 15:49 |
celeron55 |
3D stuff might require a vast API that's questionable from a security standpoint |
| 15:50 |
celeron55 |
2D stuff basically requires only a few primitives, and it would run every frame with no engine-provided object management |
| 15:50 |
erle |
like SVG with templates for inserting stuff or so |
| 15:54 |
celeron55 |
i don't know, like just functions for drawing pixels, triangles, images and text, and that's it. what's to be figured out is whether the mini environments would have a message exchange system between them or if they'd only accept custom messages from the server. there's a lot to design. don't do it now |
| 15:56 |
erle |
i think you could probably prototype that as a CSM using the CSM server-client message channel? |
| 15:56 |
erle |
no idea |
| 15:56 |
erle |
anyway |
| 15:56 |
erle |
see ya |
| 15:58 |
celeron55 |
well you don't have the necessary apis available i believe |
| 15:59 |
celeron55 |
and i believe it is not wise to start adding these onto the current CSM implementation, because it will get people stuck on that insecure platform |
| 16:07 |
|
appguru joined #minetest |
| 16:10 |
|
doseijin joined #minetest |
| 16:29 |
|
pounce joined #minetest |
| 16:29 |
|
v-rob joined #minetest |
| 16:29 |
|
mrkubax10 joined #minetest |
| 16:35 |
muurkha |
erle: shaders do have unconstrained looping, if by that you mean while loops |
| 16:36 |
erle |
muurkha not on my hardware, they become very slow after a finite amount of loops! |
| 16:36 |
erle |
limited instruction budget per frame i assume |
| 16:38 |
muurkha |
luatic: you may be interested in the purecap build of CheriBSD for CHERI, which checks pointer bounds in hardware on Morello. the problem with fat pointers is that they break the ABI |
| 16:44 |
muurkha |
there have been a series of fat-pointer implementations in GCC over the years, but with shared libraries you'd want to build the whole distro with them, and I haven't seen anybody do that |
| 16:47 |
muurkha |
part of the issue is that the C standard legalizes kind of a lot of pointer arithmetic, including things more conservative languages wouldn't. given struct { int i[10], j, k; } x[10]; I believe it is valid to access x[2].j as x[0].i[&x[3].j - x[3].i + x[4].i - x[2].i], for example |
| 16:47 |
muurkha |
you have to be able to memcpy structs, and I think you have to be able to recover pointers after casting them to and from intptr_t, if that's defined |
| 16:49 |
jonadab |
C is inherently, by design, a systems language, meant for implementing things like boot loaders and kernels. |
| 16:49 |
muurkha |
the preliminary CHERI report suggests that Morello uses about 15% more clock cycles, but that some fixes should reduce this below 5% |
| 16:49 |
jonadab |
And it was meant to be able to do that decades ago, when computers had a LOT less memory (and system resources generally). |
| 16:49 |
jonadab |
So it kind of had to be pretty low-level. Goes with the territory. |
| 16:50 |
muurkha |
jonadab: that's sort of true, in that the criterion for its success was whether Thompson was willing to rewrite the kernel in it, but in 6th Edition Unix it was also the main applications language, and continued to be that up through the end of the millennium |
| 16:51 |
jonadab |
It was and is used for that _also_ yes. |
| 16:51 |
muurkha |
languages like C at the time were well-accepted for applications software, but not for boot loaders and kernels |
| 16:51 |
muurkha |
the key innovation of C was that it was broadly enough applicable to also extend to most of the things you would normally write in assembly |
| 16:51 |
jonadab |
But languages like lisp were _also_ used for application development. Not so much for boot loaders and kernels. |
| 16:52 |
muurkha |
Lisp was not considered practical for application development by anything but a small lunatic fringe at the time |
| 16:52 |
muurkha |
(who were also writing their boot loaders and kernels in it!) |
| 16:52 |
jonadab |
Wait, really? |
| 16:52 |
jonadab |
They wrote boot loaders and kernels in lisp? |
| 16:52 |
muurkha |
yeah, the MIT CADR was maybe the most notable example, but then two companies spun off |
| 16:52 |
jonadab |
How did I not know this? |
| 16:53 |
jonadab |
Fascinating. |
| 16:53 |
jonadab |
I stand corrected, and somewhat in awe. |
| 16:53 |
muurkha |
Symbolics and Lisp Machine Inc. TI also made a product |
| 16:53 |
muurkha |
they even wrote their microcode in Lisp |
| 16:53 |
* jonadab |
boggles |
| 16:53 |
jonadab |
Microcode. |
| 16:54 |
muurkha |
regular working programmers at the time, at banks and stuff, were writing transaction processing systems in assembly languages |
| 16:54 |
jonadab |
Next you'll be telling me somebody has written a 3D graphics engine in postscript. |
| 16:54 |
muurkha |
I've written a parametric CAD system in PostScript but it's 2D |
| 16:54 |
jonadab |
Yes, I'm aware of the larger role assembly language had in the early days. |
| 16:54 |
jonadab |
Mainly due to a general dearth of higher-level languages on most platforms. |
| 16:55 |
muurkha |
I would say it was due to a dearth of better *low*-level languages like C. |
| 16:55 |
jonadab |
Because they still needed to be developed. |
| 16:55 |
jonadab |
I meant higher-level than assembly. Which C _arguably_ is. |
| 16:55 |
muurkha |
When I started working as a programmer in 01996 there was still the mentality that Serious Software was written in C (or C++) |
| 16:56 |
muurkha |
garbage collection became reasonably efficient in the mid-90s but most programmers had no idea of this until about 02002 when Java finally beat out C++ |
| 16:56 |
jonadab |
Heh. |
| 16:56 |
jonadab |
Java performance was pretty poor in the nineties. |
| 16:56 |
jonadab |
At least on consumer-grade hardware of the time. |
| 16:57 |
muurkha |
yeah, but all the C++ programmers I worked with in '96 were convinced that it was going to be the next big language for application software |
| 16:57 |
muurkha |
we built the Web on the back of Perl (garbage-collected in a particularly lame way) but it took a long time for that to get accepted |
| 16:57 |
jonadab |
Java isn't just high level though, it's also VM-based. |
| 16:57 |
jonadab |
You can have a language with higher-level data structures than what C normally uses, and still compile it to machine code. |
| 16:57 |
muurkha |
Yeah, although there is a lot of blurriness there |
| 16:58 |
muurkha |
Android software written in Java gets compiled to native binaries these days, and GCJ has been around since the 90s |
| 16:58 |
jonadab |
Not sure I'd really consider reference counting to be garbage collection, although it serves much the same purpose. |
| 16:58 |
jonadab |
It doesn't have cycles, though. |
| 16:58 |
muurkha |
Garbage collection researchers do. |
| 16:58 |
jonadab |
Hmm, ok. |
| 16:58 |
muurkha |
And a lot of Smalltalk VMs used it exclusively in the 80s |
| 16:59 |
muurkha |
the JVM doesn't have a normal bytecode interpreter any more |
| 16:59 |
muurkha |
what it calls the "interpreter" is actually a super dumb JIT compiler to native code |
| 16:59 |
muurkha |
I mean the HotSpot JVM in the JDK |
| 16:59 |
jonadab |
I have no experience with and little knowledge of Smalltalk, though of course I've heard about it. |
| 16:59 |
muurkha |
and an awful lot of Java software in the early 02000s was running on Jazelle |
| 17:00 |
|
Sobinec joined #minetest |
| 17:00 |
muurkha |
which was ARM's "set a bit in the CPU and now JVM bytecode is your machine code" thing |
| 17:00 |
jonadab |
I mean, a _lot_ of Java code was running on the browser plugin. |
| 17:00 |
muurkha |
Jazelle is unfortunately not very well documented |
| 17:01 |
muurkha |
yeah, the browser plugin was HotSpot-based from the mid-02000s, but it never really took off the way server-side Java, Dalvik, and client-side JS did |
| 17:02 |
muurkha |
Jazelle only really implemented the simpler JVM bytecodes in hardware; it trapped to "millicode" implementations for the more complex instructions, similar to how Linux implements virtual memory |
| 17:02 |
jonadab |
I'm glad browser-plugin Java has mostly faded into obscurity. |
| 17:02 |
muurkha |
access the wrong page of memory and your program's execution is suspended for a few thousand cycles while the kernel fixes up your memory map |
| 17:03 |
jonadab |
Although by the end, performance was no longer its problem. |
| 17:03 |
muurkha |
Anyway, I think it's reasonable to say that C *now* is best used only for things like kernels and bootloaders. Wrong, but reasonable. |
| 17:04 |
jonadab |
For new projects, I think I would lean that way. |
| 17:04 |
muurkha |
But it's totally ahistorical to claim that that was what it was designed for. |
| 17:04 |
jonadab |
But of course there are gazillions of existing projects written in it that need to be maintained for the forseeable. |
| 17:05 |
jonadab |
I mean, it wasn't designed _exclusively_ for that stuff. But it was designed to be _able_ to do that stuff, I still think that's true. |
| 17:06 |
jonadab |
Though it's possible there was less of a distinction between low-level and systems programming versus application development back then. Likely even. |
| 17:06 |
muurkha |
Yes! But the mainstream belief at the time was that high-level languages like COBOL and PL/I were often too inefficient to write application software in, prior to the shift to C. |
| 17:07 |
jonadab |
COBOL is too inefficient (with programmer time if nothing else) to write anything in. |
| 17:07 |
muurkha |
That wasn't the argument, and it's a lot more efficient with programmer time than assembly! |
| 17:07 |
muurkha |
"Systems programming" included things like compilers, which aren't inherently low-level, though you can certainly write them in low-level languages. |
| 17:08 |
jonadab |
In principle, you _can_ write anything in a low level language, down to and including machine code. It's just a question of whether there's a better option. |
| 17:17 |
muurkha |
Right, and I'm talking about what people generally thought in the 70s and early 80s, which is the period of time in question. It was a period of time when the opinion that writing application software in a high-level language rather than assembly was starting to become widespread. |
| 17:18 |
muurkha |
Fred Brooks famously advocated this point of view in his book in 01975, but C didn't really displace assembly for that purpose until the late 80s. |
| 17:18 |
muurkha |
In IBM mainframe shops, it never did; they were writing new applications code in assembly until the late 90s or early 2000s |
| 17:19 |
muurkha |
Though IBM itself wrote DB2 in PL/M |
| 17:20 |
muurkha |
and there have been *some* applications written in high-level languages as long as there have been interpreters; Brief Code is from 01949 |
| 17:23 |
muurkha |
So it's true that being able to write kernels and bootloaders in C was what C was designed for; but it was coming into that space from above, so to speak, a language that advanced and ambitious people might use for applications whose applicability could even extend down into the kernel space. Not the other way around, a language for kernels whose applicability could extend up into the applications |
| 17:23 |
muurkha |
space. |
| 17:23 |
|
Talkless joined #minetest |
| 17:23 |
muurkha |
The predecessor of C, B, compiled to an interpreted stack bytecode similar to the JVM bytecode, but untyped. |
| 17:38 |
|
sparky4 joined #minetest |
| 17:42 |
jonadab |
Hmm. |
| 17:42 |
jonadab |
I knew of the existence of B but didn't know anything about it. |
| 17:43 |
jonadab |
Other than its name (such as it is). |
| 17:50 |
|
v-rob joined #minetest |
| 18:11 |
|
Desour joined #minetest |
| 18:57 |
|
sparky4 joined #minetest |
| 19:00 |
|
sugarbeet joined #minetest |
| 19:05 |
|
erle_on_ice joined #minetest |
| 19:06 |
erle_on_ice |
what is it with everyone and codeberg? |
| 19:06 |
muurkha |
erle_on_ice: did you see my notes yesterday about 3-D rendering algorithms? |
| 19:06 |
erle_on_ice |
yes, probably |
| 19:06 |
erle_on_ice |
i opened your page |
| 19:06 |
erle_on_ice |
but on another computer |
| 19:07 |
erle_on_ice |
i also realized that i should probably put a check in tga_encoder so it actually can not encode the evil images |
| 19:07 |
erle_on_ice |
because right now it is trivial to do so |
| 19:08 |
muurkha |
which page? |
| 19:08 |
erle_on_ice |
the one with some javascript canvas rendering |
| 19:08 |
erle_on_ice |
i am on a train, i will get the logs |
| 19:11 |
erle_on_ice |
the irrlicht maintainer has already answered, but seems confused https://irrlicht.sourceforge.io/forum/viewtopic.php?t=52925 |
| 19:12 |
erle_on_ice |
i opened this page i think http://canonical.org/~kragen/sw/torus |
| 19:12 |
muurkha |
aha, yes. that's the one that shows polygon rendering with flat shading (not scanline rendering, but a form easily adapted to it) |
| 19:13 |
erle_on_ice |
lol everything looks cooler with trails |
| 19:13 |
muurkha |
yes |
| 19:13 |
muurkha |
but I think you might be more interested in the SDF raymarcher |
| 19:13 |
muurkha |
which was another page of mine from that conversation you could have opened ;) |
| 19:13 |
erle_on_ice |
muurkha i am not a smartie, but here, have some ghetto orbital mechanics http://daten.dieweltistgarnichtso.net/src/schwrkrft/ |
| 19:13 |
erle_on_ice |
they have trails too |
| 19:14 |
muurkha |
nice |
| 19:14 |
erle_on_ice |
i will, probably |
| 19:15 |
erle_on_ice |
well, i learned how fast you have to go to get to orbit in school in astronomy class |
| 19:15 |
erle_on_ice |
you can see in the code that it is pretty stupid |
| 19:15 |
erle_on_ice |
i once implemented point-gravity for minetest where you could orbit around 0,0,0 |
| 19:15 |
muurkha |
are you using a conservative numerical integrator? |
| 19:16 |
hare_hare_yukai |
drugs is one hell of a drug |
| 19:16 |
erle_on_ice |
muurkha http://daten.dieweltistgarnichtso.net/src/schwrkrft/js/n-body.js |
| 19:16 |
muurkha |
ah, no, it's just forward Euler |
| 19:17 |
muurkha |
do you know about leapfrog integration? it works a lot better for this kind of thing |
| 19:17 |
erle_on_ice |
ah, you can spawn things in orbit i think |
| 19:17 |
erle_on_ice |
i forgot |
| 19:17 |
erle_on_ice |
i forgot how |
| 19:17 |
erle_on_ice |
apparently i do not |
| 19:17 |
erle_on_ice |
ah there is a button |
| 19:18 |
muurkha |
with forward Euler even a simple two-body system orbiting in circles will gradually gain energy; leapfrog integration is symplectic |
| 19:18 |
erle_on_ice |
the numeric instability in my simulation is off the charts |
| 19:19 |
muurkha |
try leapfrog integration, it's easy and fun! |
| 19:20 |
erle_on_ice |
everything is flying away |
| 19:20 |
erle_on_ice |
i will look it up now |
| 19:20 |
erle_on_ice |
minetest orbital mechanics when |
| 19:21 |
muurkha |
it's probably the case that a random N-body system really *is* unstable and will eject rogue planets from time to time; that's not necessarily an error due to numerical instability |
| 19:23 |
|
erle_on_ice joined #minetest |
| 19:54 |
hare_hare_yukai |
sometimes life is... cock & ball torture |
| 20:02 |
|
erle_on_ice joined #minetest |
| 20:04 |
hare_hare_yukai |
erle_on_ice where can i see the musical? |
| 20:05 |
erle_on_ice |
which musical |
| 20:05 |
erle_on_ice |
this is like yuri on ice |
| 20:06 |
hare_hare_yukai |
does that mean you are a lesbian on ice? |
| 20:09 |
erle_on_ice |
hilariously, yuri on ice seems to be a series about boys https://en.wikipedia.org/wiki/Yuri_on_Ice |
| 20:21 |
hare_hare_yukai |
>Poorly-socialized male-at-birth who was mostly raised by screens (TV, computer, etc.) rather than their parents, and therefore didn't properly develop a healthy social-identity. Due to having few or no friends or positive role-models, they instead form a strong parasocial relationship with female pornography subjects and/or female video game & |
| 20:21 |
hare_hare_yukai |
cartoon characters, to the point that they end up identifying as a "transgender-lesbian". |
| 20:21 |
erle_on_ice |
what |
| 20:22 |
erle_on_ice |
are you researching the infamous incel-to-trans-catgirl pipeline? |
| 20:22 |
hare_hare_yukai |
yes |
| 20:22 |
erle_on_ice |
i think the reason for t4t relationships could also just be that the cis don't get it? like, shared experiences or so |
| 20:23 |
|
appguru joined #minetest |
| 20:23 |
erle_on_ice |
hare_hare_yukai did you get what you posted from? |
| 20:24 |
hare_hare_yukai |
did i get what? |
| 20:24 |
erle_on_ice |
oh lol |
| 20:24 |
erle_on_ice |
urban dictionary: troon |
| 20:25 |
erle_on_ice |
hare_hare_yukai go here instead http://ts.isnice.be/ |
| 20:28 |
sfan5 |
while this channel does not have a strong on-topic requirement I feel you have ventured very far from it |
| 20:29 |
muurkha |
sorry |
| 20:33 |
|
v-rob joined #minetest |
| 20:48 |
|
erle_on_ice joined #minetest |
| 20:49 |
|
amfl2 joined #minetest |
| 21:11 |
|
amfl2 joined #minetest |
| 21:20 |
erle_on_ice |
what's the issue people have with the subtree merge method? i have just seen this and it seems to work fine https://codeberg.org/mineclonia/mineclonia/pulls/580 |
| 21:22 |
|
illwieckz_ joined #minetest |
| 21:23 |
|
illwieckz joined #minetest |
| 21:52 |
|
appguru joined #minetest |
| 22:21 |
|
illwieckz joined #minetest |
| 22:33 |
|
panwolfram joined #minetest |
| 22:34 |
|
sys4 joined #minetest |
| 22:56 |
|
illwieckz joined #minetest |
| 22:58 |
|
Alias joined #minetest |
| 23:06 |
|
comrad joined #minetest |
| 23:13 |
|
illwieckz joined #minetest |
| 23:13 |
|
v-rob joined #minetest |
| 23:13 |
|
erle_on_ice joined #minetest |
| 23:24 |
|
simon816 joined #minetest |
| 23:30 |
|
AliasAlreadyTake joined #minetest |
| 23:31 |
|
Leopold_ joined #minetest |
