Hello again! I've ran into another problem with socketing. I have it completely working, but when you try to load the mud with existing .obj files the mud crashes. I didn't run into this issue, because I had no .obj files. When you create new obj or .obj file it saves and loads correctly.
Here is the exact error I get:
Nov 15 01:04:15 :: SYSERR: Format error in (f): object #1, after numeric constants …expecting 'E', 'A', 'B', '$', or next object number
So this error made me believe its in this function:
/* read all objects from obj file; generate index and prototypes */ char *parse_object(FILE *obj_f, int nr) { static int i = 0; static char line[READ_SIZE]; int t[10], j, retval; char *tmpptr, buf2[128], f1[READ_SIZE], f2[READ_SIZE], f3[READ_SIZE], f4[READ_SIZE]; char f5[READ_SIZE], f6[READ_SIZE], f7[READ_SIZE], f8[READ_SIZE]; char f9[READ_SIZE], f10[READ_SIZE], f11[READ_SIZE], f12[READ_SIZE]; struct extra_descr_data *new_descr;
/* string data */ if ((obj_proto[i].name = fread_string(obj_f, buf2)) == NULL) { log("SYSERR: Null obj name or format error at or near %s", buf2); exit(1); } tmpptr = obj_proto[i].short_description = fread_string(obj_f, buf2); if (tmpptr && *tmpptr) if (!str_cmp(fname(tmpptr), "a") || !str_cmp(fname(tmpptr), "an") || !str_cmp(fname(tmpptr), "the")) *tmpptr = LOWER(*tmpptr);
if (!get_line(obj_f, line)) { log("SYSERR: Expecting second numeric line of %s, but file ended!", buf2); exit(1); } if ((retval = sscanf(line, "%d %d %d %d", t, t + 1, t + 2, t + 3)) != 4) { log("SYSERR: Format error in second numeric line (expecting 4 args, got %d), %s", retval, buf2); exit(1); } GET_OBJ_VAL(obj_proto + i, 0) = t[0]; GET_OBJ_VAL(obj_proto + i, 1) = t[1]; GET_OBJ_VAL(obj_proto + i, 2) = t[2]; GET_OBJ_VAL(obj_proto + i, 3) = t[3];
if (!get_line(obj_f, line)) { log("SYSERR: Expecting third numeric line of %s, but file ended!", buf2); exit(1); } if ((retval = sscanf(line, "%d %d %d %d %d", t, t + 1, t + 2, t + 3, t + 4)) != 5) { if (retval == 3) { t[3] = 0; t[4] = 0; } else if (retval == 4) t[4] = 0; else { log("SYSERR: Format error in third numeric line (expecting 5 args, got %d), %s", retval, buf2); exit(1); } }
If this finds the B it checks the socket affect line:
case 'B': if (j >= MAX_SOCKET_AFFECT) { log("SYSERR: Too many B fields (%d max), %s", MAX_SOCKET_AFFECT, buf2); exit(1); } if (!get_line(obj_f, line)) { log("SYSERR: Format error in 'B' field, %s\n" "…expecting 2 numeric constants but file ended!", buf2); exit(1); }
[code] #1 wings~ a pair of wings~ A pair of wings is sitting here.~ ~ 9 0 0 0 0 ae 0 0 0 0 0 0 0 6 0 0 0 1 1 0 0 0 [/code]
Now clearly we can see that the fourth numeric line is missing. Which should be 0 0. Does anything have any ideas to fix this so people will not have to object wipe?
With these types of modifications, there's a process you must go through. You cannot make modifications to both the saving and loading protocols and expect your MUD to reboot fine when you have such a ridged file format. You always want to make your modifications to your saving first, copyover/reboot your MUD, save your world, modify loading protocols, then reboot/copyover.
20 Nov, 2012, Rarva.Riendf wrote in the 3rd comment:
Votes: 0
This should always be tested in a test environment and never on your production code. So you can revert to previous situation and create for yourself a document that details everything you must do to push the change on production. If you are modifying player files I suggest you have an option to load them all and save them while the mud boot.
With these types of modifications, there's a process you must go through. You cannot make modifications to both the saving and loading protocols and expect your MUD to reboot fine when you have such a ridged file format. You always want to make your modifications to your saving first, copyover/reboot your MUD, save your world, modify loading protocols, then reboot/copyover.
See the test was on MY(modified version of tbamud) mud, but when I tried to apply it to stock tbamud I get the crash. When I applied it to my mud, I had no crash or anything.
This should always be tested in a test environment and never on your production code. So you can revert to previous situation and create for yourself a document that details everything you must do to push the change on production. If you are modifying player files I suggest you have an option to load them all and save them while the mud boot.
It was tested. It's only having crashing problems when testing on a stock tbamud. I'm only modifying .obj files, not players.
It was tested. It's only having crashing problems when testing on a stock tbamud. I'm only modifying .obj files, not players.
A bug does not always lead to a crash. The fact that it crashes on a stock TBA without you understanding why should raise a concern about the validity of the code even on your mud You could read/write wrong value and not necesserily know it till some real obvious glaring error show. All armors being set to a reasonnable value cause you read the wrong line wont crash anything, nor even raise a concern on unsuspecting players. And that was jsut an example of what could happen
Hell it could even crash later, as any modication to code lead to a different memory allocation, thus it could crash on stock mud right away, and on yours like days later. The same bug does not lead to same problems for a lot of reasons. . And you are saying you are modifying object but not player, I dunno about tbamud, but objects are saved on players too on some muds.
Here is the exact error I get:
So this error made me believe its in this function:
Now to be more detailed in what I added when programming sockets and socket affects, this is what I added to parse_object:
This code checks min/max sockets in the .obj file:
This code checks the sockets affect flags:
If this finds the B it checks the socket affect line:
Now you may ask, let me see how you have the "B" saving, here is the code in genobj.c that saves socket affects: