| Time |
Nick |
Message |
| 00:22 |
|
sparky4 joined #luanti |
| 00:45 |
rubenwardy |
bgstack15: you should provide aliases in the response to migrate author names |
| 00:45 |
rubenwardy |
Of ContentDBProxy |
| 00:45 |
rubenwardy |
I forget the exact syntax (search the cdb API response for alias) |
| 00:46 |
rubenwardy |
But Luanti supports packages changing author name |
| 00:46 |
rubenwardy |
So you could use this to allow moving from existing CDB installs to your proxy |
| 01:37 |
|
YuGiOhJCJ joined #luanti |
| 01:44 |
bgstack15 |
rubenwardy: awesome idea. That was a breaking thing; if a user installs official mod author/ABC but then switchs luanti config to use the contentdbproxy, it does not recognize author~https___content.luanti.org/ABC as the same mod. It sounds like alias should do the trick, because I'm exploiting the author field. |
| 01:50 |
bgstack15 |
Is there a good example mod I can examine in the api response? Unfortunately the /api/packages/?type=mod list doesn't seem to indicate anything about aliases anywhere. |
| 01:51 |
MTDiscord |
<wsor4035> if you did /api/packages you would see like 3 in a 1920 x 1080 screen |
| 01:52 |
MTDiscord |
<wsor4035> *2, requires a slight scroll. one on page load (with pretty print) |
| 01:54 |
bgstack15 |
Ah, I had some crazy set of query params, probably from the client interactions, so I didn't have a bare /api/packages. Thanks! |
| 02:52 |
|
aliasreadytaken joined #luanti |
| 03:21 |
bgstack15 |
Cool, thanks for the info! I was able to add the alias info, so it gracefully lets packages update. That was something I hadn't yet solved. It only took a few lines. |
| 03:21 |
bgstack15 |
Surprisingly, codeberg is down, so I guess everybody'll have to wait. |
| 03:27 |
|
SwissalpS joined #luanti |
| 03:34 |
[MatrxMT] |
<Blockhead256> > We've also made CloakV4 harder to detect by removing the custom version string. |
| 03:35 |
[MatrxMT] |
<Blockhead256> This is not very nice. I know we never expected to actually be able to trust those, but, for goodness sake, don't do that, keep the skiddies out |
| 04:00 |
|
MTDiscord joined #luanti |
| 05:20 |
|
FileX joined #luanti |
| 05:38 |
|
FeXoR joined #luanti |
| 05:42 |
|
identity joined #luanti |
| 05:59 |
|
FileX joined #luanti |
| 07:23 |
|
FileX joined #luanti |
| 08:56 |
|
identity joined #luanti |
| 09:00 |
|
erle joined #luanti |
| 09:09 |
|
mrkubax10 joined #luanti |
| 10:06 |
|
SFENCE joined #luanti |
| 10:13 |
|
SFENCE joined #luanti |
| 10:16 |
[MatrxMT] |
<Bracket> what's cloakv4 |
| 10:17 |
[MatrxMT] |
<Blockhead256> do you want to take a guess with context clues? |
| 11:01 |
[MatrxMT] |
<Bracket> something with scrapers? |
| 11:01 |
[MatrxMT] |
<Blockhead256> it's a cheat client |
| 11:01 |
erle |
cloakv4 is an alternative luanti client with improved CSMs, colloquially known as a “debug” or “cheat” client. such clients usually have improved rendering/GUI options, like tracers that point to targets of interest (other players or specific mobs) and vastly improved CSM APIs compared to vanilla luanti |
| 11:01 |
|
SwissalpS joined #luanti |
| 11:02 |
erle |
contrary to the name, you can't cheat that much with it, except in PvP. and outside of anarchy servers, you definitely shouldn't. |
| 11:02 |
[MatrxMT] |
<Blockhead256> yes, the cheating is in PvP, or cheating the usual rules of visibility and knowledge of game state |
| 11:02 |
erle |
game state? |
| 11:02 |
[MatrxMT] |
<Bracket> sounds interesting though |
| 11:02 |
erle |
oh you probably mean fullbright |
| 11:02 |
[MatrxMT] |
<Blockhead256> the literal point of Luanti's built in CSM API is that it can't automate player actions |
| 11:02 |
erle |
yeah, that's the fundamental difference. |
| 11:02 |
[MatrxMT] |
<Blockhead256> erle: fullbright, x-raying, et cetera |
| 11:03 |
erle |
cora once made an amazing CSM that automated “put the node i have in hand on each node in range that has the same type” |
| 11:03 |
erle |
which means if you want a castle or a tower you can just make the outline of the walls |
| 11:03 |
erle |
and then hop around and press the key bound to that action multiple times |
| 11:03 |
erle |
to make it go higher |
| 11:03 |
[MatrxMT] |
<Blockhead256> the bridge is mangling those smart quotes. I love unicode! |
| 11:04 |
erle |
doesn't allow you to cheat, |
| 11:04 |
erle |
like you still need the materials |
| 11:04 |
erle |
but if you know you want to build a tower 100 nodes high it will take only a minute or so instead of forever |
| 11:05 |
erle |
Bracket most of the useful stuff is like that. i.e. not full-blown bot automation but rather binding a complex action to a single command. |
| 11:05 |
[MatrxMT] |
<Blockhead256> I know you take a very loose interpretation on what constitutes it, so I won't argue the point, but, someone would definitely feel ripped off by cheat-client users that they had to go through something because they didn't have that client capability |
| 11:05 |
erle |
which is why these clients announce themselves on connection to the server |
| 11:05 |
erle |
so they are easily auto-bannable |
| 11:06 |
[MatrxMT] |
<Blockhead256> *on what constitutes cheating, and your general view of emergent gameplay |
| 11:06 |
erle |
at least last i checked |
| 11:06 |
[MatrxMT] |
<Blockhead256> cloakv4 says in their github release that they do not, so, I pointed it out, and asked in their issue tracker that they consider doing so again |
| 11:06 |
erle |
oh okay |
| 11:07 |
[MatrxMT] |
<Blockhead256> predecessors like dragonfire have been polite about it |
| 11:07 |
erle |
yeah, stuff like “fly/walk to these coordinates” or “angle my player character exactly that i am looking at a target” or “build a nether portal” is usually not part of the core gameplay loop i experience |
| 11:08 |
erle |
or “output coordinates of all particle spawners so that you can see if your game has an info leak” |
| 11:08 |
erle |
waspsaliva also has a thing where you can mark other players as friend or foe (IFF) and IIRC a private chat CSM that encrypts your chats so server owners can not spy on users |
| 11:08 |
[MatrxMT] |
<Blockhead256> I do like the idea of some of these features as "debug" options, it tends to lend more credence than "yeah you use this to win at PvP" |
| 11:09 |
erle |
the people who use this in PvP usually only fight others who use these things in PvP |
| 11:09 |
erle |
because it's fucking boring to just win by default |
| 11:09 |
erle |
it's like a battle in DragonBallZ |
| 11:09 |
erle |
people flying around, fucking up the environment, landing hits |
| 11:09 |
[MatrxMT] |
<Blockhead256> there's always some people out there who just wanna grief & gank |
| 11:10 |
erle |
that is true, but these people are usually too stupid to do much. i once defeated one of them with a vanilla client modified to just move randomly. he got bored after like 20 minutes. |
| 11:10 |
[MatrxMT] |
<Blockhead256> at least it should get boring quickly enough |
| 11:10 |
erle |
defeated by a literal random walk ;) |
| 11:11 |
erle |
i usually tell people on anarchy servers to only trust those who either gift you valuable items, without wanting anything in return or demonstrate knowledge of complex mechanisms like redstone or mesecons or technic |
| 11:12 |
erle |
in any case, all the things that are used for griefing are super simple to do |
| 11:12 |
erle |
like, anyone knowing the engine even a tiny bit could modify their own client to fly, noclip, xray, etc. easily |
| 11:13 |
erle |
stuff like tracers and debugging features are the useful things |
| 11:13 |
erle |
they serve as a counterweight to grinding features in games |
| 11:13 |
[MatrxMT] |
<Blockhead256> hence I mentioned "& gank" in particular, since it's all about causing grief, and that gets done various ways |
| 11:13 |
erle |
you can see this partially by the fact that the more grindier games are easier to beat using cheat clients |
| 11:14 |
erle |
whereas e.g. nodecore … i think i never saw anyone use one there |
| 11:14 |
erle |
nodecore is also virtually free of griefers |
| 11:14 |
erle |
too unsatisfying of a game for a quick fix |
| 11:14 |
erle |
players don't even die |
| 11:15 |
erle |
and servers focused on technic or so … their users also don't profit much from modified clients |
| 11:15 |
erle |
because the in-game automation already covers stuff like autocrafting |
| 11:16 |
erle |
but e.g. mineclonia has a button “fill the crafting grid with all resources i have for this recipe that is in it”, authored by cora, i believe. i made the icon for it :) |
| 11:16 |
[MatrxMT] |
<Blockhead256> not much beyond what you could provide with server mods and ordinary level CSMs, like waypoints or different ways of looking up information |
| 11:16 |
erle |
and every single time i play a game that does not have that button i am EXTREMELY frustrated when i want to craft like a full stack of bamboo wood or compressed cobble or so |
| 11:17 |
erle |
one reason why these clients can not be used to cheat much is also that the creators of cheat clients often fix the bugs |
| 11:17 |
erle |
lizzy fixed entity speed IIRC |
| 11:17 |
erle |
cora fixed a lot of stuff |
| 11:18 |
erle |
like, you used to be able to access your echest from anyone. now there is a distance check. you can still try to access echest inventory … but if there is no echest nearby, sucks to be you. |
| 11:18 |
erle |
this nerfs griefers a lot |
| 11:18 |
erle |
previously they could die and literally pull out sword and armor out of their ass (echest inv) after respawning |
| 11:18 |
erle |
now they can't |
| 11:18 |
|
PoochInquisitor joined #luanti |
| 11:43 |
|
SFENCE joined #luanti |
| 12:12 |
|
FileX joined #luanti |
| 12:14 |
bgstack15 |
I was making a "mcl_colored_chests" mod, and found in the ender_chest code that distance check. |
| 12:17 |
erle |
be aware that the distance check is subtly faulty |
| 12:17 |
erle |
or may be |
| 12:17 |
erle |
i think it is not exactly equivalent to the hand distance, but a tiny bit less |
| 12:18 |
erle |
bgstack15 in any case, try accessing the chest you made if it uses that kind of code from below, it might be that you can open the inv but not interact with it because the cheat detection is triggered |
| 12:19 |
erle |
also if you saw the xmas deco code, that was my doing :P |
| 12:19 |
erle |
on 24th/25th/26th december all mineclonia chests become xmas present chests |
| 12:24 |
repetitivestrain |
Blockhead256: there are plenty of legitimate applications for client side physics/interaction/graphics overrides |
| 12:25 |
repetitivestrain |
mcl_localplayer (my CSM) exercises these to replace luanti's atrocious localplayer physics with a reproduction of minecraft's physics engine, and implement client-side item animations |
| 12:25 |
repetitivestrain |
it does not facilitate cheating in any wise |
| 12:26 |
[MatrxMT] |
<Blockhead256> ok well, that is the best vector available for delivering it, and any form of DRM to check otherwise would be a waste of effort |
| 12:26 |
erle |
i am convinced though that the local physics thing can just be solved with a better traits system like OpenRA has |
| 12:26 |
[MatrxMT] |
<Blockhead256> it still feels inappropriate compared to C++ |
| 12:27 |
erle |
while openRA does have lua scripting, almost all unit/superweapon/building stuff is defined in declarative YAML |
| 12:27 |
erle |
to make something work you combine traits |
| 12:27 |
erle |
and make up state transitions that define traits, like in CSS |
| 12:27 |
erle |
a submarine might have an invisibility trait when submerged and the state transition for submerging might be the “deploy” action |
| 12:28 |
repetitivestrain |
erle: minecraft physics require a constant tick speed which cannot be supported without engine modifications |
| 12:28 |
erle |
repetitivestrain which is why i think the engine should be modified |
| 12:28 |
erle |
in combined arms (a game running on a modified openRA) engine they added more traits and then took advantage of it |
| 12:28 |
repetitivestrain |
my luanti patches implement enough to permit csms to implement constant tick speeds in lua |
| 12:28 |
erle |
repetitivestrain are you halon? |
| 12:28 |
repetitivestrain |
yes |
| 12:28 |
erle |
hi then |
| 12:28 |
repetitivestrain |
hello |
| 12:29 |
erle |
repetitivestrain about your mapgen thingy, i think you could sidestep a lot of “does it ruin singlenode worlds” discussions if your client (and/or luanti) would just make it easier to register/enable lua mapgens |
| 12:30 |
erle |
did you think about making that an option in your client, given you have a custom client already? |
| 13:13 |
|
qqe joined #luanti |
| 13:46 |
luatic |
erle: i am convinced that trying to engineer some sort of traits system is not going to cut it |
| 13:47 |
luatic |
it will always end up with more work, a more complex and messier API, and less capabilities. |
| 13:47 |
luatic |
and really there is not much of a risk coming from running lua on the client if properly sandboxed. |
| 13:47 |
erle |
lmao |
| 13:48 |
luatic |
indeed i wouldn't be surprised if an overengineered "data-driven" system resulted in more vulnerabilities. simply because more C++ code = more potential for messing up. |
| 13:48 |
erle |
luatic from my work experience a good traits system basically summarizes the domain. e.g. openRA CA has figured out the RTS domain. |
| 13:48 |
luatic |
you can not "summarize" the (voxel) game engine domain without a turing complete programming language. |
| 13:49 |
erle |
and while it is not always like that, the people advocating loudest for “let's just have lua or another scripting language” (at least in a work context) were people unable to model the domain at all without a concrete task, so they needed it as an escape hatch |
| 13:49 |
erle |
i mean don't understand me wrong, OpenRA also has custom lua scripts for e.g. special maps |
| 13:49 |
erle |
minigames and so on |
| 13:49 |
erle |
but they mostly mastered their domain in declarative terms |
| 13:50 |
luatic |
good for them. we can try to do that once we have the lua scripts. |
| 13:50 |
erle |
i believe the domain can be mostly modeled in declarative terms but failure of things like dual wielding push people to CSMs |
| 13:51 |
erle |
and also the fact that at least some devs are unable or unwilling to do abstractions they deem unnecessary or difficult |
| 13:51 |
luatic |
dual wielding is a perfect example of bad, overly game-specific modeling that can be abstracted much better by SSCSM |
| 13:52 |
luatic |
and even without SSCSM it's a very particular feature |
| 13:52 |
luatic |
more general alternatives (at least for visuals) go in the direction of first-person attachments, HUD mesh elements |
| 13:52 |
erle |
e.g. sending shaders to the client is always easier than encapsulating an effects API as long as you only support one graphics backend and a limited amount of GPU and don't intend to support anything the devs don't have |
| 13:52 |
[MatrxMT] |
<Blockhead256> if your domain model is "all of the features minecraft has", "dual wield" begins to look like a good fit |
| 13:52 |
erle |
i'd add roblox, but yeah |
| 13:53 |
luatic |
sending shaders to the client is also a good example. because it's one of the things i thought was a good idea like half a decade ago and now i see that it isn't. |
| 13:53 |
luatic |
(i had implemented it and the PR was rejected. in hindsight for the better.) |
| 13:53 |
erle |
luatic the push to be as generic as possible is something that for me is an indicator for “i have not been able to model the domain and consider it either to difficult or not a task that is worth anyone's time” |
| 13:53 |
luatic |
erle: wrong way around |
| 13:53 |
erle |
oh yeah but then you understand why it seems like a good idea |
| 13:53 |
erle |
the shader stuff i mean |
| 13:54 |
luatic |
"i have modeled the domain and observed why SSCSM" is the better solution is what it is. |
| 13:54 |
luatic |
move that quote |
| 13:55 |
erle |
what |
| 13:56 |
erle |
i don't get it |
| 13:56 |
luatic |
you're free to check out github, plenty of discussions there, you'll see that we are modeling the domain |
| 13:56 |
luatic |
and time and time again the conclusion is just: SSCSM would result in an easier, more flexible, more efficient API with less work for engine developers |
| 13:56 |
[MatrxMT] |
<Blockhead256> what would make an antipattern of sending shaders to the client? |
| 13:56 |
repetitivestrain |
erle: my mapgen is supposed to support unmodified luanti implementations too |
| 13:56 |
luatic |
in other words: it is strictly better |
| 13:56 |
erle |
> less work for engine developers |
| 13:56 |
erle |
lol motivated reasoning |
| 13:56 |
luatic |
Blockhead256: Among other reasons, we do not want to freeze our messy rendering pipeline at the current point in time. |
| 13:56 |
erle |
“less work for API implementors so more work for everyone else” |
| 13:57 |
repetitivestrain |
i'm sorry to be blunt but i think sending shaders to the client is a fool's errand because shaders are not portable and really do not admit of stable interfaces |
| 13:57 |
erle |
luatic have you read “the seven turrets of babel”? |
| 13:57 |
luatic |
yes, but it's been a while |
| 13:57 |
erle |
then you must know there is always a cost to higher flexibility |
| 13:57 |
erle |
namely that some problems become unsolvable |
| 13:58 |
luatic |
yes poorly written SSCSM can halt your client. such is the nature of a game engine. |
| 13:58 |
erle |
up until the point whereas every client has a halting problem for trivial tasks (e.g. web with javascript) |
| 13:58 |
[MatrxMT] |
<Blockhead256> oh yes, right, "shaders" are actually quite specific to the pipeline, GL version and hardware targets that they exist within |
| 13:58 |
luatic |
(though, given that they'll be on a different thread, we could even cope somewhat i believe.) |
| 13:58 |
erle |
shaders are also the mechanical instantiation of an intent |
| 13:58 |
repetitivestrain |
e.g. ask yourself how many modders will understand what MSAA is and in what circumstances to qualify values centroid |
| 13:59 |
erle |
most often you care about the intent, not about the implementation |
| 13:59 |
luatic |
anyways the assertion that SSCSM would somehow be "less work for API implementors so more work for everyone else" is pretty far from the truth in general |
| 13:59 |
luatic |
i'm very optimistic that in plenty of cases it'll be a win-win |
| 14:00 |
[MatrxMT] |
<Blockhead256> erle: just curious, do you disable a lot of javascript in your browser? |
| 14:00 |
repetitivestrain |
i cannot speak for erle but i do |
| 14:00 |
repetitivestrain |
i have noscript installed with the default whitelist disabled |
| 14:01 |
erle |
Blockhead256 i do in fact disable js by default and only enable what i need to make the site function. and e.g. for stuff like youtube that usually translates to “one higher resolution step of the video can be decoded without the image lagging” on multiple machines. |
| 14:01 |
repetitivestrain |
erle: i think you shouldn't hold exaggerated expectations as regards the scope of my luanti branch |
| 14:01 |
erle |
like you get 480 instead of 360 or whatever they call their resolutions |
| 14:01 |
[MatrxMT] |
<Blockhead256> may we live long enough to see Luanti-noscript users complaining about too many client scripts :P |
| 14:01 |
erle |
repetitivestrain you do work on tasks that are vast and do impressive stuff. i thought “make a hook to register a custom mapgen so it can be selected at world config” would be within that scope. it's not that i expect you to do it, i just think it kinda fits. |
| 14:02 |
repetitivestrain |
since i intend to restrict departures from upstream to the minimum required for my mineclonia features to function well |
| 14:02 |
repetitivestrain |
erle: if i had boundless time to dedicate to maintaining my branch i would probably have implemented such facilities already |
| 14:03 |
erle |
Blockhead256 i think it will pretty much happen immediately, judging from mineclone2 development. like, there was once a bug that was simply sending like 60+ packages per second when the player was on fire. my bug report about it was retitled to “post your computer's specs”. meanwhile, cora was able to set people on fire multiple times and managed to cause 2MB traffic per second or so just from that shitty implementation. |
| 14:03 |
repetitivestrain |
but i need periodically merging upstream to be a feasible chore |
| 14:03 |
erle |
you can see this with luanti engine development as well: inefficient code is often excused as “works on my machine” |
| 14:04 |
erle |
and sometimes you get stuff that you can't sidestep, like halons mapgen that needs a computer more powerful than most machines i have seen that run mineclonia have – because it is a full-featured mapgen in lua. imagine such a feature that is useful, but not optional, as part of a game. it is not a question *if* it will happen. |
| 14:04 |
[MatrxMT] |
<Blockhead256> 16 Mbit? ouch, right in the badinternets |
| 14:05 |
erle |
also in mineclone2 there was the ghost inventory bug |
| 14:05 |
erle |
nodes could be destroyed but the inv would stay |
| 14:05 |
erle |
safe to say this made game laggier for people with worse internet/hardware |
| 14:05 |
erle |
also it allowed easy duping because the items would still spill out hehe |
| 14:06 |
erle |
with the right CSM even in vanilla minetest you could pluck the items out of thin air when a base got griefed hehehehehe |
| 14:08 |
repetitivestrain |
i think a very compelling argument against expecting lua to manage absolutely every aspect of gameplay can be found in the voxelmanip API |
| 14:09 |
repetitivestrain |
which at the present requires multiple 12 mb arrays to be allocated in addition to the VoxelManip's contents itself to be manipulated efficiently from lua |
| 14:09 |
repetitivestrain |
(one array for param2 data and one array for cid data) |
| 14:09 |
erle |
i think a very compelling meta-argument is that for most use-cases where people want SSCSM it is trivial to adjust the engine (were it not for the “but we want it to be general” argument) |
| 14:10 |
erle |
repetitivestrain yeah but then again most APIs are designed for ease of implementation and not really for ease of use in the first place. like, the png encoding API shape is atrocious. and while i disagree with how zughy goes about a lot of things, having e.g. get_sky and set_sky be assymetric is an API smell. |
| 14:11 |
erle |
or take the picture-in-item meta thing. for stuff like bows or compasses it would make sense to e.g. be able to change the pic without the item switch animation or to even map different states of an item to different textures. but that is harder to implement and while multiple users of such an API want this, no implementor did. |
| 14:11 |
repetitivestrain |
this VoxelManip issue in particular is a limitation imposed by lua as a language |
| 14:12 |
erle |
care to elaborate? |
| 14:13 |
repetitivestrain |
All lua values are numbers, which are 8 byte doubles, and it is not possible to expose native memory (e.g. a voxelmanip's mapnode array) directly to PUC Lua programs |
| 14:14 |
repetitivestrain |
and C module function calls are damnably slow in LuaJIT--they interrupt the jit trace recorder--and consequently efficient lua programs must avoid nearly all engine APIs altogether |
| 14:15 |
repetitivestrain |
take my map generator, for example |
| 14:16 |
repetitivestrain |
it doesn't remotely approach the performance of an equivalent in C, but it is roughly half as performant on a single thread as minecraft's java level generator, and one of the reasons it can attain such performance is that it dilligently avoids invoking code which cannot be compiled by the jit compiler or which may produce unnecessary allocations and so forth |
| 14:18 |
repetitivestrain |
and this inherent divorcing of the lua domain from the C++ domain is one of the factors preventing lua scripts from running optimally |
| 14:19 |
erle |
repetitivestrain i think i know that kind of thing very well. i profile my shell scripts using strace. |
| 14:20 |
erle |
and most of the time, shell scripts are slow because people have overhead of subshells, which means overhead of process creation. |
| 14:20 |
repetitivestrain |
yes, with luajit the bottlenecks are operations which the compiler cannot compile, and after that, garbage collection, and loops with unpredictable control flow |
| 14:21 |
repetitivestrain |
"yes, the analogy is accurate," i meant to say |
| 14:21 |
erle |
meanwhile, i have outperformed C programs using shell scripts for some specialized tasks because the C stuff was just badly written (and i am not going to repair C code if i can get better performance with a shell script) |
| 14:21 |
erle |
lua garbage collection goes fucking weirdo when it hits a memory limit btw |
| 14:22 |
erle |
cora once made a fire implementation for mineclonia that improved on the previous one but used node timers |
| 14:22 |
repetitivestrain |
LuaJIT's garbage collector is completely unfit for a real-time video game |
| 14:22 |
repetitivestrain |
hence programmers really ought to cut down on operations that allocate vectors |
| 14:23 |
erle |
since fire copies itself, memory usage goes skywards. and that is how i found out that the garbage collector can go in a weird death loop if you fuck up your mod programming to the extent that a node (fire) is a memory leak |
| 14:23 |
erle |
cora's solution was to have probabilistic fire, so no new timers are created |
| 14:23 |
repetitivestrain |
all >50ms globalsteps on my server are either produced by ABM execution or by outstanding garbage collection operations triggered by vector operations and object moveresult allocations, during which operations which access tables or arrays become one order of magnitude slower |
| 14:24 |
erle |
btw, i do think “make it possible to register a custom lua mapgen” is a worthwhile goal for vanilla luanti. maybe luatic can weigh in on that. |
| 14:24 |
erle |
like, if it's the kind of feature that would be accepted |
| 14:25 |
repetitivestrain |
what i would truly appreciate would be the ability for a game to implement its own New World dialog |
| 14:25 |
erle |
because IIRC there are quite a number of “install this mod and enable singlenode” mapgens |
| 14:25 |
repetitivestrain |
or at the minimum to specify its own mapgen flags |
| 14:25 |
erle |
i'd appreciate the latter, not the former |
| 14:25 |
repetitivestrain |
https://minecraft.wiki/images/CreateNewWorld_World_1.21.6.png |
| 14:25 |
erle |
(this is consistent with the “intent, not implementation” thing) |
| 14:26 |
repetitivestrain |
because my world generator implements every single one of the flags in this dialog, but enabling them requires that the server administrator manually edit map_meta.txt or minetest.conf before the world is created |
| 14:28 |
erle |
repetitivestrain unfortunately, shortly after i made a mod that was able to change the main menu path, that capability got taken away forever on “security” grounds. this also exposed the folly of naming flags with “secure” in the name, hehe. |
| 14:28 |
repetitivestrain |
that's lamentable |
| 14:28 |
erle |
(all my mod did was add a CSM menu) |
| 14:29 |
repetitivestrain |
furthermore it would be nice to permit games to override the algorithm that hashes seeds specified as strings |
| 14:29 |
erle |
yeah, but i understand it. what i don't understand is why you can't have “menu” mods at all. like a mod that is just a main menu. after all, it's a general game engine, right? ;)))) |
| 14:29 |
erle |
repetitivestrain btw what i don't get about your mod storage use. if the mapgen is deterministic, can missing values not be recalculated? |
| 14:29 |
erle |
or are you building the world bottom-up instead of top-down and can't do it because of that? |
| 14:30 |
repetitivestrain |
erle: in the case of biomes, it's because biome generation is not efficient enough to be repeated whenever a biome is required, and what is more, changes to the biome table mustn't affect biomes in existing chunks |
| 14:30 |
erle |
(top down: recursively going from biggest to smallest feature. bottom-up: starting with the smallest unit, then working up. bottom-up is harder to extend.) |
| 14:31 |
erle |
screw efficiency, i mean could it be done theoretically? |
| 14:31 |
repetitivestrain |
biomes, yes, but not the other uses |
| 14:31 |
erle |
because “yeah cool mapgen but map downloads do not allow me at all to explore the world” is a bit of a let-down |
| 14:31 |
erle |
and why not the other uses? |
| 14:31 |
repetitivestrain |
the "generated" flag cannot be reconstructed because it depends on whether the post-processing system has already processed a chunk |
| 14:31 |
erle |
i used to use map downloads to generate a world on a server using the exposed seed and mapgen and then find a good place for shenanigans |
| 14:31 |
repetitivestrain |
which cannot be determined from its contents |
| 14:32 |
repetitivestrain |
a MapBlock, actually, in fact |
| 14:32 |
erle |
well you could set a secret node meta on every node that has been generated |
| 14:32 |
erle |
or only on one corner one |
| 14:32 |
erle |
or a public one, who knows |
| 14:32 |
erle |
would actually be interesting |
| 14:32 |
repetitivestrain |
the issue is that node metadata is somewhat storage-intensive and liable to be overwritten |
| 14:33 |
erle |
“show me all nodes that have been modified since this has been generated” |
| 14:33 |
erle |
i guess i am about as useful as hacker news comments :P |
| 14:33 |
repetitivestrain |
i have in fact requested https://github.com/luanti-org/luanti/issues/16125 |
| 14:33 |
[MatrxMT] |
<Blockhead256> if you want to mess up map download users, lie about the seed, or better yet, change the noiseparams seeds to troll them |
| 14:33 |
repetitivestrain |
on several occasions, but reading the thread, it appears that the tide of core developer opinion has now turned against the proposal |
| 14:34 |
erle |
Blockhead256 i am pretty sure repetitivestrain is the opposite of a person who wants to mess up things |
| 14:34 |
repetitivestrain |
Yeah, i would prefer that offline map downloads functioned correctly |
| 14:34 |
repetitivestrain |
> IIRC, back then the whole world storage had to be loaded as a whole into memory (because it was just a file with json), but now we use an sqlite db. So, nowadays, using worldstorage instead has no real issues. |
| 14:35 |
repetitivestrain |
erle: you might cite this as an argument in favor of mapblock-specific metadata |
| 14:35 |
repetitivestrain |
at least so long as such metadata is delivered to clients |
| 14:36 |
erle |
repetitivestrain my opinion matters very little on it, but yes. mapblock-specific metadata could be interesting, although i'd probably see how far i can get with node specific metadata until it craps out. |
| 14:37 |
FeXoR |
"erle: i usually tell people on anarchy servers to only trust those who either gift you valuable items, without wanting anything in return or demonstrate knowledge of complex mechanisms like redstone or mesecons or technic" Lets tell a story: "Here, have some lava boots" *climbs up to a cube of lava mysteriously not spilling over the recipient's base, starts to throw eggs at them* "Hey, stop throwing eggs at me!" *moves to the offender |
| 14:37 |
FeXoR |
and with their newly acquired lava boots replace the illumination nodes holding the lava in place and after a few seconds their base is flooded with lava* |
| 14:37 |
erle |
repetitivestrain btw no matter how many holes i punch into your proposals, i am a big fan of having such goals and trying to achieve stuff. i'll probably not be able to see the mapgen any time soon for lack of a beefy machine, but what you did to mobs is exquisite. |
| 14:37 |
FeXoR |
So, yea, also knowledgable players can be vicious :p |
| 14:37 |
repetitivestrain |
erle: thanks for the scintillating feedback :-) |
| 14:38 |
erle |
repetitivestrain well sometimes people think that engaging with their stuff and pointing out what sucks means i'm a hater. |
| 14:38 |
erle |
but that's just what i do when i care about it working |
| 14:38 |
repetitivestrain |
i appreciate well-informed criticism haha |
| 14:39 |
erle |
FeXoR the shenanigans that experienced players get up to are often funnier though |
| 14:39 |
erle |
FeXoR like, uh, i could make a redstone bomber easily on oysterity. i am pretty sure there are people who would be impressed if i made a bomber fleet just to raze their base. |
| 14:39 |
repetitivestrain |
it is only those who fly into a rage and accuse me of profiteering from microsoft's divinely ordained intellectual property that i can't abide |
| 14:40 |
repetitivestrain |
erle: biome data (which in the optimal case only consumes two bytes, a biome id and a repetition count of 64 quart positions) is already cached in the origin node of each mapblock, but node metadata is erased whenever a block is altered by the player or by core.set_node and so forth |
| 14:40 |
repetitivestrain |
and it cannot be reliably restored after it is so erased |
| 14:40 |
erle |
i see |
| 14:40 |
erle |
FeXoR i once saw a griefer name a lot of pillagers and lure them to someone's respawn point |
| 14:41 |
erle |
so someone got killed over and over and had to fight them with bare hands |
| 14:41 |
erle |
shit was hilarious |
| 14:41 |
erle |
(named mobs don't despawn IIRC) |
| 14:41 |
repetitivestrain |
correct, they don't |
| 14:41 |
erle |
well i guess you may have implemented that :P |
| 14:41 |
erle |
in any case you are an expert on the topic |
| 14:41 |
repetitivestrain |
i think this is the case even in Mobs Redo |
| 14:42 |
repetitivestrain |
in all fairness |
| 14:42 |
repetitivestrain |
also, https://github.com/luanti-org/luanti/issues/16229 would obviate the need for non-biome mapblock metadata to begin with |
| 14:42 |
erle |
i see |
| 14:43 |
repetitivestrain |
but before anyone actually contributes a serious effort to implementing such a facility, i invite such prospective contributors to consider the requirements my map generator would actually place on it |
| 14:44 |
erle |
repetitivestrain what is the part of the mapgen that does make it infeasible to implement it on weaker machines like old thinkpads or MNT reform btw? |
| 14:44 |
erle |
i mean minecraft used to work on such things a long time ago |
| 14:44 |
erle |
now it has higher requirements than a bunch of 3D shooters lol |
| 14:44 |
repetitivestrain |
erle: LuaJIT itself is generally not as efficient as Java or C/C++ |
| 14:44 |
erle |
that's all? so there is no big chunk that can be taken away or made optional to support weaker machines? |
| 14:45 |
repetitivestrain |
i hate to disappoint, but nope |
| 14:45 |
repetitivestrain |
lots of information must also be duplicated across each mapgen environment |
| 14:45 |
repetitivestrain |
as unlike java, lua does not support shared-memory concurrency |
| 14:45 |
erle |
and there is zero chance that any future mapgen API could replicate that stuff in terms of a declarative mapgen that comes close to what you want to do? |
| 14:46 |
erle |
so lua would only need to touch it up |
| 14:46 |
repetitivestrain |
nearly nil, but minecraft's mapgen api (which mine implements) is 100% declarative anyway as far as terrain is concerned |
| 14:47 |
repetitivestrain |
and if the core developers are willing to incorporate it into luanti proper i already have a largely complete version implemented in C |
| 14:47 |
repetitivestrain |
as a standalone library |
| 14:47 |
repetitivestrain |
but that's a castle in the air lol |
| 14:48 |
|
jaca122 joined #luanti |
| 14:49 |
repetitivestrain |
... requirements my map generator would actually place on it ... |
| 14:50 |
repetitivestrain |
namely, it must be possible for one stage to access metadata attached to mapblocks generated by preceding stages |
| 14:50 |
erle |
repetitivestrain i would bet money on “this is not a minecraft clone engine, it is a generic engine” and your chances of your contribution being accepted close to the survival chances of an ice cube in hell |
| 14:51 |
repetitivestrain |
erle: yeah |
| 14:51 |
repetitivestrain |
but i will recapitulate the structure of a dimension preset (which generates terrain) |
| 14:51 |
erle |
in fact, a bunch of proposals i consider sensible are not considered sensible by people arguing from “make it generic” POV |
| 14:52 |
erle |
and i am pretty sure if these people were OpenRA devs, it would have a lot more custom lua |
| 14:52 |
erle |
because sometimes it has traits that are used only by very few things and nowhere else |
| 14:53 |
repetitivestrain |
a dimension preset is just a series of parameters, a list of noises which are made unique by keywords and are defined as octaves and amplitudes, a terrain density function, a biome table, and a surface rule |
| 14:53 |
erle |
like, i am pretty sure that the attack mode of tesla coils and obelisks is such a thing. it first charges up and then fires, which (almost?) no other weapon does. |
| 14:53 |
erle |
and you can move out of range during the charging up IIRC and then it powers down harmlessly |
| 14:54 |
repetitivestrain |
a density function is a function which can sample a noise or perform various logical or arithmetic operations on the results of other density functions |
| 14:54 |
erle |
like most stuff in OpenRA is hitscan weapons (almost all guns) or projectiles (mostly artillery, rockets, but also flamethrowers) |
| 14:54 |
repetitivestrain |
at a given position |
| 14:55 |
erle |
also i am pretty sure that the “ctrl + deploy” movement thing is a trait they added to the engine only to support jumping mechs and teleporting tanks (again, two very special cases, with different animations) |
| 14:55 |
erle |
or was it force move? |
| 14:55 |
erle |
i guess it was force move |
| 14:55 |
erle |
downgrade it to “reasonably sure” in that case |
| 14:55 |
erle |
:P |
| 14:56 |
repetitivestrain |
their operations include selecting the minimum of two values, applying a value to a spline, deriving a depth value which increases as the y level decreases, selecting between two values contingent on whether or not a third value lies within a specified range, and so forth |
| 14:57 |
repetitivestrain |
the terrain generates a solid block (stone) at a position if the density function yields a value greater than 0, and air if otherwise |
| 14:57 |
erle |
repetitivestrain if you ever have too much time i'd love to have you criticize some lua code of mine, since you seem to have ideas about performance |
| 14:58 |
repetitivestrain |
i would recommend running your code under "luajit -jv" (or "luajit -jdump=+birxmT" if you understand luajit's IR and assembler) |
| 14:58 |
repetitivestrain |
and profiling it with "-jp=v" |
| 14:59 |
repetitivestrain |
then strive to eliminate all issues reported by "-jv" preventing your code from reaching 98% compiled |
| 14:59 |
erle |
i don't understand that (yet?) but thank you |
| 15:00 |
repetitivestrain |
and profile your code with "-jp=2fv" to establish what code spends the most time in garbage collection |
| 15:00 |
erle |
my speedups so far were mostly related to not creating an excessive amount of strings |
| 15:00 |
repetitivestrain |
and attempting to minimize the number of allocations incurred |
| 15:00 |
erle |
thanks |
| 15:00 |
repetitivestrain |
ah, i have thankfully not been required to interact with strings in developing my map generator |
| 15:01 |
MTDiscord |
<luatic> erle: have you read the Lua performance tips? |
| 15:01 |
erle |
yes |
| 15:01 |
erle |
this is how i got the string thing |
| 15:01 |
repetitivestrain |
https://web.archive.org/web/*/http://wiki.luajit.org/Numerical-Computing-Performance-Guide |
| 15:01 |
repetitivestrain |
is very important |
| 15:01 |
repetitivestrain |
https://codeberg.org/mineclonia/mineclonia/src/commit/mineclonia_mapgen/mods/MAPGEN/mcl_levelgen/API.txt#L2088 |
| 15:01 |
repetitivestrain |
i also have a number of recommendations here |
| 15:02 |
MTDiscord |
<luatic> erle: well it also has more allocation related things. eg if you have a table of vectors, transpose that and make it 3 XYZ tables. |
| 15:02 |
repetitivestrain |
... minecraft-style overworld terrain is generated from two fundamental functions which are combined by simple addition |
| 15:03 |
repetitivestrain |
the first is an offset and the second is the depth |
| 15:03 |
MTDiscord |
<luatic> re vmanip earlier, in theory LuaJIT FFI could help, no? |
| 15:03 |
repetitivestrain |
luatic: yes, but that's not portable to PUC Lua |
| 15:03 |
MTDiscord |
<luatic> I know |
| 15:04 |
MTDiscord |
<luatic> but it should be possible to make it portable by having a poly fill for puc |
| 15:04 |
repetitivestrain |
although i doubt performance matters on PUC Lua since my lua mapgen, which theoretically supports puc lua, is nearly 100x slower and completely unusable on such configurations |
| 15:04 |
MTDiscord |
<luatic> that too |
| 15:05 |
repetitivestrain |
... depth increases in proportion as the y position being sampled approaches sea level, and the offset is derived from three noises which are applied to splines to produce the offset |
| 15:06 |
repetitivestrain |
(three 2d noises) |
| 15:06 |
repetitivestrain |
these two values are subsequently summed so that the offset effectively decides the surface height of the terrain at a given column |
| 15:07 |
repetitivestrain |
and a jaggedness value with very low persistence is added to create more variance in the height of the terrain |
| 15:08 |
repetitivestrain |
then, if above the surface, the result is multiplied by a factor value which is derived from another series of splines and which defines the brokenness of the terrain and combined with a 3d noise to create overhangs |
| 15:09 |
repetitivestrain |
and if below the surface, cave and pillar noises are integrated into the density value |
| 15:11 |
repetitivestrain |
a surface system is a list of conditions and control flow operators which define a function that specifies blocks to substitute for stone after terrain has been generated from density function values |
| 15:11 |
repetitivestrain |
https://codeberg.org/mineclonia/mineclonia/src/commit/mineclonia_mapgen/mods/MAPGEN/mcl_levelgen/surface_system.lua |
| 15:11 |
repetitivestrain |
https://codeberg.org/mineclonia/mineclonia/src/commit/mineclonia_mapgen/mods/MAPGEN/mcl_levelgen/surface_presets.lua#L61 |
| 15:11 |
repetitivestrain |
see here for an example of the rules that apply in the Overworld |
| 15:12 |
|
Kimapr_ joined #luanti |
| 15:13 |
repetitivestrain |
and a biome table is a spatial index where each of the noises that contribute to the terrain's offset and brokenness are axes in a hyperspace, and biomes are assigned to hypercubes within this hyperspace, the nearest of which to a point sampled from the noises at a position yields the biome at that position |
| 15:13 |
repetitivestrain |
https://codeberg.org/mineclonia/mineclonia/src/commit/mineclonia_mapgen/mods/MAPGEN/mcl_levelgen/biomes.lua#L637 |
| 15:13 |
repetitivestrain |
here is where the overworld's biome table is defined |
| 15:14 |
repetitivestrain |
https://codeberg.org/mineclonia/mineclonia/src/commit/mineclonia_mapgen/mods/MAPGEN/mcl_levelgen/biomes.lua#L169 |
| 15:14 |
repetitivestrain |
and the spatial index itself is something akin to an r-tree that is not modified at run-time |
| 15:15 |
repetitivestrain |
there is no reason this could not serve as the engine's declarative mapgen api |
| 15:16 |
repetitivestrain |
and it is infinitely superior in practice to the built-in map generators |
| 15:18 |
repetitivestrain |
regarding which i could cite a litany of complaints off the cuff, such as non-determinism, overgeneration, invalid heightmap data, biomes being evaluated at each mapchunk's terrain height rather than at actual y transitions, and carvers (randomwalk cave generators) which overwrite the contents of mapblocks that have already been generated |
| 15:20 |
repetitivestrain |
luatic: btw, can i ask whatever became of the proposal to implement proper perlin noise in the engine |
| 15:54 |
[MatrxMT] |
<Blockhead256> I think we just renamed "Perlin" to "fractal" and never got to the "make actual Perlin" part |
| 15:54 |
[MatrxMT] |
<Blockhead256> https://github.com/luanti-org/luanti/pull/15858 |
| 15:54 |
[MatrxMT] |
<Blockhead256> mind you, we had to wait for the patent to lapse as well |
| 15:55 |
[MatrxMT] |
<Blockhead256> sorry, I think that was simplex that actually got patented |
| 15:59 |
MTDiscord |
<nathan4220776> I kind of understand that. Math can be absolutely horrific to implement. :( |
| 16:32 |
luatic |
repetitivestrain: #15877 is apparently in adoption needed status.. i've not been very involved with that despite knowing it exists, sorry. |
| 16:32 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15877 -- Add Perlin and Simplex noise by kno10 |
| 16:32 |
luatic |
s/despite/besides perhaps |
| 16:43 |
luatic |
btw erle re physics: a lot of game physics can be done fairly declaratively (see popular physics engines). but trying to mix that in with our current hardcoded weird physics is a recipe for disaster. |
| 16:43 |
luatic |
it probably needs to be a distinct system people can opt into and use instead of our current physics. |
| 16:43 |
[MatrxMT] |
<Blockhead256> I don't want to defend default physics too much but.. |
| 16:44 |
[MatrxMT] |
<Blockhead256> I really enjoy holding space and easily jumping uphill |
| 16:44 |
[MatrxMT] |
<Blockhead256> also, Steve is way too heavy compared to Sam once you're used to Sam |
| 16:44 |
luatic |
Steve is obese |
| 16:45 |
[MatrxMT] |
<Blockhead256> I don't think he can even walk over 1m gaps |
| 16:46 |
erle |
luatic i actually think that most stuff should be opt-in so to not break existing usage |
| 16:54 |
luatic |
erle: a system extending the existing one need not break usage |
| 16:55 |
luatic |
but real physics is so far apart from luanti physics that i don't think it can easily be safely extended without breaking things |
| 17:02 |
MTDiscord |
<nathan4220776> There is always the option of using a bunnch of #defines. |
| 17:03 |
MTDiscord |
<nathan4220776> That way, it can be broken only if the developer want to break things. |
| 17:03 |
|
Talkless joined #luanti |
| 17:05 |
|
kimapr__ joined #luanti |
| 17:16 |
jonadab |
Actual real-world physics is not a desirable goal. Excessive focus on realism is the enemy of fun gameplay. |
| 17:16 |
MTDiscord |
<nathan4220776> Not necessarily. |
| 17:17 |
[MatrxMT] |
<Blockhead256> yes, but considering the history with "features" like Sneak-glitching, well.. what we have often lives much to be desired |
| 17:17 |
jonadab |
I'm not saying you can't ever make anything realistic at all in any way. Just that there's always a limit to how far it's worth taking it. |
| 17:17 |
MTDiscord |
<nathan4220776> For instance, I would love to see a long-range artillery mod with a range of 10s of kilometers (kilonodes). The math to do this isn't that difficult, but it's hard to get the motivation to do server-side stuff. |
| 17:17 |
[MatrxMT] |
<Blockhead256> s/lives/leaves |
| 17:18 |
MTDiscord |
<nathan4220776> Maybe I will actually do that someday. |
| 17:18 |
[MatrxMT] |
<Blockhead256> you only have 60 km of distance to work with, so no ICBMs |
| 17:18 |
MTDiscord |
<nathan4220776> I was thinking of stuff like mortars and howitzers. |
| 17:18 |
jonadab |
You want to implement a voxel-based version of Scorched Earth? |
| 17:19 |
MTDiscord |
<nathan4220776> Something more than just point-blank range like most weapons tend to be in video games... |
| 17:19 |
MTDiscord |
<nathan4220776> Not necessarily just scorched earth. |
| 17:19 |
MTDiscord |
<nathan4220776> I just want to see more long-range combat in games. |
| 17:20 |
[MatrxMT] |
<Blockhead256> would be nice if that could work with farmesh + binoculars for spotting that can see in more detail |
| 17:20 |
jonadab |
I mean, in a sense, some games (e.g., NetHack) have unlimited-range combat. Scroll of genocide counts, right? |
| 17:21 |
|
Kimapr_ joined #luanti |
| 17:21 |
[MatrxMT] |
<Blockhead256> > Confused effect: You genocide your own role, causing instadeath. |
| 17:21 |
[MatrxMT] |
<Blockhead256> lol |
| 17:24 |
erle |
> considering the history with "features" like Sneak-glitching |
| 17:24 |
erle |
it's an ascended glitch |
| 17:24 |
erle |
like bunnyhopping, plasmasliding, rocketjumping |
| 17:27 |
jonadab |
@Blockhead256 : NetHack has a ton of those sorts of funny gotchas. |
| 17:28 |
erle |
btw two things that are relatively easily implementable in the engine but are often mentioned as an argument for CSMs are entity path prediction and the red flash you get even when fall damage is canceled |
| 17:29 |
jonadab |
The best argument for CSMs isn't any specific thing you can think of, it's the things you _haven't_ thought of. |
| 17:29 |
jonadab |
That's true for mods in general, actually. |
| 17:30 |
erle |
yet, strangely, i have never seen an engine patch that addressed the path thing (e.g. by saving a movement path or just future waypoints in the entity meta if you want to KISS) or something that makes zero fall damage result in not having a flash (which is trivial) |
| 17:30 |
erle |
jonadab which gets back to the domain thing |
| 17:31 |
erle |
if you say “i need turing complete input so i can do things i have never thought of” means you think it is not a worthwhile endeavour to map the domain to discrete concepts you can express declaratively |
| 17:31 |
erle |
doesn't matter if that is because this is an inherent property of the domain or lack of skill |
| 17:32 |
erle |
although for domains that have been “solved” you can pretty much see when it's a lack of skill |
| 17:33 |
|
mrkubax10 joined #luanti |
| 17:34 |
erle |
e.g. people failing to do things with not-turing-complete languages that are, in principle, achievable. many (but not all) animations in browsers can be done in a declarative way (using CSS animations/transitions or SMIL) but people use JS for it simply because of a lack of skill. |
| 17:35 |
luatic |
erle: i love your examples because they completely obliterate your point |
| 17:36 |
erle |
wdym? |
| 17:36 |
luatic |
for example, you want an entity moving on a predefined path? you could do that today with the model features |
| 17:36 |
luatic |
you could even send such models to the client dynamically |
| 17:37 |
erle |
i have written both js and non-js animations and i am pretty sure almost everyone i have seen who does js animations would be unable to make a declarative solution if their life depended on it |
| 17:37 |
luatic |
bone overrides (interpolatable) also |
| 17:37 |
luatic |
point being, model file formats have offered declarative solutions here |
| 17:37 |
luatic |
only problem is its inaccessible and hard to dynamize properly |
| 17:38 |
erle |
wdym dynamize |
| 17:38 |
luatic |
actually the dynamize point may be wrong |
| 17:38 |
luatic |
somewhat at least, hmm.. depending on if you want to use attachments or bake the model in |
| 17:38 |
luatic |
erle: i mean being able to change the path at runtime |
| 17:38 |
|
SFENCE joined #luanti |
| 17:39 |
luatic |
anyways representing "the red flash you get even when fall damage is canceled" as an "often mentioned argument for SSCSM" is a misrepresentation |
| 17:39 |
luatic |
the entity paths get closer, but still doesn't cut it |
| 17:39 |
luatic |
one thing which is really often mentioned: player physics |
| 17:40 |
luatic |
well, the more precise term is controls |
| 17:40 |
luatic |
contrary to your assertions, you can not do that well with a declarative server centric api. not if you want to give game devs freedom. |
| 17:40 |
luatic |
client logic must react in the blink of an eye to client inputs |
| 17:41 |
luatic |
and trying to somehow map every possible reasonable "player control function" in a declarative api will just result in bloatware which nobody knows how to utilize or maintain properly |
| 17:42 |
erle |
luatic i don't understand how you think that agreeing with me that two things (paths and no red flashes) can be done without CSMs applies to something else entirely |
| 17:45 |
luatic |
i'm saying your examples show you're focusing on the wrong things. these are not the major points in favor of SSCSM. and these are things which in principle limited other solutions exist for. |
| 17:45 |
luatic |
let me give some other examples in no particular order: |
| 17:46 |
erle |
i think you are misunderstanding the point i am making |
| 17:46 |
erle |
what i am saying is that these are weak points AND the people arguing them have not made an effort to remedy it using server-side mitigations AFAIK |
| 17:46 |
luatic |
yes, that i can agree with |
| 17:47 |
erle |
which does help in mapping the domain |
| 17:47 |
luatic |
but this is not representative of the average SSCSM supporter, i would hope |
| 17:47 |
erle |
e.g. your zeroing in on control schemes. celeron55 has also brought the example of an airplane. i would give you the example of elytra flight in mineclonia. |
| 17:47 |
luatic |
another example |
| 17:47 |
luatic |
particles. this is something i thought about recently. someone was asking for more particle spawner features. for the time being, the solution i suggested and implemented is to make add_particle more efficient (less network traffic) by batching and compressing. |
| 17:48 |
luatic |
(they want particular shapes and things for fireworks) |
| 17:48 |
luatic |
but it would be preferrable if they could just tell the client "spawn a heart firework" and the client had the logic to do that |
| 17:49 |
erle |
ultimately the “fireworks” thing leads to “i want a particle definition that is associated to a state”, so you need a binding to a state and a particle position/effect DSL |
| 17:49 |
luatic |
of course it is possible to always extend the particle spawner api, and that has been done a few times, but at some point it just becomes too much of a bottleneck |
| 17:49 |
luatic |
erle: you'll pretty soon arrive at a solution that essentially boils down to "i need to send a list of particles" and that sucks a bit i think |
| 17:49 |
luatic |
like take this example. say i want an exploding heart. i need at least positions, possibly velocities. |
| 17:50 |
luatic |
someone else might want to do an exploding image using particles. they need textures (colors) on top. |
| 17:50 |
luatic |
batching with compression is actually a half decent solution, because all the redundant properties can be optimized out pretty well by the compression, with little effort |
| 17:51 |
luatic |
anyways i gotta work on something else |
| 17:53 |
erle |
luatic do you know this library call irrlicht? it has a function to emit particles from the vertices of a mesh |
| 17:54 |
erle |
i mean batching with compression is also a good first approximation for a lot of stuff |
| 17:55 |
erle |
(you have to choose your compression right ofc to get the most bang for your buck) |
| 17:55 |
erle |
but it's not like no one has ever made a usable fireworks API |
| 17:57 |
erle |
i interpret “at some point it just becomes too much of a bottleneck” as “i am not maintaining that shit” and IMO that means you have come upon a fundamental social issue: when APIs are implemented/maintained by people who have no “skin in the game”, no “stake”, you get tension. |
| 17:58 |
erle |
one solution to avoid that is having subsystem maintainers who are personally invested, but i have a guess that this is not a thing ever |
| 17:58 |
erle |
(in luanti) |
| 18:06 |
|
kimapr__ joined #luanti |
| 18:08 |
|
CRISPR joined #luanti |
| 18:30 |
|
fluxionary_ joined #luanti |
| 18:31 |
luatic |
"not a thing ever" is patently untrue |
| 18:35 |
|
SFENCE joined #luanti |
| 19:50 |
|
imi joined #luanti |
| 20:16 |
|
silverwolf73828 joined #luanti |
| 20:25 |
|
CRISPR joined #luanti |
| 21:13 |
bgstack15 |
repetitivestrain: I think your CSM somehow hides the player indicator on a crafted map, in-game. When I use the mainline Luanti client, I can see my little indicator on a map where I am. When I use the mineclonia client with CSM, I don't see that indicator. |
| 21:14 |
bgstack15 |
Would you like me to file an issue against your mcl_localplayer repo about this? |
| 21:21 |
|
Thermoriax joined #luanti |
| 21:44 |
|
SwissalpS joined #luanti |
| 21:50 |
|
greeter joined #luanti |
| 22:04 |
|
Kimapr_ joined #luanti |
| 22:33 |
|
panwolfram joined #luanti |
| 22:45 |
|
chilledfrogs joined #luanti |
| 23:00 |
|
Kimapr_ joined #luanti |
| 23:05 |
|
Eragon joined #luanti |
| 23:14 |
|
YuGiOhJCJ joined #luanti |
