jakj

Well, I did a bit more research today into VBOs, spurred on by the discovery that in GL 3.1+ every single thing is either deprecated or removed except VBOs, attributes, and shaders. So here's my new theory: Data per vertex: 3 floats for position, 3 floats for normal, 2 floats for texture coordinate, making 32 bytes (which ATI likes, being not as flexible as nVidia). Fast 16-bit indices, limit to 65536 vertices per model. That makes 2 MiB, which is right in the range of 1-4 MiB recommended for VBOs on most mid-range hardware. So, for a maximum of 8 MiB (and more likely 3-4 MiB) total, I get two VBOs I can keep bound for the duration of Minecraft's running, which should work even if some mod turns on Minecraft's shitty native VBO mechanism. Allocate both VBOs as static data. Whenever a model is instructed to be rendered, stick it in the VBO, and keep a stack pointer to the next free spot. If the VBO fills up, reallocate the buffer (using the quick method of binding a new buffer-body of null which is either a no-op (if no GL calls are pending) or quick-allocates a new buffer from a pool (since we choose a common size) and the GL calls can continue in the background). This also allows the disabling of synchronization on the buffer, because we're never writing to a byte more than once. As more and more models become rendered, the VBO gets purged, but overall, that should happen very infrequently, and most of the time the VBO will be sitting partially-full with the most-common models in it. Another possibility includes a slightly-larger VBO (probably 4 MiB) to make it less- likely that larger models will overflow the VBO. Alternately, models larger than X vertices could be placed into their own VBO, though by that point, performance would probably be degrading to the point that the extra rebinding costs would collapse the framerate. It depends on whether it would be more costly to keep rewriting the VBO (allocated with static hint, remember) or to do several rebinds every frame.

Immediate (glBegin/glEnd): - Most flexible in ordering, data specification, and memory usage - Slow as fuck Vertex Arrays: - Fewer function calls, leading to greater efficiency - Greater memory usage Vertex Buffer Objects: - Fastest possible, storing data directly on the card - Can blow apart a card's memory very quickly, dragging down the entire program The dilemma: Minecraft is already a hog, and the situation where VBOs would truly be valuable (as in, where performance actually degrades: large complex models) are also where they would be least successful (few people are likely to use giant models, and video-card memory is precious). For lots of little models, in theory VBOs could help, but considering the fragmented nature of a mod, near-impossible to truly optimize and utilize. Most of the techniques that can be used when making a whole program, break down when having to inject code into an existing program that doesn't even use the same methods. My thought so far: I think vertex arrays are probably the best way to go. It's more memory, but it's all system memory, which is slower but more plentiful. Some of my transformations have to be cached anyway, instead of just using render-time matrices, so it may as well be cached in vertex arrays, which (as far as I can tell) can be used like any other array in the mean time. This mod already requires a video card with shader support, so, at a rough guess...six-ish year old cards? Something like that. And really, people aren't going to be running out of system memory on computers that modern. Thoughts?

I have implemented pixel-perfect hit-detection in Minecraft. Because, why not?

Technically, it would be possible, but you would be immediately laughed off the Internet for even trying. No, really: The vibrations from the explosion of laughter would open a localized chasm between your computer and the wall, effectively cutting off your connection. Take pictures.

Do you really need to get your panties in a bunch over how someone you don't even know wants to play their video game?

There are only four bits of metadata (16 values), so no, she stores it in the tile entity most likely. Tile entities and item stacks both use NBT to store effectively-infinite data, but it's a lot cheaper to do so in the tile entity since it's automatically cached in memory when the TE is instantiated, whereas the itemstack's NBT has to be read every single time (for example, every render frame). That's why microblocks don't work with non-RedPower blocks: They are not actually blocks (because in Minecraft, no matter what, only one block at a time can be in a spot) but rather are just custom rendering, and the only way to get custom rendering on another mod's blocks is to reimplement and replace that mod's blocks (which for multiple reasons is not practical at all).

