FavoritoHJS

i was thinking of it being used for full-blown cuboid fills, but i don't think those will be helpful enough to matter...

Overrideable Blocks: basically a normal, renderable block that can also be placed over, like tall grass or snow in MC DEPRECATED: not useful unless you HAVE to input an id for each possible block position, which no packet does atm. Noop ID: Reserve the highest id representable (currently 0x3FF, 1023) as a "noop" - this means that trying to place this block in any way results in nothing happening, leaving the current block in its place Extended Extended IDs: Increase the highest valid block to 1023. Will need to find a way to fit the extra 256 ids into the system MCGalaxy uses, which should be possible if so much as a single free bit is found in all size-constrained structures. Advanced Filling: Adds the following: A slight modification on how block indices are used: Indexes -1 to -256 mean "skip forward this many indices". This means, for the most common operations (large fills or copies, for example), poorly-compressing number changes are replaced with long runs of a few numbers (with the most common case of -1 being 4 FF bytes), all at the low cost of shrinking the maximum world area size by 256 - assuming unsigned ints for the index are even enforced, otherwise there's no change! Paletted Bulk Update: Many operations tend to modify a large amount of blocks, but only do so with a few block types. This packet takes advantage of this redundancy to decrease size of payload data. TODO: Check if this is worthwhile in bandwidth. Count is an unsigned integer, just like in BulkBlockUpdate 16 block definitions (totaling 16 bytes for non-extid or 20 bytes for extid) 256 ints for block indices, same as BulkBlockUpdate 128 bytes for what block id is used for this position. Bulker Block Update: Same as BulkBlockUpdate and its paletted counterpart, just with all fields increased in size by around 16x, creating a larger packet that should be able to compress better over the network. (if you aren't transparently compressing packets, it might be worthwhile to make these a variable-length packet for a compressed version of this) Count can become a short or remain as a single byte, whose value is multiplied by 16 to get the used count. Up to 15 extra SetBlock packets after this should be small enough to not really matter. NEW! 01-12-23 Model part properties: 2 new property type values, each one being a bitmask, with each bit enabling or disabling one of the 64 parts of a model. Useful for making multiple small variations of a single model without relying on transparent textures. Alternatively, more properties can be used, and a way to turn such info into an animdata field added to allow for further per-model customization. Sounds: Already explained here:

fair enough, though the option of a dmca takedown seems a bit too nuclear imho. ...wait a minute we're verging right off topic aren't we? answering the op's question, i fear the mere fact of asking said question has locked you out of the sigma chromie rank. have fun!

(laughs like that guy who cross-compiled 1.5.2 into javascript, see eaglercraft) (cries in surprise takedown) (realizes they probably copied his homework as well) yet another reason why microjang is dead to me

