Server Help

ASSS Questions - Objects

Bak - Fri Jul 08, 2005 10:50 pm
Post subject: Objects

it seems when you take the asss 1.4.0 for windows. Insmod object and do an *objon it crashes the server. When I recompiled objects in it's own module, taking the code exactly from objects.c and objects.h and used that module, it worked fine without crashing.

Also there are a lot of header files out of place (for example the packets directory needs to be in the include directory).

When objects is set up to load in modules.conf and you do objinfo all works well. then you rmmod objects and insmod objects and do objinfo again and it says the lvz object the that object id can not be found. Also objinfo assumes there's only one object per object id which is not necessarily the case, as objects can share ids.

D1st0rt - Fri Jul 08, 2005 11:49 pm
Post subject:

I can't get makefiles to work yet, sent grel a ?message about it.

When I used ($eval ($call dltemplate, library)) gcc said there was no input file

Bak - Sat Jul 09, 2005 12:32 am
Post subject:

Found another bug in the standard distibution of the ojbects module. In sendstate you currently have:

Code: Show/Hide

if (t >= ad->tog_diffs || e >= ad->ext_diffs)
break;

but you really want to change that or to an and (&&). The reason for this is that you don't want to stop sending that state until both all the objects that have been modified and all the objects that have been toggled are accounted for, not one or the other. The way it is now if you have no modified objects, it won't send any (since e >= ad->ext_diffs, 0 >= 0). This gives the appearance of the state saving lvz not working, when you put all the effort into making it work. It works fine after this change.

Grelminar - Sat Jul 09, 2005 3:56 am
Post subject:

In general, I'm not surprised ?insmod objects behaves funny. Some modules aren't written to be loaded while arenas are running. If you could improve objects so it worked correctly in those cases, I'd be happy to accept it.

I can't comment much about the code, since I didn't write it, and don't really know anything about objects. Your fix (|| -> &&) makes sense to me, though, and I fixed it in my working copy.

I really have no idea the built version of objects crashed but yours worked. Did you do the exact same sequence of steps with both? Is the crash reproducable? Did you get a backtrace? What compiler/linker did you build yours with?

I wouldn't call the packets directory "out of place". I left it where it is on purpose. You might argue that it makes more sense somewhere else, but I don't see a compelling reason to move it.

Bak - Sat Jul 09, 2005 5:09 am
Post subject:

I did the exact sequence of steps and yes, the crash is reporducable (insmod, objon). The backtrace Just In Time Debugging gave me was assembly, as the the .exe wasn't compiled with VS.net in debug mode so this was as expected. I use VS.NET 2002 to compile and link my code. My theory is that pthreadVC.dll isn't by default in the same directory as asss.bat, and is required for the objects module to work.

The only reason I complain about the location of the directories isn't that I disagree with your organization (I like the recent changes you've done), but that in a file like ball.c you have

Quote:

#include "packets/balls.h"

so being a good compiler VS.NET looks for the packets folder realitive to the balls.c file which doesn't exist. So I have to go through by hand and change it to

Quote:

#include "../packets/balls.h"

Now this kind of thing is in most .h and .c files so it gets little repetitive.

Dr Brain - Sat Jul 09, 2005 11:08 am
Post subject:

You shouldn't have to do that. You should tell VS the location of the base include directory.

Grelminar - Sat Jul 09, 2005 4:35 pm
Post subject:

Uh, "asss.h" and "persist.h" aren't in the same directory as balls.c either, but it can find those, right? If you look at the Makefile, you can see that among the flags passed to the compiler are "-I. -Iinclude -I$(BUILDDIR)". The dot refers to the "src" directory itself, which makes paths like "packets/balls.h" work. Just set up your compiler with the equivalent options, and everything should be file.

If it couldn't find the pthreadVC.dll file, it would give you an error when loading the module, not a crash.

Bak - Tue Aug 02, 2005 1:07 pm
Post subject:

Alright, well that works, although I have to set it for every module I make now (one project per module).

Anyways here's another bug. The Move function crashes the server if your target isn't T_ARENA. Now the bug isn't the lack of functionality for T_PLAYER targets, just if you do give it a T_PLAYER target, it crashes. This wouldn't be a big deal if modules were the only things using the Move function (just don't code per player objmoves), but the *objmove command calls the Move function, and doesn't do any checking of the target, which could possibly be a player.

The move function does check for T_ARENA before it sends the packet, but not when it gets the per arena data based on t.arena, which is a crash if it's a player pointer .

Quote:

aodata *ad = P_ARENA_DATA(t->u.arena, aokey);

Here's one possible fix:

Code: Show/Hide

void Move(const Target *t, int id, int x, int y, int rx, int ry)
{
if (t.type != T_ARENA)
{
   lm->Log(L_INFO,"<objects> objmove for non-T_ARENA target not currently supported.");
}
else
{
   BEGIN_EXTENDED(t, id);

   *(u8*)objm = 0;
   objm->change_xy = 1;

   if ((objm->data.mapobj = node->defaults.mapobj))
   {
      objm->data.map_x = x;
      objm->data.map_y = y;
   }
   else
   {
      objm->data.scrn_x = x;
      objm->data.scrn_y = y;
      objm->data.rela_x = rx;
      objm->data.rela_y = ry;
   }

   END_EXTENDED(t, id);
}
}