Yes, if they all are the same material, hardness, and blast resistance, and all have the same behavior (in this case, simple block), you would add one block and use metadata to specify the colour. (You could even do it as a re-implementation of the existing brick block by saying "Block . blocksList [ Block . brick . blockID ] = null ;" and then instantiating your block at the same ID, but I don't recommend that, because most existing recipes requiring bricks would not automatically use your type of brick, and another mod might already have replaced that block and your mod would obliterate that.) But if, for example, you wanted some of your bricks to be brick slabs instead of bricks, or stairs instead of bricks, or whatever, you'd have to use a different block ID. If you want to see metadata in action, go look at gotyaoi's stained-glass mod.

No, that's because he copied/pasted the slab code and was too lazy/terrible/stupid to check his work. But you're thinking in the right terms, yes: Material is a member variable of the block class, so it can change at any time but can't vary intelligently based on metadata.

Unfortunately, some things to do with blocks are tied to the block type itself, not the individual block (meaning it can't be set differently for different block instances). Collision boxes I should be able to do, because the function takes the X/Y/Z of the block as a parameter, but I'm not sure yet about other things.

Depends on how EE stores it. If in the tile entity, this would be easy. If also in is main code, would require a good bit of fiddling. My bet is on the former, though. If someone else wants to write the code for the pipes themselves (probably based on bc or thaum for visuals) I'll write the code to interface with ee and perform the actual transfer.

New video is up on how to manipulate 3D models within Minecraft without a GUI.

But that would be actually incorrect, instead of correct but infuriating. Something that's just flat-out wrong can be comfortably lumped into a whole and discarded by the mind, whereas something that makes perfect sense and yet just isn't how it should be, that will eat at a body.

1 B III has its own sort of symmetry, actually, a constant shift. Being an anal-retentive myself, you can trust that 1 2 C is far worse.

I try to help anal-retentives to desensitize themselves to disorder and asymmetry. Seems to help, now and then.

There is no direct rule against "necro'ing" a thread. Basically, you ask yourself two questions: 1) Is the thread itself still relevant (as in, if it were to have been posted in its entirety yesterday instead of whenever, would it still be interesting)? 2) Does the thread lend weight to whatever you want to post, aiding the discussion, making it more useful to post in the thread instead of making a new thread? "Necro'ing" a thread is bringing up an old topic for no damned reason. In this case, I would personally say that the topic is still valid in general (though maybe not to the original poster), for anyone curious about getting into modding, though what you did was not actually modding, but just editing a config file, so I wouldn't say you added anything to the discussion.

If you don't have any luck trying to find an existing converter, see if you can find some way within LIghtwave to export to a plain-text file.

1) Placeholder, not placebo. Good lord. 2) Any artistic design is copyrighted. For example, typefaces (fonts) are protected by copyright, even though they're just the letters/symbols of the language. C) Most reasonable people don't really care about small-scale ripoffs as long as there isn't money being made and it's not causing harm or misrepresentation of the original.

For the love of Pete, please do not bring SMP into this. It'll be today's shitstorm (again).

I maintain a more practical stance, that 100% of my opinions will never precisely line up with 100% of everyone else's opinions, so if I hold out for that to happen, it'll never happen. If I find a mod that is 90% what I want, I simply alter that remaining 10% instead of throwing away the 90%. It's no different than getting a slice of cake with too much icing on it: I just take off some of the icing and still eat the cake.

That's always been a fair point, but there are plenty of us who don't like the equivalent part of equivalent exchange in the first place. I personally avoid the transmutation table and condenser entirely with the exception of creating EE items (so I'll transmute diamonds only to make diamond blocks for dark matter, for example), just like I avoid the solar panels from IC and RP. (That other guy's idea of burning nikolite for blutricity is good, or alternately burning items for thaum to produce blutricity.) It's just a matter of taste: For my playstyle, I like everything to be finite, and if I need more stuff, I can make a new age to dig into.

It would be a better idea to wait to see how the new guy does EE3 (because he's announced a total revamp) before messing with tweaks.

This sounds like a hodgepodge of parts from existing mods. Try looking around more, first: All of this is probably already done (though not necessarily every specific gun you mention.)

If you can't even tell whether or not mod supports SMP in the first place, how in the fuck do you expect to install and configure it correctly? Go take it to a forum that cares. This one is for making mods, not handholding people through their installation.

People as a whole do not understand the important difference between plagiarism, iteration, and coincidence, unfortunately. There is a plentitude of all three on YouTube, and only one of the three is detrimental to the quality of work.

I'm not going to do frame-by-frame animation, nor physics-based animation. The animation I'll be including is just a modifier on the transformation. (For example, you can already say "rotate around the Y axis by 10 degrees", and you can simply animate that by saying "rotate around the Y axis 10 degrees every 250 milliseconds".) I'm also not going to implement advanced 3D features like materials and bump mapping: The only parameters accepted are model vertices of three coordinates and (optionally) texture vertices of two. Normals will be recalculated when loading the file and user-supplied normals will be ignored.