Time Nick Message 00:19 [MatrxMT] :/ 01:01 MTDiscord Of all the features that make sense for CSM, controlling the camera mode is not one of them 01:01 MTDiscord The server will end up sending a packet either way, having a csm on the other end is extra steps 01:02 MTDiscord 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 04:49 MTDiscord Camera control client side could be helpful, but yeah also game breaking, and cheating too 04:50 MTDiscord But also controlling clients in an open source world... That's impossible even in a closed source world 06:53 MTDiscord Yes, but only once, at the mods load time 06:55 MTDiscord Why cheating? 06:58 MTDiscord 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 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 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 The camera mode may be updated during runtime using data the CSM has no access to. 07:14 MTDiscord 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 > 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 It would be good but that is irrelevant to the operation at hand 07:19 MTDiscord 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 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 Sure, that is a perfectly viable reason for SSCSM, and once again, entirely irrelevant to the commit in question. 07:51 MTDiscord Im not saying we shouldnt have SSCSM. I am saying we shouldnt block this feature waiting on it. 08:02 MTDiscord 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 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. 10:27 MTDiscord But just don't create the API duplication still more in the future 12:25 [MatrxMT] I've scheduled the next meeting for next Sunday, since last one was the IRL we had at FOSDEM 12:28 MTDiscord 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 You can do that actually without CSMs by editing the existent Camera and LocalPlayer classes logic engine-side 14:38 MTDiscord @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 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 MTDiscord Andrey, I see no reason that a game developer would rapid-fire change the camera mode, hence, no network overload. 14:42 MTDiscord They would set it once and leave it for at least several minutes 14:42 MTDiscord 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 sscsm camera control would be assumed to be a whole other camera paradigm than the cu]rent hardcoded options 14:44 MTDiscord 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 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 Seems the saying of don't let perfect be the enemy of good Is apt here 14:49 MTDiscord 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 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 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 sfan5: no, EO involves camera contols such as sweep, camera velocity, interpolation 14:52 MTDiscord 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 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 MTDiscord 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 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 I already said which one here and on the github PR 14:59 MTDiscord sfan cannot see replies 14:59 MTDiscord from discord 15:01 MTDiscord 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 @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 @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 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 @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 @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] +1 ^ 15:38 MTDiscord 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 Furthermore, we already have such consequences from the similar approach, so don't do it more 15:40 MTDiscord we already have an incorrect design and this is a step in the right direction 15:41 MTDiscord 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: ) 15:59 SFENCE Hmm... I will try it. Thanks. 17:35 MTDiscord 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:50 sfan5 so essentially it's not supported at all 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 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. 19:27 MTDiscord 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. 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:19 sfan5 i think they don't. this problem has been brought up 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 @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 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 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 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