Conquer Raids

[Super Aids]

Let me argue for why I am doing it and since I don't know of any other ways to be doing it better (Perhaps parallel-programming? Not familiar with it really, so I don't know.)

The BaseThread is a multithreading wrapper actually, however normal mobs does not have a thread for themself. Only the bosses, but there would only be a single boss in the map spawned at once. Normal mobs uses the thread the map has, since each map with mobs has a thread, rather than a global thread for the whole server.

The reason why the boss uses multiple threads is because each thread simply does different actions and if I was to use a single thread then one action may delay another action. It's not really a problem when it comes to deadlocks though, since there is not multiple threads accessing the same data they do. No locks is needed either since they just take care of the concurrent collections which already takes care of concurrency between threads.

If you know a better way to do it, I'd be more than interested in it, but as of now I do not know a better way.

Perhaps instead of giving each boss the threads then shared threads for the bosses, like with the mobs?

[pro4never]

The naming would heavily imply (to me anyways) that they are their own thread loops. I'd expect if they were something being called by a master thread it would be something like

Boss_Move_Tick
Boss_Attack_Tick

etc

Originally Posted by Super Aids

Let me argue for why I am doing it and since I don't know of any other ways to be doing it better (Perhaps parallel-programming? Not familiar with it really, so I don't know.)

The BaseThread is a multithreading wrapper actually, however normal mobs does not have a thread for themself. Only the bosses, but there would only be a single boss in the map spawned at once. Normal mobs uses the thread the map has, since each map with mobs has a thread, rather than a global thread for the whole server.

The reason why the boss uses multiple threads is because each thread simply does different actions and if I was to use a single thread then one action may delay another action. It's not really a problem when it comes to deadlocks though, since there is not multiple threads accessing the same data they do. No datalocks is needed either since they just take care of the concurrent collections which already takes care of concurrency between threads.

If you know a better way to do it, I'd be more than interested in it, but as of now I do not know a better way.

Perhaps instead of giving each boss the threads then shared threads for the bosses, like with the mobs?

... There's no reason (that I'm aware of anyways) to use more than a couple threads for your entire server. The amount of threads you are using creates more problems than it solves (what exactly do you need that many for to start with?)


I'd recommend a task system. The best way to explain it to those familiar with conquer online would be something like how TQ binaries handle NPCS.

Each task has parameters as well as an optional next task. This way your task collection only contains the currently relevant tasks. You can then process these tasks as they elapse and if there is a next task associated with them then you simply add that new task to the tasks collection.

This allows you to have a potentially unlimited chain of tasks being processed by the server. You can make the system as complicated as you would like.


Another possibility would be how TQ handles threading. There's a 'base thread' for the server which then triggers child threads, each of which have an interval which determines how often they are called. These child threads can then call any actions they need to (some of which may have their own internal tick intervals)

[_DreadNought_]

Originally Posted by pro4never

The naming would heavily imply (to me anyways) that they are their own thread loops. I'd expect if they were something being called by a master thread it would be something like

Boss_Move_Tick
Boss_Attack_Tick

etc






... There's no reason (that I'm aware of anyways) to use more than a couple threads for your entire server. The amount of threads you are using creates more problems than it solves (what exactly do you need that many for to start with?)


I'd recommend a task system. The best way to explain it to those familiar with conquer online would be something like how TQ binaries handle NPCS.

Each task has parameters as well as an optional next task. This way your task collection only contains the currently relevant tasks. You can then process these tasks as they elapse and if there is a next task associated with them then you simply add that new task to the tasks collection.

This allows you to have a potentially unlimited chain of tasks being processed by the server. You can make the system as complicated as you would like.


Another possibility would be how TQ handles threading. There's a 'base thread' for the server which then triggers child threads, each of which have an interval which determines how often they are called. These child threads can then call any actions they need to (some of which may have their own internal tick intervals)

AcidCOv3 had a similar system, where you could tell the GenericThread to execute a method and when, like a child - but not in its own loop.

(I'd have to look to remember exactly how it was done, but I remember it being pretty cool)

[Super Aids]

Well I have a sort of task thing, but I will figure something out. Thanks pro.

[diedwarrior]

Originally Posted by _DreadNought_

AcidCOv3 had a similar system, where you could tell the GenericThread to execute a method and when, like a child - but not in its own loop.

(I'd have to look to remember exactly how it was done, but I remember it being pretty cool)

You never taught me anything about threads you *****, now all of this seems like Chinese to me >.<

[Mi'kiro]

I personally think the idea is pretty neat. My favorite game at this time is Star Wars: The Old Republic where I play both DPS and Healer.

I very much look forward to carrying over the role to ProjectX.

[Super Aids]

Want to thank pro4never and Hybrid for the threading thing and I have narrowed it down now and the naming convention has been changed to be similar for it all, as well some other optimization, not sure why I did this stupid stuff in the start *****

[Korvacs]

Probably for the same reason you decided to call yourself 'Super Aids'....

[Super Aids]

Originally Posted by Korvacs

Probably for the same reason you decided to call yourself 'Super Aids'....

Only a few people would understand. It was a command in a previous server.