Proof of Concept - A player treated as a NPC (thought to be "impossible")

This is quite exciting,finally someone who's on last patch aside Hybrid/Impulse,who's not using impulse's base, glad to see that you're working on a from scratch source,not only that but also with great ideas/knowledge.

We just managed to take control over max HP of a monster server-side (client is no longer dependent on monster.dat for the SizeAdd, ZoomPercent, or MaxLife) since the server can send these as we extended the spawn packet.

We also managed being able to dynamically turn a monster into a boss (showing the boss HP bar, and choosing the max life of the HP bar without using the Synchronize MaxLife type).

Everything we've been showing so far requires no client file modifications, so our project is 100% legal in comparison to other servers...


Read the comments, it'll answer most questions.

this is how the client should be, monster.dat is so useless lol

Just like tq.

its just asm modifications, nice system, but its nothing new, not to me anyway

Quote:

Originally Posted by Ultimation its just asm modifications, nice system, but its nothing new, not to me anyway

I've seen your work, and believe me I am impressed but I feel that a lot of the people in this community who've done some significant work don't feel the slightest bit impressed with ours, but if any of you attempted this, you'll see it's not as easy as some of you may think it is.

Yes, it's assembly modifications, but finding what, where, and how to modify the client for things like this can get quite tricky and time consuming, especially for the majority of people.

Quote:

Originally Posted by pcs_ffchen I've seen your work, and believe me I am impressed but I feel that a lot of the people in this community who've done some significant work don't feel the slightest bit impressed with ours, but if any of you attempted this, you'll see it's not as easy as some of you may think it is. Yes, it's assembly modifications, but finding what, where, and how to modify the client for things like this can get quite tricky and time consuming, especially for the majority of people.

Totally Agree with you, i read back on the post it did sound abit harsh so i appologise for how it sounded.

I do have a System that you guys may be interested in to add to your extensions. Team Yakuza has a working Map streaming system. (We can send not only dmaps generated by the server to the client, But continuous worlds too)

Regards

Quote:

Originally Posted by Ultimation Totally Agree with you, i read back on the post it did sound abit harsh so i appologise for how it sounded. I do have a System that you guys may be interested in to add to your extensions. Team Yakuza has a working Map streaming system. (We can send not only dmaps generated by the server to the client, But continuous worlds too) Regards

When you say "continuous worlds", do you mean sort of like using a single map the size of say maybe 100 Twin Cities or more? o_O

Quote:

Originally Posted by Eteru When you say "continuous worlds", do you mean sort of like using a single map the size of say maybe 100 Twin Cities or more? o_O

More like the idea of continually expanding a map as the client moves, I suspect.

Quote:

Originally Posted by Korvacs More like the idea of continually expanding a map as the client moves, I suspect.

I don't feel like that would be possible...? If the map was ever-expanding, would it not take up an infinite amount of physical space to save the data as it expanded as a character traveled across it? And unless there is a way to teleport back to a certain location, I feel like the player would get lost. And what about the coordinates...? *imagines coordinates: (10387612304876, 85613587618796)* or some shit. Lol Sounds a bit far-fetched, maybe?

Depends how you use it, none of those issues are actually issues unless you allow them to be.

Provided that you dont go beyond the 4 digit 'limit' (not actually a limit, just beyond that looks messy on the client) on the coordinates then you can create a map thats 10x the size of the Twin City Plains map, that and clever use of portals or map design means you could randomly generate within that space infinitely.

Also an ever-expanding map does not use an infinite amount of physical space at all, for one thing you would probably never store the map on the disc, and secondly in terms of memory you would just unload the previous areas that are no longer used.

Sounds far-fetched perhaps to yourself, but plenty of other games stream content on the fly which require far more demanding requirements than Conquer's dmaps do.

Another useful thing that it could be used would be dynamically changing maps, you could have a boss wreck the landscape as part of a quest and then dynamically alter that part of the map on the client side.

Quote:

Originally Posted by Korvacs Depends how you use it, none of those issues are actually issues unless you allow them to be. Provided that you dont go beyond the 4 digit 'limit' (not actually a limit, just beyond that looks messy on the client) on the coordinates then you can create a map thats 10x the size of the Twin City Plains map, that and clever use of portals or map design means you could randomly generate within that space infinitely. Also an ever-expanding map does not use an infinite amount of physical space at all, for one thing you would probably never store the map on the disc, and secondly in terms of memory you would just unload the previous areas that are no longer used. Sounds far-fetched perhaps to yourself, but plenty of other games stream content on the fly which require far more demanding requirements than Conquer's dmaps do. Another useful thing that it could be used would be dynamically changing maps, you could have a boss wreck the landscape as part of a quest and then dynamically alter that part of the map on the client side.

If the map is handled by either the client or the server, wouldn't it require more RAM to be constantly loading and "unloading" map data? And that makes me think... What determines when and what part of the map should be "unloaded?" And if it's "unloaded" every time, does that mean, I could go off screen, come back, and it be totally different? If mobs are killed in an area, items may drop, if the character strays from the area, and comes back, will the map be "reloaded" and the items be gone?

What other games do you know of that use a map system like that? I can't think of any...

If you mean dynamically changing maps with landscape, do you mean instance maps? This makes me think of Guild Wars 2, where the map changes the objects in the map when a dynamic event happens. But this isn't changed client-side-- It's changed server-side, because all of the players see the change, and can interact accordingly. For example, when centaurs destroy a bridge, the bridge falls apart, and players cannot cross it.

So I'm still a bit confused as to how you can have dynamic "ever-expanding" maps if no information is saved... If the map changes because it's dynamic and ever-expanding, how can you place content there without it being different every time because the map is never the same..? >_< :confused:

I think your over thinking this. I'm just giving examples, I have no idea what Ulti's system would do, the randomly generated map was an example of how the technology could be used, how random such a map could be would be a judgement made at design time. But none of your points are issues.

Generating the map from a seed, therefore making the server able to remake it solves most of them. Then an items are stored in that map with that seed with relative coordinates, and previous areas of the map can just be resent.

As for examples, I stated that other games stream content, not specifically maps. The point being that the dmap format for conquer is relatively small compared to some of the content sent by other games.

The guild wars 2 comparison is interesting, what gw2 tells the clients is to remove certain parts of the map, the map data is still the same however so that system would be the same as this one, only the client is being told to physically overwrite the client side data with incoming data. This system would allow for client specific instancing within maps, so to speak.

But yeah your over thinking it.

think of it like this.. Conquer sees the dmap as 1000 x 1000 coordinates (example).

But your own buffer is updating the grid with a "virtual" bigger map, along with the puzzle references. as the player moves. thus your not using anymore memory your just overwriting the existing memory :)

Exactly, its no more an issue than using the regular maps in the normal fashion.