| Time |
Nick |
Message |
| 00:03 |
|
hwpplayer1 joined #luanti-dev |
| 00:19 |
[MatrxMT] |
<Zughy> :/ |
| 01:01 |
MTDiscord |
<greenxenith> Of all the features that make sense for CSM, controlling the camera mode is not one of them |
| 01:01 |
MTDiscord |
<greenxenith> The server will end up sending a packet either way, having a csm on the other end is extra steps |
| 01:02 |
MTDiscord |
<greenxenith> Furthermore, CSMs will end up supplementing a lot of existing features anyway so there is no point worrying about server-side features in the meantime |
| 03:50 |
|
SFENCE joined #luanti-dev |
| 04:49 |
MTDiscord |
<exe_virus> Camera control client side could be helpful, but yeah also game breaking, and cheating too |
| 04:50 |
MTDiscord |
<exe_virus> But also controlling clients in an open source world... That's impossible even in a closed source world |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 05:41 |
|
SFENCE joined #luanti-dev |
| 06:20 |
|
SFENCE joined #luanti-dev |
| 06:52 |
|
SFENCE joined #luanti-dev |
| 06:53 |
MTDiscord |
<andrey2470t> Yes, but only once, at the mods load time |
| 06:55 |
MTDiscord |
<andrey2470t> Why cheating? |
| 06:58 |
MTDiscord |
<greenxenith> How many times it sends a packet depends on what is controling the camera mode. If the information for that is server-side, the server will have to send an update packet every time regardless. If its only a one-time update, a CSM is pointless. The only advantage a CSM has is in the specific case where the relevant data is entirely CSM-accessible (which is not guaranteed) |
| 07:01 |
MTDiscord |
<greenxenith> CSM is not some magic bullet for a lot of things. There is still a lot of data that remains server-side exclusively where the server will need to send information for the client to do anything useful. |
| 07:09 |
MTDiscord |
<andrey2470t> Well in the given of the case the camera locates only client-side, so the server-side mod would send the CSM code once. Any only client-related info could be implemented via the CSM like setting entity animation params, lighting, bone overrides. However in the case of updating the object position/velocity there will be possibly more packets sent as the server is also busy with their updating, but it will be necessary only for the sync |
| 07:10 |
MTDiscord |
<greenxenith> The camera mode may be updated during runtime using data the CSM has no access to. |
| 07:14 |
MTDiscord |
<greenxenith> Case 1: The camera mode is only set once on join; A CSM here has no advantage over server calls because a packet is sent for the change anyway. Case 2: The camera mode is set during runtime based on private server-side data; A CSM does not have access to the data, so a packet is required anyway. Case 3: The camera mode is set during runtime based on "public" client-accessible data; A CSM is more efficient at determining and setting |
| 07:14 |
MTDiscord |
the mode. Case 1 is the most likely use case. Camera mode being updated during runtime is reasonable but not likely to occur often, so the performance advantage of saving a single packet once ever so often is tiny. And frankly its better to have a simple working solution now that can be perfected later (seeing as we are becoming more comfortable making changes these days) |
| 07:18 |
MTDiscord |
<andrey2470t> > There is still a lot of data that remains server-side exclusively where the server will need to send information for the client to do anything useful. It's yes, but it would be good to unload it as much as it is possible to decrease the lag on servers |
| 07:18 |
MTDiscord |
<greenxenith> It would be good but that is irrelevant to the operation at hand |
| 07:19 |
MTDiscord |
<greenxenith> The reality is we have no SSCSM API right now and will not likely have a stable SSCSM API for a while, and this is a feature that people have wanted for a long time. |
| 07:45 |
MTDiscord |
<andrey2470t> Well possibly the camera mode changing is not that case where SSCSM would help much. But it would actually do that where the pretty frequent packets updates occur like changing the entities velocity/position, especially for the transport/mobs. Another variant of avoiding the visible lag is doing the interpolation client-side |
| 07:50 |
MTDiscord |
<greenxenith> Sure, that is a perfectly viable reason for SSCSM, and once again, entirely irrelevant to the commit in question. |
| 07:51 |
MTDiscord |
<greenxenith> Im not saying we shouldnt have SSCSM. I am saying we shouldnt block this feature waiting on it. |
| 08:02 |
MTDiscord |
<andrey2470t> But the more features will be implemented server-side the more cases will be where you will need to rely on the backward-compatibility with the conventional mods which have already used that API. It will actually lead to the code duplicating for the CSM and SSM (which differs mostly with that first one doesn't send anything, the second one does) |
| 08:04 |
MTDiscord |
<greenxenith> CSM will introduce API duplication regardless. I would also go as far as suggesting CSM should be a 6.0 target where we break a lot of the API for the sake of an objectively better engine. |
| 08:19 |
|
YuGiOhJCJ joined #luanti-dev |
| 09:22 |
|
Warr1024 joined #luanti-dev |
| 09:46 |
|
Warr1024 joined #luanti-dev |
| 10:27 |
MTDiscord |
<andrey2470t> But just don't create the API duplication still more in the future |
| 12:25 |
[MatrxMT] |
<Zughy> I've scheduled the next meeting for next Sunday, since last one was the IRL we had at FOSDEM |
| 12:28 |
MTDiscord |
<exe_virus> As to the cheating: Imagine: hide and seek game Any game with traps RTS without fog of war Any PvP Etc. With complete csm camera control, you can effectively look just about anywhere from any angle, that you have data from the server for. That will always be a problem, because I can recompile luanti with such features myself. Luckily we already can say "no CSMs" for the normal people of the world as a server setting. That's about as |
| 12:28 |
MTDiscord |
strong of a defense we'll ever have |
| 14:06 |
MTDiscord |
<andrey2470t> You can do that actually without CSMs by editing the existent Camera and LocalPlayer classes logic engine-side |
| 14:38 |
MTDiscord |
<mistere_123> @andrey2470t, sscsm makes sense for controlling the camera but not for setting the hardcoded camera mode. |
| 14:39 |
sfan5 |
this point is really not that important |
| 14:40 |
sfan5 |
the reason I made this PR now is that having a partial feature now is better than having a full-featured client-side API in 3 years |
| 14:40 |
MTDiscord |
<andrey2470t> It makes sense not to overload the server and network |
| 14:40 |
sfan5 |
and when it comes to the latter we have to rework or remove the existing APIs anyway |
| 14:41 |
|
SFENCE joined #luanti-dev |
| 14:41 |
MTDiscord |
<mistere_123> Andrey, I see no reason that a game developer would rapid-fire change the camera mode, hence, no network overload. |
| 14:42 |
MTDiscord |
<mistere_123> They would set it once and leave it for at least several minutes |
| 14:42 |
MTDiscord |
<andrey2470t> But you will break the compatibility with the mods which already used the APIs, if you remove that, really not? |
| 14:42 |
sfan5 |
that would be the case, yes |
| 14:42 |
sfan5 |
like someone suggested earlier Luanti 6.0 would be a good occasion to do it |
| 14:43 |
MTDiscord |
<mistere_123> sscsm camera control would be assumed to be a whole other camera paradigm than the cu]rent hardcoded options |
| 14:44 |
MTDiscord |
<mistere_123> which we may expand with more options in the meantime, but let's avoid premature optimization here |
| 14:45 |
sfan5 |
fwiw if someone has good ideas that fit into the current API paradigm we can add them |
| 14:46 |
sfan5 |
i was thinking maybe a fixed camera position. and restricting yaw/pitch to ranges |
| 14:47 |
MTDiscord |
<andrey2470t> That will just add the unnecessary data sending over the network and considering that already enough much of the current APIs do that, that will only amplify the general network overload. I just suggested to think about that before merging to avoid potentially still worse lag than it usually exists on the servers and even on the singleplayer now |
| 14:48 |
sfan5 |
preventing lag is on the modder, the API is just a tool. |
| 14:48 |
sfan5 |
you're obviously not supposed to try to implement by-frame panning motion using it |
| 14:48 |
MTDiscord |
<wsor4035> Seems the saying of don't let perfect be the enemy of good Is apt here |
| 14:49 |
MTDiscord |
<mistere_123> sfan5: other camera modes that follow predetermined rules? Your suggestion, and maybe a top-down camera like the game Extra Ordinance implements hackily |
| 14:49 |
MTDiscord |
<andrey2470t> Of course it will expand, but why avoid the optimizations? |
| 14:50 |
sfan5 |
which optimization are you proposing? pulling working SSCSM out of a hat so we can move it to the client? |
| 14:51 |
MTDiscord |
<mistere_123> because the optimization in this case is: don't do it uyil some unknown future date when we will be implementing a whole other paradigm |
| 14:51 |
sfan5 |
@mistere_123 locking to angle to (0, -1, 0) and setting the offset should cover that, no? |
| 14:52 |
MTDiscord |
<mistere_123> sfan5: no, EO involves camera contols such as sweep, camera velocity, interpolation |
| 14:52 |
MTDiscord |
<mistere_123> not possible without moving the player, and not possible without jank from lag |
| 14:53 |
sfan5 |
i don't know the game. was just guessing from "top-down camera" |
| 14:54 |
MTDiscord |
<mistere_123> if some basic rts client camera controls were implemented that would be ideal. Go load up Extra Ordinance. it's quick, and every developer should play it because its basically an engine feature request |
| 14:54 |
rubenwardy |
Extra ordinance has an orbit camera. So focuses on a position and rotates around that, fixed height |
| 14:54 |
rubenwardy |
It's janky because engine issues |
| 14:55 |
sfan5 |
sounds like third-person with some adjustments |
| 14:57 |
|
Desour joined #luanti-dev |
| 14:57 |
MTDiscord |
<andrey2470t> Apparantly the engine should prevent the lag too and it should have the APIs which would facilitate that. The mods won't help in that if the engine can't because the first ones depend on the second ones |
| 14:58 |
MTDiscord |
<mistere_123> yes, but those adjustments are so significant as to be a separate camera mode with a whole lot more movement than our 3rd person. It's implemented by moving the player around as a camera, which is jank in multiplayer. Just play it to see what we mean? |
| 14:58 |
MTDiscord |
<andrey2470t> I already said which one here and on the github PR |
| 14:59 |
MTDiscord |
<mistere_123> sfan cannot see replies |
| 14:59 |
MTDiscord |
<mistere_123> from discord |
| 15:01 |
MTDiscord |
<andrey2470t> Hmm, don't they save in the IRC logs? |
| 15:02 |
Krock |
https://irc.luanti.org/ |
| 15:06 |
Desour |
I'd like to add that a simple server API such as setting the camera mode can later easily be reimplemented in sscsm client builtin |
| 15:06 |
Desour |
basically, the plan that I have in sight is that we replace all the server APIs by giving the server packet to the SSCSM client builtin, which then uses the SSCSM API to implement the server feature |
| 15:08 |
Desour |
we might also want to add some *more* features like this to the server API *after* we have a stable SSCSM API, just to make modding on the server easier |
| 15:09 |
MTDiscord |
<mistere_123> @andrey2470t also a way in which backwards compatibility could be maintained with eventual SSCSM control is to have another camera mode call "sscsm" at which point the server expects the cliento control the camera. Otherwise it remains hardcoded with first or third |
| 15:09 |
Desour |
and so if SSCSM ends up in a state where people don't want to enable it at all, modders can still be a bit happy |
| 15:11 |
MTDiscord |
<andrey2470t> @MisterE well, generally my suggestion is reflected on the github PR and here in my replies it doesn't differ from that |
| 15:11 |
Desour |
@mistere: or in SSCSM add an API where you can tell the client builtin to not control the camera (basically the same idea, but controlled by SSCSM, not SSM) |
| 15:11 |
Krock |
on a side project I found it helpful to have a shared API of server and client. Both perform similar actions (such as repositioning entities). Where it matters, abstraction can provide functions for server- or client-specific behaviour. |
| 15:13 |
Krock |
the client cannot predict everything, thus the server has to send some sort of trigger. whether or not that's a camera update packet doesn't really matter. |
| 15:18 |
MTDiscord |
<andrey2470t> To be honest I'd wait for the SSCSM control to implement the features correctly from the first time and won't do the workarounds like that later |
| 15:19 |
MTDiscord |
<andrey2470t> @MisterE To be honest I'd wait for the SSCSM control to implement the features correctly from the first time and won't do the workarounds like that later |
| 15:23 |
MTDiscord |
<mistere_123> @andrey2470t We already have first and 3rd person hardcoded camera modes. It is currently negatively affecting the user experience that the server cannot set the mode for games that are made for 3rd person. I have made 2 games that are really only good in the 3rd person, and it is bad that I have to use an ingame sign to tell players. SSCSM is an overkill solution for this problem. |
| 15:35 |
[MatrxMT] |
<Zughy> +1 ^ |
| 15:38 |
MTDiscord |
<andrey2470t> I don't say we don't need in the controlling the camera mode as it is absolutely useful for modders, I just say it should be correctly implemented not to suffer from the negative consequences of the wrong designed API further |
| 15:40 |
MTDiscord |
<andrey2470t> Furthermore, we already have such consequences from the similar approach, so don't do it more |
| 15:40 |
MTDiscord |
<mistere_123> we already have an incorrect design and this is a step in the right direction |
| 15:41 |
MTDiscord |
<andrey2470t> In the right one? |
| 15:42 |
SFENCE |
I feel litle flustrated. Google ANGLE implements KHR_debug, but for Metal angle glObjectLabel function is implemented, but when is called, it say that it require openGLES 3.2. But I do not think, that it is good idea to limit calling of it by OpenGLES version, because this is probably imlementation depend behaviors. I found no info, that glObjectLabel should be avaliable only from specific GLES version. |
| 15:52 |
Desour |
SFENCE: have you tried using EXT_debug_label as fallback? |
| 15:55 |
Desour |
(this here: <https://registry.khronos.org/OpenGL/extensions/EXT/EXT_debug_label.txt>) |
| 15:59 |
SFENCE |
Hmm... I will try it. Thanks. |
| 16:44 |
|
hwpplayer1 joined #luanti-dev |
| 16:49 |
|
SFENCE_arch joined #luanti-dev |
| 16:49 |
|
SFENCE joined #luanti-dev |
| 17:14 |
|
hwpplayer1 joined #luanti-dev |
| 17:35 |
MTDiscord |
<andrey2470t> Also, the absence of the useful client-side features would be an additional motivator to promote SSCSM. If the most of them will be present in the way of the camera mode was added recently, I think there's a more possibility it will be delayed longer and barely got released |
| 17:45 |
SFENCE |
Ok. I replaced glObjectLabel with glLabelObjectEXT, with identificator change from GL_PROGRAM to GL_PROGRAM_OBJECT_EXT. Error log from this call disappear. But we are also calling it with GL_TEXTURE identificator, which has no replace. Potencial problem is that we also use something like glObjectLabel(GL_TEXTURE, ...) somewhere... and there is no eqivalent identifier for glLabelObjectEXT. |
| 17:48 |
|
SFENCE joined #luanti-dev |
| 17:50 |
sfan5 |
so essentially it's not supported at all |
| 17:54 |
|
SFENCE joined #luanti-dev |
| 17:55 |
SFENCE_arch |
sfan5: Looks more like some bug in Google ANGLE implmenentation. If they support only OpenGLES 3.0 translating to Metal, and glObjectLabel needs at least 3.2 GLES, they should not privide pointer to that function probably. I will ask them how that should be checked correctly. |
| 17:57 |
sfan5 |
implementations are allowed to provide bogus pointers if the user doesn't check extensions |
| 17:57 |
sfan5 |
but we do |
| 17:58 |
|
SFENCE joined #luanti-dev |
| 18:02 |
|
SFENCE joined #luanti-dev |
| 18:02 |
SFENCE_arch |
Yes we checked externsion, we load function pointer, get it and we get error when function is called.Sounds like unexpected behaviors. |
| 18:15 |
|
SFENCE joined #luanti-dev |
| 18:36 |
|
SFENCE joined #luanti-dev |
| 18:53 |
|
SpaceManiac joined #luanti-dev |
| 19:00 |
|
SpaceManiac joined #luanti-dev |
| 19:27 |
MTDiscord |
<mistere_123> so refuse all sorts of features that are needed now because they could be implemented by sscsm? I don't think that's a good policy. |
| 19:45 |
|
SpaceManiac joined #luanti-dev |
| 19:58 |
|
SFENCE joined #luanti-dev |
| 20:01 |
SFENCE_arch |
Do I understand it well, that on Android, users have to access to their world data to do some backups/move of them for example? |
| 20:01 |
|
SFENCE joined #luanti-dev |
| 20:15 |
|
pattmax joined #luanti-dev |
| 20:19 |
sfan5 |
i think they don't. this problem has been brought up |
| 21:05 |
|
mark-wiemer joined #luanti-dev |
| 21:06 |
mark-wiemer |
SFENCE_arch: You can look at https://docs.luanti.org/for-players/mobile/, but I think it's a bit outdated. Let me know what you find and I'm happy to update the page :) |
| 21:15 |
MTDiscord |
<andrey2470t> @MisterE well I would like to get the features qualitatively made without the janks. There are two ways: 1. either the feature is implemented now without SSCSM, simply, fast, but sloppy and involving the tech debt (which is already piled up to the limit thoughout the engine) and also the compatibility issues. 2. or wait until SSCSM gets implemented (it could be faster, if the contributors are motivated recognizing it could bring in a |
| 21:15 |
MTDiscord |
large potential for the mods), afterwards implement the feature by the proper way without fixing that in the future. As for me, the second variant outweighs the first one. |
| 21:19 |
MTDiscord |
<greenxenith> If it outweighs the first for you, feel free to implement SSCSM yourself. We all fully recognize the importance of SSCSM, but that doesnt magically make it appear quickly. |
| 21:54 |
MTDiscord |
<andrey2470t> I said in the second one I would wait for that, but I didn't state I would start implement (actually there are already corresponding open PRs, so why will I do the same thing from the scratch?). And I didn't state anywhere it would appear quickly, vice versa it should be thoroughly thought out and not implemented in a hurry |
| 21:54 |
MTDiscord |
<andrey2470t> I said in the second one I would wait for that, but I didn't state I would start implement (actually there are already corresponding open PRs, so why will I do the same thing from the scratch?). And I didn't state anywhere it would appear quickly, vice versa it should be thoroughly thought out and not implemented in a hurry |
| 23:01 |
|
YuGiOhJCJ joined #luanti-dev |
| 23:21 |
|
rdeforest joined #luanti-dev |
| 23:34 |
|
Sharpman joined #luanti-dev |
| 23:34 |
|
panwolfram joined #luanti-dev |
