With a bit more time on my hands lately, I've got this stream updated to the current trunk. Anyway, I think it would be ideal if the changes from this stream are merged to the trunk before I begin to work on the bigger changes. There aren't many changes in here yet, only two main ones.
1. Weapon speed and skill delay timers have been merged together. This prevents players from shooting mobs with a bow or casting spells while swinging their weapon at the same time for example. You have to wait until the cooldown timer runs out before you can do one or the other. Of course, there is a possibility that in future we have dual-wield, which would probably require adding a second cooldown timer, but that should be fairly simple.
2. The 'You can shoot again' spam has been removed. Instead, I've added a new action timer variable to the protocol. Ideally, the server would only need to update the client twice whenever a skill is used. Right now, the server will still handle skill requests and update the cooldown timer if the cooldown timer > 0. It is possible to block the client from sending skill requests to the server during that time though, which should greatly reduce the amount of bandwidth used, and lower the CPU time for the server too. The client currently has a new cooldown timer in the interface that ticks down pre-emptively. I'm not so sure about this new timer in the interface though, since there will always be some difference between the client and the server in ticking it down. Perhaps a player will know why they can't use a skill yet because of cooldown time. Or maybe there could be another way of doing this. Though, pretty much anything is better than being bogged down with 'You can shoot again' messages imo. There probably should be some kind of discussion on this change. Also a side-effect of this of course will mean that the cs version must be changed as the trunk client is incompatible with the server from this stream.
The bigger changes I've got down the line for this stream are rebalancing the items in the game, and solving the issue of having modified attributes hard-written to base items. The former issue is rather self-explanatory.
The latter issue prevents existing items in the game from being changed in case a rebalance is needed later on. What I have in mind here are new index attributes that go along with the regular attributes such as str, dam, ac, etc. The index attributes would be there for those items such as regular rings that get generated, and artifacts such as items 'of lesser element'. What happens here is that the index value is translated into the real attribute when the object is loaded. These index attributes would probably scale from 0-1000, a little arbitrary but it should be enough to prevent inaccuracies from happening when they are translated. We would also have the maximum possible bonus of each stat stored in a file somewhere. An index value of 1000 would mean that attribute attains the highest possible bonus. So let's say we have a dex+ ring and we don't want the bonus to be higher than 5. We set the max value of dex to 5 in the file, and the index value is a random number from 0-1000 when the ring is generated. If the index is 1000, the ring is dex+5. If the index is 500, the ring would be dex+2.5, and then rounded. What this means is if we think dex+ rings are a little underpowered, we can then increase the max bonus, and all existing dex+ rings in the game will go up with it. It would mean we could make the artifacts file significantly smaller than it is now, with all the items such as 'of lesser element' removed as they can be generated with the index system instead.
Or we could go the other route and remove regular rings and amulets and possibly 'of element' and 'of stat' items completely and just have artifacts generated instead. This would probably be a little more boring on gameplay though, but it would mean the index system wouldn't need to be implemented. Also, the other obvious thing would be to make it so artifacts generated from treasurelists don't hard-write the artifact attributes to the base items either. But yeah, that's probably another subject for discussion I think.
I should have time now, I'm basically free until September, and even then I should have much more time free than I have had in the last several years, which was virtually nothing.
The stream contains changes to the client as well as the server because of the new action timer variable added to the protocol, so if the server is restarted with this stream, the trunk client becomes incompatible with it. So once the changes are merged in, we would need to create a new beta 5 client installer to distribute.
The index suggestion or the alternative suggestion is to eliminate the current problem we have now, where once a special item drops, it becomes impossible to change it. Let's say the server generates dam+10 rings and the ring is way too powerful. There is no way to nerf it without finding every single one of those rings that have dropped, which is almost impossible. If it was possible to update the stats of this ring dynamically, this wouldn't be a problem. We already have a way of doing this, which is to use artifacts, but regular rings and amulets that drop do not use this.
I vote yes to merging the current stream to trunk, as long as you are sure you now have time to address resulting bugs as they are reported on the dev server.
When we finally dump B4 and rearrange SVN properly, running a modified server should be even easier.
For now, if it's server-only changes, you might try '/restart gameBalancing' on dev, which will export trunk, then streams/gameBalancing over the top, and recompile the server.
The index thing sounds unnecessarily complicated and I don't really understand the point you're getting at with the alternative suggestion.
But yes, the artifacts file (and ie, demon_plane.art) needs a total rewrite (for example, the actual of lesser, etc artifacts currently do not match up with the suggested format, and many 'generic' artifacts which should be in the public file are squirreled away in the private demon_plane.art for some reason). But I think this can all be achieved through proper use of the current artifacts system.