mp_en_viaje: | diana_coman, yeah, taking out most of the race conditions in that pile will be a great improvement | [08:50] |
diana_coman: | mp_en_viaje: do you see any use for the "modes" shit? | [09:51] |
mp_en_viaje: | what is that again ? | [09:51] |
diana_coman: | mp_en_viaje: hm, there are 2 types even: 1. movement modes aka "run" "walk" 2. "server modes" e.g. "statue" "overweight" "peace" | [09:52] |
diana_coman: | the thing is that as "modes" they are nonsense really, a layer of shit that ps added to the pile it made confusing everything | [09:52] |
mp_en_viaje: | well, on one hand we kinda need a variant of walk/run for chars, and on the other, we need aggro/non aggro mobs | [09:53] |
diana_coman: | mp_en_viaje: heh, walk and run and even anything in between can be had sanely without "modes" wtf | [09:53] |
mp_en_viaje: | how do you make the server know the char can't move because ow ? | [09:53] |
diana_coman: | meanwhile I figured out the sane way the animations come in and I'm amazed even how reasonable it can be (once ps is out of the way ffs) | [09:54] |
mp_en_viaje: | ha! | [09:54] |
diana_coman: | poor cal3d and cs in fact do the reasonable thing and automatically select the bloody animation based on velocity of movement, which makes sense to me | [09:54] |
mp_en_viaje: | this is incidentally the funny story of a manalone production (cs) taken over by a "community effort" (ps). | [09:54] |
diana_coman: | ie when you load the animation you specify the type (eg travel) and the velocity interval in which it operates essentially | [09:54] |
diana_coman: | and then when you set the velocity, it will look and even blend (in principle, haven't yet seen it do it) those that apply | [09:55] |
diana_coman: | but then ps had to come and invent "modes" that are a sort of half-assed states for a nonexistent statemachine | [09:55] |
diana_coman: | re server knowing that it's overweight - if/when it's overwheight, it basically doesn't allow it to change position and that's that, I don't see what else is needed there | [09:56] |
mp_en_viaje: | i am not against taking it out, in the slightest. | [09:58] |
diana_coman: | mp_en_viaje: re movement modes btw currently I anyway "define" them on the client since they are entirely client concern - iirc we touched on this earlier but the way I see movement is that client may do locally whatever it wants but then it will have to sync with server (on whatever intervals it chooses) and the server will accept or reject the position that the client claims, basically. | [09:58] |
mp_en_viaje: | my only problems are you know, the specific items of interest. for instance, run also means stamina drain | [09:58] |
diana_coman: | mp_en_viaje: sure, but that's anyway based still on velocity, no>? | [09:59] |
mp_en_viaje: | well, moreso than walking anyway. yup it is. | [09:59] |
diana_coman: | so then why not just...use the velocity? | [09:59] |
mp_en_viaje: | what about the npcs, we'll have to distinguish aggro from peacible ? | [09:59] |
mp_en_viaje: | this sort of thing's my concern, i don't care about ps "modes" any. | [09:59] |
diana_coman: | (btw that's exactly how I ended up finding out that ...yes, can actually use it; because I was going nuts in between ps's pile of managers of everything and nothing until I had enough and went wtf, this is related to velocity so will plug it WHERE VELOCITY changes) | [10:00] |
diana_coman: | mp_en_viaje: in what way re distinguish? | [10:00] |
mp_en_viaje: | well, i dunno, one gets a red border ? | [10:00] |
diana_coman: | well, there can be some property and then client decides what/how it represents that, no? | [10:01] |
diana_coman: | with pink slippers for all I care | [10:01] |
mp_en_viaje: | yes, but there'll have to be a property is all i'm sayin'. | [10:01] |
mp_en_viaje: | kinda weird btw, have you noticed that the ONE response of the mediocre to ANY KIND of challenge is to build some manner of state machine ? it's so universal i'm about to start using it as diagnosis heuristic. "you made a state machine ? you're a retard aren't you." | [10:01] |
diana_coman: | sure; properties there can be as many as we want, why not. | [10:02] |
mp_en_viaje: | aite, then good riddance. | [10:02] |
diana_coman: | ahahah; dunno, the foxybot ended up with proper and strict state machine precisely to ride out all the unexpecteds and weirds due to unreliable connection & environment. | [10:02] |
mp_en_viaje: | that being the problem, they end up forcing normal people to make anti-moron state machines at the borders. | [10:03] |
diana_coman: | atm I basically circumvented a whole pile of client code aka it's in there but ...I don't use it; I am not very keen on trying specifically to cut it out esp right now since hell knows what other bits rely on it and so on but either it gradually comes loose until it falls off or whatevers, maybe at a later-stage cleanup or something. | [10:03] |
mp_en_viaje: | it's how the pros do it. | [10:04] |
diana_coman: | well, it's annoying like hell in that I keep carrying around all that shit on all sides but I don't see a more practical way currently. | [10:04] |
diana_coman: | mp_en_viaje: meant to ask 2 things: 1. given that the ids are uint32 in the protocol, is it fine for client to use 32 bits ? it makes a mess if it's always converting to 64 bits to then convert back (this is the messy part) when talking to server and so on | [10:05] |
diana_coman: | and 2. re characters - do we fix in any way the number of subparts (submeshes) and/or the equippable slots or how to call them | [10:06] |
diana_coman: | ? | [10:06] |
diana_coman: | (this 2 is something I still need to explore and it's potentially a big thing) | [10:06] |
mp_en_viaje: | should i make protocol ints 64 ? | [10:07] |
mp_en_viaje: | it's problematic because... well... they take so much space ;/ | [10:07] |
diana_coman: | mp_en_viaje: myeah, I know; otoh then it's really logical to have them as 32 bits on client too, what. | [10:08] |
mp_en_viaje: | imo no harm could come of it. | [10:08] |
mp_en_viaje: | i mean, the server needs its precision. but the client is wilfully kept in the dark re most things, it could practically work as 8bit too. | [10:08] |
diana_coman: | I'm not even sure I see exactly what's the problem with that as such; ie yes, strictly speaking it won't be "client is 64 bits everywhere & everything" but given that anyway CS is not 64 bits everywhere and everything, it's not a huge thing. | [10:09] |
mp_en_viaje: | imo that's tjhe right cut here, let client be 32 or w/e is convenient. | [10:09] |
diana_coman: | cool. | [10:09] |
mp_en_viaje: | re 2 : imo there should be only one. why would i have submeshes at all ? | [10:10] |
mp_en_viaje: | "oh mp, how do you attach scope to rifle ?" "simple, my dear fellow : first you read about disease of american capitalist ; THEN, and only then, and only if indeed still needed, you make two identical rifles, except one has also scope." | [10:10] |
diana_coman: | mp_en_viaje: ahahah | [10:10] |
diana_coman: | but no, there are 2 separate things that get mixed up in your example | [10:11] |
mp_en_viaje: | show | [10:11] |
diana_coman: | there is A. submeshes that means strictly making an animated sprite out of parts; the idea of use for this is if you want to have small variations e.g. Bob has long hair while Will has short hair | [10:12] |
diana_coman: | that part has nothing to do with equip at all | [10:12] |
mp_en_viaje: | oh | [10:12] |
diana_coman: | B. sockets are places where you can equip stuff | [10:12] |
mp_en_viaje: | well in that sense yeah, we do want pc variation | [10:12] |
diana_coman: | and sockets work in principle with any mesh | [10:12] |
diana_coman: | ie for any mesh, you can pick a triangle where you say "socket" and so you plug in there whatever other mesh you want | [10:12] |
mp_en_viaje: | right | [10:13] |
diana_coman: | that's (theoretically at least) the cal3d way to equip | [10:13] |
diana_coman: | I haven't yet got to actually test it so disclaimer here - the above is how the docs say it is MEANT to work! | [10:13] |
diana_coman: | I won't believe it until I see it working, lol. | [10:13] |
diana_coman: | so to my mind we actually want both really | [10:14] |
mp_en_viaje: | ok but then i don't understand either what you're asking or what part of what you were asking i equivocated | [10:14] |
mp_en_viaje: | what i mean is : i do not want anything more complicated than one mesh attaching to the character. | [10:14] |
diana_coman: | mp_en_viaje: it seemed to me you were talking of equip as submesh when it has nothing to do with it | [10:14] |
mp_en_viaje: | i don't want mesh chains, such that "on hand goes weapon and on weapon goes flag and on flag goes mom" | [10:14] |
diana_coman: | ah | [10:14] |
diana_coman: | hm, that is in principle even possible with the above ie there is no limit of levels | [10:15] |
mp_en_viaje: | make a weapon-flag-mom thing, and replace the weapon thing with it. | [10:15] |
mp_en_viaje: | that's what i thought you're asking, re limit of levels, and i said 1. | [10:15] |
diana_coman: | ah, that is good to know too! | [10:15] |
diana_coman: | but I wasn't even yet there, lol | [10:15] |
mp_en_viaje: | cool. now, what were you actually asking ? | [10:15] |
diana_coman: | take the characters: currently the ones in use are made out of torso and head iirc | [10:16] |
mp_en_viaje: | ok | [10:16] |
diana_coman: | the cally example char otoh is made out of feet, legs, pelvis, torso, arms, hands, head, hair | [10:16] |
diana_coman: | (or even more) | [10:16] |
mp_en_viaje: | k | [10:16] |
diana_coman: | so do we want something like cally or something like current char or how the fuck? | [10:17] |
mp_en_viaje: | rather like cally | [10:17] |
diana_coman: | because all those need to be loaded somehow and knowing *where* the bits go | [10:17] |
mp_en_viaje: | you can't make the players all look the same and live | [10:17] |
diana_coman: | yeah, I quite thought the same tbh. | [10:17] |
diana_coman: | I'll dig to see if there's a male equiv to cally too anyway | [10:18] |
mp_en_viaje: | now, those changes should ideally be procedurized, but this is kind of open q. | [10:18] |
diana_coman: | but at any rate, I'd rather fix the list of parts for player chars ie everyone has the same limbs, right? | [10:18] |
mp_en_viaje: | here's the only important question : | [10:18] |
mp_en_viaje: | allow me to quote, 1s. | [10:18] |
mp_en_viaje: | June Gearcull | [10:19] |
mp_en_viaje: | Millicent Shotsay | [10:19] |
mp_en_viaje: | Claribel Oceanmean | [10:19] |
mp_en_viaje: | Grace Workercrisp | [10:19] |
mp_en_viaje: | Adria Gradebraid | [10:20] |
mp_en_viaje: | ^ what's that ? | [10:20] |
diana_coman: | uhm? list of names/surnames? or what? | [10:20] |
mp_en_viaje: | right. it's the correct solution, also : on one hand they retain enough "human-nees" to be natively recognizable as "those are names" by the naive human mind, ie, they take that exam | [10:21] |
mp_en_viaje: | but they're actually on the other hand the result of a very simple procedural generator, which can take 1kb of data and prduce 1gb of quality output such that it passes the above test, in few steps and a line of code. | [10:21] |
mp_en_viaje: | THIS is what we want. can you find a way to do this for faces ? | [10:21] |
mp_en_viaje: | the criterion isn't even "this is human" ; the criterion is "this is a fun and acceptable face for a char in this game". | [10:22] |
diana_coman: | hm, no idea really; ie *something* can probably be done on the easy bits e.g. colour of hair (since it's anyway a material so possibly can set procedurally the colour easily anyway); otherwise it probably *can* be done but ... the building blocks are not made /in place currently aka not sure if it's the sort of thing to sink effort into right now. | [10:23] |
diana_coman: | note that even Cally does NOT go into the detail of the face | [10:23] |
mp_en_viaje: | well how about you think about it. | [10:23] |
diana_coman: | it's not about eye and nose and etc but "head" | [10:23] |
mp_en_viaje: | this'd be the fun of programming for a game, this sorta subquest | [10:23] |
mp_en_viaje: | diana_coman, the idea is to start with a base head and make 1trn heads | [10:24] |
diana_coman: | mp_en_viaje: I can gladly think of any part but you know, there's a ton of stuff competing for limited thinking places basically. | [10:24] |
mp_en_viaje: | head understands. | [10:24] |
diana_coman: | (not to mention that bloody first I still need to actually see the sockets and submeshes thing done and working) | [10:25] |
mp_en_viaje: | aite. | [10:25] |
diana_coman: | anyways, noted. | [10:25] |
mp_en_viaje: | is the q set answered or anything lingers ? | [10:26] |
diana_coman: | so far foxy is happily moving legs and arms and all that | [10:26] |
diana_coman: | mp_en_viaje: well, it's answered of sorts in that what is wanted is probably way more than what the structure as it is easily supports/provides but yeah, at least it's clear I'd say, thanks. | [10:26] |
mp_en_viaje: | it's quite the pleasure to read up on your progress you know. | [10:27] |
diana_coman: | come to think of it, I guess I'll have fun plugging weird stuff into "arm" and "leg" sockets to make some walking-shambles :)) | [10:27] |
mp_en_viaje: | aha! | [10:27] |
diana_coman: | mp_en_viaje: hey, glad to hear it! and thanks! | [10:27] |
mp_en_viaje: | yeah you gotta lotta work to do, you know ? but the ~purpose~ for why you got it is to have fun and make a mess of it | [10:28] |
diana_coman: | I don't know how the animation will handle that but I guess I'll find out. | [10:28] |
mp_en_viaje: | otherwise why are we even here | [10:28] |
diana_coman: | there's still so much *in the way* - that's the part that kills the joy at every corner | [10:28] |
mp_en_viaje: | just as long as the relationship is monotonically increasing the right way. | [10:29] |
mp_en_viaje: | ever less killjoys and ever grander messes each and every day. | [10:29] |
mp_en_viaje: | words to live by! | [10:29] |
diana_coman: | heh, will try to remember that at the right moments, lol | [10:29] |
mp_en_viaje: | :) | [10:30] |
Comments feed: RSS 2.0