Time |
Nick |
Message |
00:01 |
MTDiscord |
<GreenXenith> basically string interpolation |
00:01 |
schwarzwald[m] |
I should really find something useful to PR, but I've had trouble getting the confidence or the time. |
00:02 |
Zughy[m] |
well, there are a lot of bugs ? |
00:02 |
MTDiscord |
<GreenXenith> See if theres any smaller bug issues |
00:03 |
Zughy[m] |
#10037 is very annoying, for instance |
00:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/10037 -- Physics override not working properly when speed is set to 0 while moving |
00:03 |
schwarzwald[m] |
The dunning-kruger effect must not work on me because I know I have absolutely no idea what I'm doing and then do it wrong anyway. ?️ |
00:05 |
Zughy[m] |
and I guess #12403 is easier |
00:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/12403 -- `is_visible = false` doesn't work on players |
00:05 |
Zughy[m] |
(yes, I'm pushing my reports) |
00:05 |
MTDiscord |
<GreenXenith> whats your opinion on the element syntax above, zughy |
00:06 |
MTDiscord |
<GreenXenith> and should I bother using something like it for the main menu |
00:07 |
Zughy[m] |
can't really say, I'm a simple mind, I see a formspec, I want to cry |
00:07 |
MTDiscord |
<GreenXenith> thats fair |
00:07 |
MTDiscord |
<GreenXenith> Speaking of though, how would a "better" GUI system even work |
00:07 |
MTDiscord |
<GreenXenith> the string based system structure-wise isnt awful |
00:08 |
MTDiscord |
<GreenXenith> the only other established systems are usually tag-based ([ht,x]ml) |
00:10 |
MTDiscord |
<GreenXenith> meh, pointless exercise for now. Ill get back to main menuing. |
00:13 |
schwarzwald[m] |
> I see a formspec, I want to cry |
00:13 |
schwarzwald[m] |
Zughy might've accidentally hinted at one possible solution. It's not necessary for modders to ever manually write formspecs. They could be in a binary format for that matter, although I think there's a lot of value in them being human readable. They could be generated using tooling and stored in their own file format. |
00:14 |
schwarzwald[m] |
Even the existing formspec language could be used that way, and nobody would ever have to look at formspec code again. But if the tooling stops being maintained, nothing is lost, as the format is simple to modify by hand if necessary, or write new tooling for. |
00:17 |
Zughy[m] |
related: #6527 |
00:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/6527 -- Formspec replacement |
00:20 |
|
YuGiOhJCJ joined #minetest-dev |
00:29 |
|
YuGiOhJCJ joined #minetest-dev |
00:36 |
|
YuGiOhJCJ joined #minetest-dev |
00:47 |
|
Soni joined #minetest-dev |
01:13 |
|
Baytuch joined #minetest-dev |
01:53 |
|
Baytuch joined #minetest-dev |
03:40 |
|
Baytuch joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
04:04 |
|
cheapie joined #minetest-dev |
04:07 |
|
erle joined #minetest-dev |
04:15 |
|
Baytuch joined #minetest-dev |
04:37 |
|
BuckarooBanzai joined #minetest-dev |
04:38 |
|
Krock joined #minetest-dev |
05:30 |
|
Baytuch joined #minetest-dev |
05:42 |
|
calcul0n joined #minetest-dev |
05:45 |
|
calcul0n joined #minetest-dev |
06:14 |
|
independent56 joined #minetest-dev |
06:20 |
|
erle joined #minetest-dev |
09:25 |
|
independent56 joined #minetest-dev |
09:27 |
|
independent56 joined #minetest-dev |
09:40 |
MTDiscord |
<luatic> I had considered this too but ultimately rejected it. I went with S-expressions instead: {"label", {1,2}; "foo bar"} |
10:01 |
|
independent56 joined #minetest-dev |
10:09 |
|
calcul0n_ joined #minetest-dev |
11:08 |
|
independent56 joined #minetest-dev |
11:12 |
|
appguru joined #minetest-dev |
11:18 |
MTDiscord |
<Warr1024> Of course, what we need for a formspec replacement is yet another bespoke syntax instead of something like JSON or Lua that we already have serializers for. |
11:42 |
|
independent56 joined #minetest-dev |
12:07 |
kilbith |
https://www.youtube.com/watch?v=16M3PJu1zfw |
12:07 |
kilbith |
Camera API (WIP) |
12:07 |
kilbith |
this is a static camera, not the traditional CameraFPS with mouse events |
12:24 |
kilbith |
I'm tempted to make a lower level API to draw on-screen, without going through the HUD and the GUI; it could be something like: camera:draw(x, y, w, h) |
12:25 |
kilbith |
right on the screen, everything in pixels |
12:25 |
kilbith |
opinions? |
12:51 |
|
erle joined #minetest-dev |
13:01 |
kilbith |
nobody cares? |
13:07 |
|
proller joined #minetest-dev |
13:08 |
|
Taoki joined #minetest-dev |
13:16 |
Zughy[m] |
I do, the whole camera system is cool, but I don't have enough knowledge to answer the HUD thing |
13:17 |
Zughy[m] |
the Lua implementation seems clean though |
13:22 |
rubenwardy |
v-rob was woking on such a thing, as a client-side API |
13:22 |
rubenwardy |
a server-side API would be too slow for real time things, it would end up just being a way to make dynamic images to send |
13:25 |
kilbith |
uh no, there are no dynamic images involved |
13:26 |
kilbith |
each camera is drawn inside their respective viewport |
13:26 |
kilbith |
so it's realtime rendering of the scene |
13:27 |
kilbith |
besides, there's already a client-side camera API which is half-baked |
14:01 |
|
Fixer joined #minetest-dev |
14:03 |
MTDiscord |
<MisterE> So this would be good for cut scenes? What other usecases? |
14:08 |
|
Baytuch joined #minetest-dev |
14:10 |
kilbith |
that: https://www.youtube.com/watch?v=yGZHYut1gik |
14:11 |
kilbith |
camera:get_camera_texture() inside entity def |
14:15 |
|
proller joined #minetest-dev |
14:26 |
|
Baytuch joined #minetest-dev |
14:32 |
|
independent56 joined #minetest-dev |
15:01 |
|
proller joined #minetest-dev |
15:25 |
|
independent56 joined #minetest-dev |
15:28 |
rubenwardy |
reviewed and fixed #7865 could use another look |
15:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/7865 -- Add crosshair support for Android by srifqi |
15:28 |
rubenwardy |
s/could use/needs/ |
15:38 |
MTDiscord |
<MisterE> kilbith: so it could allow overlays and holograms? Yeah, id say theres interest |
15:40 |
MTDiscord |
<MisterE> In your code in the video, I don't see a reference to the player object. So how does it control just 1 player's camera? Or, maybe I'm still not understanding what it does :| |
15:41 |
kilbith |
> so it could allow overlays and holograms? Yeah, id say theres interest |
15:42 |
kilbith |
no, it means that a scene can be rendered in real-time onto an entity |
15:42 |
kilbith |
> So how does it control just 1 player's camera? |
15:43 |
MTDiscord |
<MisterE> Oh! So, real time portals? Non-euclidean spaces? Mirrors? Star field end portals? |
15:43 |
kilbith |
you can add a new camera object with Camera(), it's not tied to an ObjectRef |
15:43 |
kilbith |
unless you attach() it |
15:43 |
kilbith |
possibly mirrors, yes |
15:43 |
rubenwardy |
Is a camera a type of Object? Would be good to reuse the movement interpolation code |
15:43 |
rubenwardy |
and attachments |
15:44 |
rubenwardy |
just not necessarily serialisation |
15:44 |
MTDiscord |
<MisterE> kilbith: the blog isn't out yet. Do you want to write up a short paragraph about it? Or save it for another month? |
15:45 |
|
independent56 joined #minetest-dev |
15:45 |
kilbith |
moment |
15:45 |
kilbith |
I finish a meeting |
15:47 |
|
independent56 joined #minetest-dev |
16:05 |
|
independent56 joined #minetest-dev |
16:14 |
|
independent56 joined #minetest-dev |
16:16 |
kilbith |
so |
16:16 |
kilbith |
Camera is an independant object such as VoxelManip or ItemStack |
16:17 |
kilbith |
you can create it at init time or whatever |
16:18 |
kilbith |
you can create as much cameras as you want |
16:19 |
kilbith |
MisterE[m]: what are your expectations for the blog? |
16:19 |
kilbith |
a technical in-depth explanation? the use-cases? |
16:20 |
MTDiscord |
<MisterE> Conversational tone, an intro for general consumption that describes progress. Semi formal |
16:20 |
MTDiscord |
<MisterE> A screenshot would be great if appropriate |
16:20 |
Pexin |
can each camera exist in a separate coordinate space? so they dont see the same geometry? |
16:20 |
MTDiscord |
<MisterE> Make an issue against the blog |
16:20 |
kilbith |
I'll make a video instead |
16:21 |
MTDiscord |
<MisterE> That will be grent |
16:21 |
MTDiscord |
<MisterE> *great |
16:21 |
kilbith |
Pexin: examples? |
16:21 |
Pexin |
lots. but simple ones? ...uhh |
16:22 |
kilbith |
I intend to make the Camera coords system 1:1 with world coords |
16:22 |
Pexin |
well basically so you dont need to carce out a region |
16:22 |
Pexin |
carve |
16:24 |
MTDiscord |
<MisterE> How long do you think the blog submission would take you? More than two days we cant wait for but if its before that we can make that work. Ideally by the end of today though. Otherwise it can go into next month's post. |
16:25 |
MTDiscord |
<MisterE> as for details, if you think that the average person interested in minetest development would be interested, you can put it in. |
16:28 |
rubenwardy |
technically it's July already, so wouldn't be incorrect in next month's post :D |
16:29 |
erle |
is it already merged? |
16:29 |
erle |
i think teasing features should only happen if the users have some easy way to experience them (i.e. compile git HEAD) |
16:30 |
kilbith |
MisterE[m]: can it be tomorrow? |
16:30 |
MisterE[m] |
erle: No, the blog is for letting people know what devs are working on. |
16:30 |
erle |
ah i see |
16:30 |
erle |
i thought it was a “what's new” thing |
16:30 |
MisterE[m] |
kilbith: We can try for that kilbith |
16:30 |
MisterE[m] |
erle: That too erle |
16:30 |
MisterE[m] |
It just has to be described as what it is |
16:32 |
rubenwardy |
I'm hesistant to put super immature stuff there if it's still a long time away |
16:33 |
erle |
hmm, hmmm, maybe i can get cora to write something about how to place structures very fast (the trick is to make the minetest engine place decorations for you that unpack into buildings later, but i think she figured out a bit more about what is slow and what is fast) |
16:33 |
MisterE[m] |
erle: Ruben and I were discussing having special how-to articles. That would do nicely. |
16:34 |
rubenwardy |
content marketing |
16:34 |
erle |
well it is also help for using the engine. most structure placement code in mods is garbage in one way or the other. |
16:34 |
MTDiscord |
<MisterE> Write it, submit it as a PR or an issue, and we will review and post. |
16:35 |
erle |
sometimes the engine is at fault (it still can't place giant schematics IIRC), sometimes people make mapgen with a code flow that reminds me of spaghet |
16:35 |
MTDiscord |
<luatic> erle: TBH that belongs on the minetest_doc project rather than a "blog" |
16:35 |
erle |
i'd rather say it could go into the rubenwardy book maybe? |
16:35 |
rubenwardy |
detailed modding tutorials like that owuld be better on minetest_doc, yeah |
16:35 |
rubenwardy |
or my book |
16:35 |
MTDiscord |
<MisterE> Depends how its written? |
16:36 |
erle |
anyways, the blog surely could link to new book chapters |
16:36 |
rubenwardy |
the blog should be fairly high level rather than technical info |
16:36 |
rubenwardy |
ooh, could add the new book chapter to the blog post |
16:36 |
rubenwardy |
https://rubenwardy.com/minetest_modding_book/en/quality/translations.html |
16:37 |
kilbith |
rubenwardy: the PostProcessing thing by x2048 is a super immature as well, yet mentionned in the blog |
16:37 |
kilbith |
-a |
16:37 |
MTDiscord |
<MisterE> As is jordach's mapgen |
16:37 |
rubenwardy |
true. That has a lot of political buy in |
16:38 |
rubenwardy |
Jordach's map gen probably shouldn't have been in the blog post, would be lucky to ever see that :D |
16:38 |
kilbith |
btw that feature will be financially backed by new company I work in |
16:38 |
rubenwardy |
cameras or post processing? |
16:38 |
kilbith |
thats why I have time to develop it |
16:38 |
kilbith |
cameras |
16:39 |
MTDiscord |
<luatic> rubenwardy: found a typo "player’s lang,uage" |
16:39 |
rubenwardy |
thanks |
16:39 |
MTDiscord |
<MisterE> Jordach's mapgen can be used today tho, if you build a server form source. |
16:40 |
MTDiscord |
<luatic> MisterE: You could feature my revival of the bone override PR I guess |
16:40 |
MTDiscord |
<luatic> #12388 |
16:40 |
MTDiscord |
<MisterE> I think, that as long as very WIP features are known to be so, they should go in the blog. Maybe with lower priority than more likely to be merged soon feature |
16:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/12388 -- Extend bone override capabilities by appgurueu |
16:41 |
MTDiscord |
<luatic> Like most PRs, it is in ready for review limbo |
16:41 |
rubenwardy |
sure |
16:41 |
rubenwardy |
sure @MisterE |
16:41 |
rubenwardy |
Well, the average PR open time is plumetting recently at least |
16:41 |
rubenwardy |
*cough* #7865 *cough* |
16:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/7865 -- Add crosshair support for Android by srifqi |
16:42 |
MisterE[m] |
Something of the form ”kilbith is working on a PR that implements ...” |
16:42 |
rubenwardy |
The camera PR is on the roadmap at least, and is pretty awesome |
16:42 |
MTDiscord |
<luatic> in terms of likeliness to be merged, #12353 has been discussed during the last meeting, but I don't think fixing physics makes for an exciting blog post ? |
16:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/12353 -- Fix acceleration by appgurueu |
16:42 |
rubenwardy |
so as long as the tech works out it doesn't seem unlikely |
16:43 |
MisterE[m] |
To point is to generate interest in development, and inform everyone of what others are working on, so they know to follow the development. |
16:43 |
kilbith |
OpenMW is doing that |
16:43 |
kilbith |
0 A.D. as well |
16:43 |
MisterE[m] |
Doing what? |
16:44 |
kilbith |
blog marketing |
16:44 |
MisterE[m] |
Yeah. I specifically got the idea from Veloren |
16:44 |
erle |
i actually think the physics thing is a decent thing for a blog post |
16:44 |
erle |
you should probably ask fleck if it started in physics class lol |
16:45 |
MisterE[m] |
Well, people, you have 1.5 days or so to make submissions for this month's post |
16:45 |
erle |
given he was still in school when he noticed it was wrong |
16:45 |
MisterE[m] |
https://github.com/minetest/blog/issues |
16:45 |
MisterE[m] |
submit them there |
16:48 |
rubenwardy |
I've wanted a blog for years but didn't want to be the main person to do it, that's how it never gets updated regularly *looks at the twitter* |
16:49 |
rubenwardy |
Content marketting is a bit different than a blog with monthly/weekly updates. The idea behind content marketting is to appear more in search results |
16:50 |
rubenwardy |
for example, we could make an article about how to get started with making a game in Minetest, and then it could become a top result when someone searches "how to make voxel game" or whatever |
16:52 |
erle |
given the state of google i would not count on it |
16:53 |
Pexin |
seo is infernal black magic |
16:53 |
rubenwardy |
The monthly blog posts are great for communication with users though, it allows them to know we're doing stuff without crawling through github |
16:53 |
|
independent56 joined #minetest-dev |
16:53 |
erle |
i noticed that for some software i wrote its homepage is not even on the first page of search results – however, the first search results *link* to that page. so clearly, google is using something other than page rank and serving something else than useful results in this case. |
16:53 |
erle |
that is true |
16:54 |
kilbith |
there's need to focus on marketing this summer at least, after what happened to MC |
16:54 |
erle |
what happened to MC? |
16:55 |
erle |
i maintain that marketing in the sense of generating hype is bullshit, while marketing in the sense of providing useful information is not. |
16:55 |
kilbith |
https://www.reddit.com/r/Minetest/comments/vjqxwz/with_microsofts_latest_decision_to_police_chat_on/ |
16:55 |
MisterE[m] |
they implemented global chat monitering, even on anarchy servers, not sure about singleplayer. They if you say something they dont like, they can permaban you |
16:56 |
MisterE[m] |
spelling go brr |
16:56 |
erle |
LOL |
16:56 |
erle |
knowing microsoft, i bet if you are banned you can't even play on your private server or something |
16:56 |
MisterE[m] |
Minecraft is now a "safe Space" |
16:57 |
MisterE[m] |
e.g. no Freedom of speech |
16:58 |
MisterE[m] |
erle: this is correct IIUC |
16:58 |
ROllerozxa |
"i bet if you are banned you can't even play on your private server or something" yep, pretty much. no ability to play on multiplayer servers that rely on the mojang authentication servers |
16:58 |
schwarzwald[m] |
May I have permission to triage at least some parts of the Coverity report? The bugs I've been PRing fixes to haven't been marked yet. |
16:58 |
erle |
hilarious, but it has nothing to do with minetest, except for minetest being excactly unlike it |
16:59 |
erle |
schwarzwald[m] why do you need permission? |
17:01 |
schwarzwald[m] |
erle: Because I can't triage the report without permission. |
17:03 |
schwarzwald[m] |
Maybe only admins can triage it? I would hope there's a non-admin role that can triage but not upload builds. |
17:24 |
|
independent56 joined #minetest-dev |
17:33 |
|
independent56 joined #minetest-dev |
17:42 |
|
olliy joined #minetest-dev |
18:09 |
|
independent56 joined #minetest-dev |
18:17 |
|
independent56 joined #minetest-dev |
18:31 |
|
independent56 joined #minetest-dev |
18:52 |
|
independent56 joined #minetest-dev |
19:17 |
|
proller joined #minetest-dev |
19:19 |
|
panwolfram joined #minetest-dev |
19:26 |
|
independent56 joined #minetest-dev |
19:35 |
|
independent56 joined #minetest-dev |
19:38 |
|
independent56 joined #minetest-dev |
20:08 |
|
independent56 joined #minetest-dev |
20:11 |
|
independent56 joined #minetest-dev |
20:35 |
|
independent56 joined #minetest-dev |
20:57 |
|
independent56 joined #minetest-dev |
21:00 |
|
TheCoffeMaker joined #minetest-dev |
21:05 |
|
independent56 joined #minetest-dev |
21:20 |
|
behalebabo joined #minetest-dev |
21:23 |
|
independent56 joined #minetest-dev |
21:26 |
|
independent56 joined #minetest-dev |
21:27 |
Zughy[m] |
Friendly reminder that if anyone wants to help with confirming bugs, there are still 16 of them that need confirmation |
21:27 |
Zughy[m] |
https://github.com/minetest/minetest/issues?q=is%3Aissue+is%3Aopen+label%3A%22Unconfirmed+bug%22+-label%3A%22Action+%2F+change+needed%22+-label%3A%22Possible+close%22+-label%3AAndroid+-label%3AmacOS |
21:35 |
erle |
#11829 is very easy to confirm. i have put the repro instructions in the issue. |
21:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/11829 -- Client hangs on startup if too many texture modifiers are used in a game or mod |
21:37 |
erle |
#11532 is part of some parcour courses and player builds |
21:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/11532 -- Similar to sneak glitch, with different block configuration |
21:38 |
erle |
as is #11171 btw |
21:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/11171 -- New move sneak glitches through blocks despite sneak_glitch = false |
21:39 |
celeron55 |
it almost seems like we should add more glitches to the movement code, not remove them |
21:40 |
erle |
well, in both cases, i definitely don't think it's worth it to remove them – the way you have to set up the nodes is very specific and i have only ever seen it made deliberately as part of a parcour or hidden base |
21:41 |
erle |
i.e. “sneakjump in the corner in the basement to get to the secret room” |
21:41 |
erle |
walking on the side of walls is stupid though |
21:45 |
rubenwardy |
celeron55: that is what the code wants to do, after all |
21:55 |
|
olliy1or joined #minetest-dev |
22:05 |
MTDiscord |
<FatalError> Will we ever have SSCSM |
22:05 |
MTDiscord |
<FatalError> I know this topic has been discussed since well... forever |
22:09 |
|
independent56 joined #minetest-dev |
22:09 |
MTDiscord |
<FatalError> But will it even happen? |
22:10 |
MTDiscord |
<FatalError> We could just make it a completely benign system |
22:10 |
MTDiscord |
<FatalError> Hell, you could make your own custom language for it |
22:10 |
MTDiscord |
<FatalError> Lua imitation meat |
22:14 |
MTDiscord |
<GoodClover> Making a new programming is an entire seperate beast. Not exactly an option anyone's want to take. |
22:16 |
MTDiscord |
<FatalError> Well if we're concerned about security |
22:16 |
MTDiscord |
<FatalError> And apparently just neutering lua is somehow "just not secure enough" |
22:18 |
MTDiscord |
<FatalError> It really couldnt be that hard to gaurentee a secure enviorment |
22:18 |
MTDiscord |
<FatalError> We have 90% of the framework involved in this, we could even use open source libraries or hell, even reintegrate hacked clients into the API |
22:21 |
MTDiscord |
<FatalError> I mean its possible to clear the enviorment in lua, so why cant we just do that, and explicitly add safe functions |
22:21 |
|
independent56 joined #minetest-dev |
22:21 |
MTDiscord |
<FatalError> We can also do this within the client's API itself that way we can guarantee safety without risking hacks |
22:28 |
|
independent56 joined #minetest-dev |
22:34 |
|
panwolfram joined #minetest-dev |
22:34 |
erle |
FatalError what do you want to use CSM for that would not be solved by “make a better CSM interface in the main menu and host them on CDB” ? |
22:34 |
erle |
(i am collecting use cases) |
22:36 |
|
independent56 joined #minetest-dev |
22:36 |
Pexin |
< celeron55> it almost seems like we should add more glitches to the movement code, not remove them |
22:36 |
Pexin |
don't you worry, I have plans |
22:43 |
|
independent56 joined #minetest-dev |
22:46 |
|
independent56 joined #minetest-dev |
23:29 |
MTDiscord |
<paradust> this is one of the hardest problems. this is why it pretty much only happens in browsers, which are backed by big companies with deep pockets |
23:32 |
MTDiscord |
<paradust> the attack surface is huge: Miscompiles (if LuaJIT is used), buffer overruns (in the API), hardware-level attacks (row hammer, etc), side-channel attacks (e.g. spectre), etc |
23:33 |
MTDiscord |
<paradust> browsers have multiple levels of sand-boxing, and they are still regularly exploited |
23:49 |
erle |
paradust and yet, there are parts of browsers that are not exploited regularly, the ones that use tested and proven strategies. |
23:49 |
MTDiscord |
<FatalError> But you cant simply override the clientside environment, adding dangerous gunctions would quite literally be impossible with a clear environment, with only benine functions implemented |
23:50 |
erle |
(which broadly means following LANGSEC principles, and TBL's ”principle of least power”) |
23:51 |
erle |
FatalError i think it helps much more if you present a use-case. lukyx for example, wanted forms that react instantly, without lag. that is a very clear use case (and one where i would argue that browsers have shown you do not need a full-fledged scripting environment). |
23:52 |
MTDiscord |
<FatalError> Set velocity and position without delay |
23:53 |
MTDiscord |
<FatalError> Render objects only visible on clientside |
23:53 |
erle |
lag-free velocity and position seems like a movement prediction issue, i fail to see where you need scripting there. |
23:53 |
erle |
minetest already has predictive hints AFAIK |
23:53 |
MTDiscord |
<FatalError> Its absolutely nessecary |
23:53 |
erle |
elaborate please |
23:53 |
MTDiscord |
<FatalError> Set_pos is dirt useless 90% of the time |
23:54 |
MTDiscord |
<FatalError> Because lag will cause the player to snap back |
23:54 |
MTDiscord |
<FatalError> Get_pos doesnt give accurate results |
23:54 |
erle |
oh, i see. that seems like a different issue than what i thought. |
23:55 |
erle |
how exactly are you using set_pos that lag makes it weird? |
23:55 |
erle |
are you setting the position several times per second or so? |
23:55 |
MTDiscord |
<FatalError> Delay breaks shit, it always does. Same issue with hud, if I want to update a hud waypoint without delay, i fucking cant |
23:55 |
MTDiscord |
<FatalError> Itll look like shit |
23:55 |
MTDiscord |
<FatalError> The use cases are basically endless |
23:55 |
erle |
i have made the xmaps mod, so i am aware of the difficulties |
23:56 |
erle |
FatalError do you have a test case for the set pos thing? are you *sure* it is not anticheat related? |
23:57 |
MTDiscord |
<FatalError> Literally nothing to do with anticheat |
23:57 |
erle |
i have had snap-backs, but since the whole physics thing i assume it is a difference in server and client prediction |
23:57 |
MTDiscord |
<FatalError> Its not |
23:57 |
erle |
like, going in a minecart in a straight line, getting snapped |
23:57 |
MTDiscord |
<FatalError> Not what im talking about |
23:58 |
erle |
okay, so how do you use set_pos? |
23:58 |
MTDiscord |
<FatalError> I dont because itll break everything |
23:58 |
erle |
okay how do you *want* to use it? |
23:58 |
erle |
like what's the use case? |
23:58 |
MTDiscord |
<Jonathon> sscsm is useful for nice clientside prediction of things or making interactions less laggy, etc. at the end of the day you should always trust/verify things on the server side |
23:58 |
erle |
if you want to set the player position each frame, DO NOT DO THIS |
23:59 |
MTDiscord |
<FatalError> OH WOW REALLY? |
23:59 |
MTDiscord |
<FatalError> You mean I cant use setpos where I want to? |
23:59 |
MTDiscord |
<FatalError> Because itll break? |
23:59 |
MTDiscord |
<FatalError> Because of delay? |
23:59 |
MTDiscord |
<FatalError> CRAZY ALMOST LIKE I WAS SAYING THAT |
23:59 |
MTDiscord |
<FatalError> ANWAY |
23:59 |
erle |
i am saying a different thing |