Here is my situation: The typical multi-tiled mob is 2x2, with the lower left-hand corner being the "lead" mob. So I set all the non-lead mobs to SYNC_STEPS. What is happening is that the SYNC_STEP mobs are moving in unison, but without sliding animation (they just pop from turf to turf), while the head mob uses sliding animation.

Hmm. That is messed up. Let me figure out what is going wrong here...

[Edit] Oh shoot. My test case for this was not general enough. There are some order-of-operations problems here. Will fix now. Sorry for the teaser!

--Dan

Dan wrote:

Here is a thought: Would the new pixel functionality let us do up to a 9x9 tile object with just one object?

Yes. Of course, this may or may not be convenient, depending on whether you want the extra space to be filled in the grid for the purpose of Bump() and what-not.

Well I'm thinking that for multi-tile mobs, we'd create a mechanism for bump and such...like might inform the turf that it has something dense on it using our own variable or list.

This is future thinking...but it might considerably simplify all the extra handling of directions for each sub-tile and such.

Does this mean I could do a "particule" system?

And have every pixel be treated like an object?

example:



Thats not perfect but, I think you get what i mean.

Spuzzum wrote:

However, before you get excited, remember that every particle is one more object that the game has to draw on the map, tell each client that it exists, and update on the client's screen. That means that if you're making 50 particles, you're better off without them, because each particle stream will cause almost unbearable lag as the server tells EVERY connected player about all 50 particles that are newly created, where they are in the coordinate system, etc.

Even high-end professional games lag out with lots of particles...for example, all the MMOGs like EverQuest and Dark Age have settings to turn off all effects and player names so that the game doesn't lag too much when lots of things are going on.

However, with creativity you can have things like particle effects without too much lag. Don't think in terms of individual particles...think in terms of "particle streams" -- animate a stream of particles that takes up a 32x32 icon and then you can just place one icon to represent a whole batch of them.

Even cooler if you base the animation on a 64 or 96 pixel high column, and then split it between three icons. That way you can have great animation and effects, yet only be placing three icons.

Spuzzum wrote:

Even cooler if you base the animation on a 64 or 96 pixel high column, and then split it between three icons. That way you can have great animation and effects, yet only be placing three icons.

Of course, then it's not particle streams, but rather just particle stream animations.

Well again, given that games written much closer to the hardware than BYOND have big problems with lots of particles, I think it's an unnecessary pipe dream to actually model each particle for a BYOND game. I mean, what's the point?

I wouldn't actually do that in *any* game unless there was a very special reason for it. It's just a waste of CPU that could go toward gameplay.

Dan wrote:

This feature went out to Shadowdarke, in sympathy for
having busted a lot of his code by changing sleep(). I
figured this would do wonders for his new project.

Way to go Shadowdarke! This will be helpful too for that StarTrek Universe game-thing I've been designing. I always had problems trying to get the ships to turn in a smooth arc with strictly tile-based movement. This sounds like it would eliminate that trouble!

Thanks guys!

Lummox, I knew it wasn't impossible and let me elaborate. All the cars would be AI controlled with option like
call_taxi for taxis.
Police cars automatically race speeders or maybe more importantly those who run stoplights/signs.
Personalities. Erratic behavior that does the things thst police try to stop.
If you go to ByondBwicki then StartingPoints then ExadvsChallenges will land you in my challenges.
Try the AI one. If you solve any make sure you post the source somewhere. They were specifically designed to help the BYOND community. I mean who would notwant the perfect AI or a car/ship/vehicle code. The fuse code is just for a good splash screen but with electrical impulses.

The AI challenge is well beyond my capabilities, and I suspect well beyond the capabilities of anyone here. What you suggested is a level of AI that, to my knowledge, no one in the entire human race has managed to do before. It would be a worthy experiment for a doctoral thesis, by someone who knew enough about the field to hit the ground running, but it's more of a pipe dream than a challenge at this point.

It's an experiment I was eventually hoping to perform on my own some day, but I wouldn't even touch it with a 10' pole until then. Hmm, well, I'd better make it 20' for good measure.

You guys must be doing some acrobatics in there to guess which is the "lead" object! Was that simpler/less processor-intensive than having us specify an "animation_leader" for an object?

Heh. I stayed up until 5 a.m. fixing SYNC_STEPS and then did a few more hours of work on it this morning. You are right about the acrobatics. It is possible for map updates to get broken into multiple lumps, which is what really caused trouble.

All along, I have been planning to add a var where you would specify the head object, but I have been reluctant to do that, because it seemed like it should provide more functionality than just animation. And it's also not yet clear to me how this whole "extended icon" business is going to turn out, so adding built-in support for multi-bodied objects still seems premature.

Anyway, when I was adding SLIDE_STEPS, I suddenly realized that this might be an appropriate place to slip in this other functionality without opening a can of worms. I was wrong about the worms, but I am fairly satisfied with the implementation now, so I think we'll do without explicit knowledge of the head.

--Dan

Dan wrote:

And it's also not yet clear to me how this whole "extended icon" business is going to turn out, so adding built-in support for multi-bodied objects still seems premature.

Yes, I suspect we'll figure out ways to torture the new icon functionality that you never would have imagined...it certainly opens up a lot of possibilities. In fact I'm just now realizing what was probably obvious: That this makes it easy to completely remove the appearance of a tile-based system, by having offset icons on turfs so there really is no visually apparent tile borders.

Anyway, when I was adding SLIDE_STEPS, I suddenly realized that this might be an appropriate place to slip in this other functionality without opening a can of worms. I was wrong about the worms

Well I'm glad you fooled yourself into it! This will be a very big improvement to games like L&D, and I'm hugely appreciative. As is the rest of the DDT I imagine! This will also help our Sneak plans.