Server Help

Trash Talk - OCX bot core

xor eax - Sun Aug 14, 2005 10:44 am
Post subject: OCX bot core

I'm thinking about writing an "OCX bot core" for VB/Delphi, etc. I'm adding bot capabilities to my setting editor (to allow online edition of zones). So I'm considering encapsulating the bot stuff into a control.

These would be the goals:

-Hide both core and protocol into the OCX. So people can write bots knowing shit about the undies of the game.

-Open the door to other programmers (a lot of people who want to write bots but don't want to learn C or Java).

What do you guys think?

Cyan~Fire - Sun Aug 14, 2005 11:21 am
Post subject:

No. Please don't make an even more platform-specific bot. It will get less and less useful as people switch to ASSS anyway.

xor eax - Sun Aug 14, 2005 12:39 pm
Post subject:

I understand that you don’t want to hear about *another* bot core now that you’ve been through C++, MERV, etc. I’m thinking on people who don’t want to learn C. I also understand that you don’t want to hear about that people at all but they are there, and they are a whole lot I think.

My bots connects to asss so I don’t see why they will be less useful than any other SS bot system.

Also, I still think it’s not good to expose all SS knowledge in sources as MERV is doing.

Anyway, the OCX is done. It is just handling the chat and a few commands (*getfile/*putfile) because that’s all I need for online CFG edition. The idea is adding full packet handling to the work that I’ve done already.

Now talking about asss... I think “somebody” should write the needed modules to emulate subgame, I mean 100%. I think people is not moving to asss as fast as we expected because asss “won’t behave exactly as subgame does”. Continuum offered 100% compatibility (except for a few issues that can be easily solved) with SS. I my humble opinion, that’s why people moved so easily from SS to Continuum without noticing any difference. And that’s why zone owners are moving slowly to asss, because it is not offering same compatibility. I think asss is a pretty good idea and a pretty good job that it’s already done, but it needs a few more development to replace subgame.

Cyan~Fire - Sun Aug 14, 2005 3:05 pm
Post subject:

xor wrote:

My bots connects to asss so I don’t see why they will be less useful than any other SS bot system.

Because people will want to host both the server and the bots on the same box.

xor wrote:

Also, I still think it’s not good to expose all SS knowledge in sources as MERV is doing.

It's only exposing it for people who are inteligent enough to understand it, and I feel comfortable with letting them know. Anyway, there's nothing too important about SS encryption, etc., anymore because of Continuum.

xor wrote:

Now talking about asss... [snip] I think asss is a pretty good idea and a pretty good job that it’s already done, but it needs a few more development to replace subgame.

The problem with making an asss that works just like subgame is that that defeats the purpose of asss, to make a more extensible (and sensible) server. I can understand the need for players to use something similar to what they're used to, but zone owners themselves have a responsibility to learn to use new technology. They're taking it upon themselves.

Gravitron - Sun Aug 14, 2005 4:34 pm
Post subject:

continuum working same as SS? not noticing difference?

The resolution is smaller, the prox is off the whack, the network handling can barely handle 300ms latency not to mention people with only 100ms but 30ms spikes and the list doesn't end.

Mine GO BOOM - Sun Aug 14, 2005 4:51 pm
Post subject:

xor eax wrote:

Also, I still think it’s not good to expose all SS knowledge in sources as MERV is doing.

If you are really making it independent of the protocol, you could easily add an inferface to ASSS itself so bots will run either on your core, or via module directly on ASSS.

Gravitron - Sun Aug 14, 2005 7:03 pm
Post subject:

My post is of no relevance to the bot core and should not be present here.
Nor is the thread belonging to trash talk.
This should be in the bot development forum, numbbutt (mine go boom).

...Sigh, newbie admins.

Cerium - Sun Aug 14, 2005 7:31 pm
Post subject:

Hed basicly be writing an ASSS emulator in that case... and if he did it well, not only would his bots run on ASSS, but existing ASSS modules would run on his core.

Thatd be cool to see, assuming he didnt write it for OSX only =(

Solo Ace - Sun Aug 14, 2005 7:47 pm
Post subject:

OSX? Where did that come from?

xor eax - Sun Aug 14, 2005 8:36 pm
Post subject:

Gravitron wrote:

I know they forced people to a new client, so all players HAD to move to it or forget the game. But it had less impact on zones than moving to asss is having now.

I disagree about resolution. It is in settings, you can run a zone without res limitation. As far as I know resolution was limited to decrease position and weapon traffic and also to make the game more fair because people with good huge monitors and resolutions was having an unfair advantage over the rest of players.

Cyan~Fire wrote:

I agree. I’m just talking about modules. I’m not talking about putting limits to asss, it is about building the required modules to emulate subgame more accurately. So people can leave one day his favourite subgame zone and the next day enter the same asss zone without noticing any big difference. To migrate to asss, I think zone owners need a collection of asss modules that offer backward compatibility with subgame. But I agree with you, it is their responsability. And I think they will turn to asss, slowly or not.

Mine GO BOOM wrote:

If you are really making it independent of the protocol, you could easily add an inferface to ASSS itself so bots will run either on your core, or via module directly on ASSS.

Wow.. that's a great idea. I have to learn more about asss, write my own modules, etc. But I agree with you, it is the way to go with bots and asss. Obviously, it requires writing a module that load the same plugins as the bot core does. I will think of it all.

xor eax - Sun Aug 14, 2005 8:43 pm
Post subject:

Gravitron wrote:

This should be in the bot development forum

Hey! give MGB a break :p

There is a few you can see at the moment, I will upload some very basic sample soon, then we can start talking in bots section...

Bak - Sun Aug 14, 2005 9:57 pm
Post subject:

there is a module to capture subgame compatability called sgcompat. for anything else (like *spec) you can use my commandalias module.

Gravitron - Mon Aug 15, 2005 1:14 am
Post subject:

cocnut wrote:

disagree about resolution. It is in settings, you can run a zone without res limitation. As far as I know resolution was limited to decrease position and weapon traffic and also to make the game more fair because people with good huge monitors and resolutions was having an unfair advantage over the rest of players.

You got mighty confused here, I'm not talking about limitations.
I'm talking about setting a VIE client to 1280x1024dpi and entering the game, and setting a continuum client to 1280x1024dpi and entering the game, wooha, the VIE one actually provides several centimeters more of sight.

Only zone, AFAIK that actually uses the res limitation setting is trench, because it's a newb zone and they suck.

xor eax - Tue Aug 16, 2005 11:16 am
Post subject:

Bak wrote:

there is a module to capture subgame compatability called sgcompat. for anything else (like *spec) you can use my commandalias module.

Thank you, I will look into it. I have to learn the basics first.

Gravitron wrote:

[...] the VIE one actually provides several centimeters more of sight.

LOL... I don't want to start a discussion for a trivial thing like this, but... I just checked it, Continuum doesn't lose a single pixel on my monitor at 1280x1024, compared to what Subspace is showing. It must be something related to DirectX and your video card...

Gravitron - Tue Aug 16, 2005 12:06 pm
Post subject:

I suppose.
Now that I rechecked it seems to no longer exist.
So perhaps it had been a Dx/Gfx issue, though unlikely.
More possible, it been an issure with earlier continuum now fixed in 39.

Just to make it clear, though, in that we are in understanding:
I wasn't talking about getting more total screen room, more pixels.
I was talking about continuum's routines for proportional reduction in image sizes per resolution, to make it fit.
In VIE, I had smaller images, or so it seemed, as I was able to get more tiles in the screen, more "sight" between my ship and the end of the screen per my resolution than I was gettingn in continuum (IE continuum's %size reduction of ships/tiles was less than that of VIE).

Eitherway, SS is fad man.
Why not make something better?

Mine GO BOOM - Tue Aug 16, 2005 12:44 pm
Post subject:

Gravitron wrote:

Just to make it clear, though, in that we are in understanding:
I wasn't talking about getting more total screen room, more pixels.
I was talking about continuum's routines for proportional reduction in image sizes per resolution, to make it fit.
In VIE, I had smaller images, or so it seemed, as I was able to get more tiles in the screen, more "sight" between my ship and the end of the screen per my resolution than I was gettingn in continuum (IE continuum's %size reduction of ships/tiles was less than that of VIE).

At no point did Continuum ever make a pixel bigger or smaller than a pixel. No images were ever expanded or compressed. The only thing you could maybe be talking about, was that VIE read images as being made up of exactly 40x40 blocks, while Continuum knows it should have 40 blocks by 20 blocks, so each block is WIDTH/40, HEIGHT/20. So in that case, you could make ships bigger or smaller if you wish.

But still, each pixel in any image editor was always a pixel in Subspace or a pixel in Continuum. And if you used the default images, the total ship or bomb sizes were identical.

Gravitron - Tue Aug 16, 2005 4:38 pm
Post subject:

OF COURSE A PIXEL IS A FUCKING PIXEL DON"T GET MORONIC ON ME!
If I wasn't bussy slaying horde slimeballs I would dump your irish ass inside a mug and give you a wedgie.

*goes back to WoW*

Cerium - Tue Aug 16, 2005 5:17 pm
Post subject:

Grav...
Look on the bottom of your monitor. See those knobs? Some of them adjust the size of your monitors display region. Continuum doesnt have access to those. =(

Smong - Tue Aug 16, 2005 6:07 pm
Post subject:

Maybe ss/cont was changing your refresh rate, that sometimes changes the physical display size (and explains why alt-tabbing takes so long).

D1st0rt - Tue Aug 16, 2005 6:45 pm
Post subject:

This reminds me of that pixel size argument

Dr Brain - Tue Aug 16, 2005 11:31 pm
Post subject:

D1st0rt wrote:

This reminds me of that pixel size argument

Everytime I remember that I want to kill someone.

Bak - Wed Aug 17, 2005 12:39 am
Post subject:

in my web page design class back in high school one of the questions was how many pixels in an inch. I wrote an answer something on the lines of "it depends on your resolution", got it marked wrong (since it's auto graded), and then I stopped caring about that class.

xor eax - Wed Aug 17, 2005 9:13 am
Post subject:

I thought my bots can connect to asss but I'm having a problem uncompressing LVLs sent by assss. The call to ZLIB:uncompress fails with a Z_DATA_ERROR. Damnit... I hope I will trap it by logging the traffic and debugging Subspace if necessary (even subspace can inflate it and I just can't!!).

The size of the received compressed map is a bit larger than the size sent by subgame. But data have the expected size, the zlib signature is OK (0x9C78)... it looks like it needs to be uncompressed in another way...

I'm asking here trying to save time, because this could be an old issue. I've been searching forums and pages first but I haven't found anything related to LVL compression and assss. I won't upload the OCX until I'm sure it is asss compatible.

xor eax - Wed Aug 17, 2005 11:03 pm
Post subject:

It is solved.
Asss is not sending the packets in the right order. But it is my fault, I wasn't stacking the packets. Now I see that packets must be stacked and reordered to get the valid data (when downloading files from server). Subspace does it. I wasn't doing it because it seems not to happend with subgame... :p

Another thing...
I guess this must be a well know bug, but I found that a security checksum packet is usually received (from asss) during the map download, at login time. The level checksum sent by the client fails, of course, and it triggers a "Level checksum mismatch" security violation at server. I don't know which module is in charge of this but it needs a revision.

Dr Brain - Wed Aug 17, 2005 11:30 pm
Post subject:

Which version of ASSS are you testing against?

1.3.6 had some level checksum errors in it that 1.4.0 fixed. Just make sure you use the latest version. Of course, you could have found a bug that's in both.

xor eax - Wed Aug 17, 2005 11:37 pm
Post subject:

I'm using: asss 1.4.0 built at Jun 3 2005 23:36:24

Cerium - Thu Aug 18, 2005 5:13 am
Post subject:

xor eax wrote:

Another thing...
I guess this must be a well know bug, but I found that a security checksum packet is usually received (from asss) during the map download, at login time. The level checksum sent by the client fails, of course, and it triggers a "Level checksum mismatch" security violation at server. I don't know which module is in charge of this but it needs a revision.

1) Are you sending the packets reliably? Unless the code itself fucks up the order, thats the only way it should be able to happen. With something like an LVZ or level it should be sent reliably anyway, so make sure thats being done.

2) Subgame does the same thing, but seems to ignore the first incorrect level checksum.

xor eax - Thu Aug 18, 2005 9:59 am
Post subject:

Cerium wrote:

They are reliable, but I'm not sending them, asss does. All I'm doing is ACKing them. The last map packet is being received a lot of packets before than it should, as you can see in this code (packet SIDs correspond to map packets):

Code: Show/Hide

Logging in, please wait...
--wli.lvl -Server checksum:3911AAD9
Logged in successfully
Compressed map size: 47261
...
Packet SID: 80
Packet SID: 81
Packet SID: 82
Packet SID: 83
Packet SID: 84
Packet SID: 85
Packet SID: 86
Packet SID: 87
Packet SID: 88
Packet SID: 89
Packet SID: 90
Packet SID: 91
Packet SID: 92
Packet SID: 93
Packet SID: 94
Packet SID: 95
Packet SID: 110 <--- (last map packet)
Packet SID: 96
Packet SID: 97
Packet SID: 98
Packet SID: 99
Packet SID: 100
Packet SID: 101
Packet SID: 102
Packet SID: 103
Packet SID: 104
Packet SID: 105
Packet SID: 106
Packet SID: 107
Packet SID: 108
Packet SID: 109
Uncompressed map size: 105888
Map received (wli.lvl) 3911AAD9
105888 bytes.

But it could be my fault too... maybe I'm breaking protocol's flow somehow so asss consider that the map should be already sent or something like that...

Cerium wrote:

2) Subgame does the same thing, but seems to ignore the first incorrect level checksum.

OK. So it seems to be an old bug. But, again, I think I'm breaking the protocol because this error is much more frequent in my bots than in Subspace.

Cerium - Thu Aug 18, 2005 5:02 pm
Post subject:

The problem seems to be in your reliable packet handling...
If you receive a reliable packet with an ID higher than the next expected one (in this case 110 when you should be expecting 96), youre supposed to store it until 109 is received, then process it.

Reliable packets must be processed in the order they are ID'd which, as you can see, is not always the order theyre received.

Smong - Thu Aug 18, 2005 5:23 pm
Post subject:

Don't start sending position packets until you have the map downloaded, that way the server shouldn't ask you for a map checksum.

One reason the last map chunk comes early is because it is of a smaller size than all the other chunks. The bandwidth limiter might favour a smaller packet to try and use up all allotted bandwidth for that cycle. If you have time I invite you to look at the chunk packet code (and any related code) in asss and figure out why map downloads are slower than on subgame.

xor eax - Thu Aug 18, 2005 6:07 pm
Post subject:

Thank you very much, Cerium and Smong :)

I feel dumb about my "reliable problems" but I've learned the lesson.

I will look at the chunk packet code. About slow map downloads... is possible that asss is favouring game traffic against lvl/lvz traffic?