or: an answer to why do we need CEF for any custom sounds Something I noticed while binging adventure maps in NA2 is that almost every single map recommends CEF for music...and just music. I wonder whether this can be better served with a protocol extension... I'm sure someone else suggested a similar idea before (probably multiple times, even!), but assuming that this whole idea isn't impossible to begin with, here's my idea. also sorry if this is in the wrong topic and should have been in Techno Babble instead... Suggestion guideline: Register a Sound. Inputs: short identifier identifying this sound. string containing the URL to a sound effect. Generic metadata relating to the sound, potentially including: int containing size of compressed audio in bytes short indicating codec type float containing the length of audio in seconds whatever other info might be useful for the receiver. Client then uses the identifier to register the sound, such that future packets using said identifier will use the sound. If a sound is already registered to said identifier, the newly-registered sound takes priority, implicitly unregistering the existing sound. Cases of invalid URLs, failure to find/download a sound, and such errors should be printed in chat. Any identifier less than 256 is reserved by ClassiCube, and should not be used for any reason except overriding existing sounds. Additionally, the identifier 0 is special and must not be assigned to. Note: Due to limitations of the string type this can only support URLs up to 64 characters long. This could be a problem with deep path hierarchies, especially with a long domain name. This is a problem common to all packets that use URLs, but is probably worse here as you usually want to store the sounds with a descriptive name in a descriptive path. Unregister a sound Inputs: short identifier for the sound to be unregistered. Unregisters the sound. Might be unneeded if a blank URL does this as well, but I would prefer a cleaner solution. Link a sound Inputs: short containing the sound identifier to be linked. byte containing the "type" of sound to be linked. Think of this as if the sound is registered as music, footsteps, breaking... byte containing the "subtype" to be linked to. Think of this as in a specific category of blocks to have this sound. Some types might not have a meaningful "subtype" assignment. These should have this value set to 0 by the server, and have the client ignore this value. 2 byte containing minimum and maximum sound intensity 2 byte containing minimum and maximum random pitch, in units of 1/128 speed from 0,5 to 2,5. A server must ensure a maximum random value is equal or greater to the corresponding minimum random value. Mostly present to give the server a way to add sounds without manually sending every single sound that would be played, so even with occasional network lag spikes footstep many normal kinds of sounds are played as normal. Unlink a Sound. Inputs: short containing the sound identifier to be unlinked. Set to 0 to indicate all links in the type. byte containing the "type" that this identifier will lose its link to. byte containing the "subtype" to be unlinked. Some types might not have a meaningful "subtype" assignment. These should have this value set to 0 by the server, and have the client ignore this value: this means all sounds from this type are removed. This allows for whole types of sounds to lose their links to existing identifiers, to then have custom sound identifiers linked. Ever wanted your metallic blocks to sound extra metallic? Play a sound Inputs: short containing the sound identifier to be played. byte containing whether this sound is to be considered special -- Play from Everywhere, Count as Music, the like. byte containing sound intensity, or 0 if it is to be random. byte containing sound pitch, or 0 if it to be random. This does mean a speed of exactly 0,5x is unreachable without having the link specify that as the only valid random value. 3 int (or short if ExtEntityPositions is unset) containing the position of where the sound is played from. Ignored by clients if Play from Everywhere is set. If Count as Music is set, the currently playing music is stopped as soon as another sound with that flag is set, and no music will be played until this sound ends. This includes identifier 0, allowing for early stopping of a very long track. Reset Identifiers Resets the identifier table to the initial state at startup (identifiers <256 back to initial values, everything else unregistered), as well as the assigned sounds. Open questions: What to do if a malicious server sends a large amount of huge sound files? What to do if a sound can't be played by the client due to codec concerns? Ideally should allow for a fallback sound to be sent. Might be ignored if only some codecs are allowed by protocol. WAV and Opus ought to be enough for everyone, right? How to handle implementations that might not support assigning up to 64k sounds? Or those with limits to simultaneous playback? How to handle edge cases, such as linking or playing an unassigned identifier PS: anyone know how to make an inline code block?

hmm, i wonder how acceptable a 16-color pack would be if manually pixeled... something somewhat important is what shade of brown is to be used? iirc windows used dark yellow which could make creating a good dirt kinda difficult...

well, from what i recall 3dfx glide does have a dos api, and i'm sure a voodoo 2 should be able to render enough polys at a playable framerate to match a tiny render distance. EDIT: Here's a rough performance estimate, based on the 3dfx Voodoo Banshee technical reference at https://3dfxarchive.com/reference.htm. Wanted to use the Voodoo 2 reference, but the performance numbers there were illegible... The card should be appears mostly fill-rate limited, with a maximum fill rate of around 50Megapixels per second rendering trilinear texture-mapped polygons. Assuming a 20fps framerate, this equates to 2,5Megapixels per frame, or 5 full 800x600 repaints. Of course you'll probably want a higher framerate. If purely fill-rate limited, you could achieve 100fps, but that would require having no overdraw whatsoever, something that sounds tricky. With sufficient optimizations, I'm sure 45fps is possible, and maybe even 60 if you have low enough overdraw.