06 Mar, 2007, Zeno wrote in the 1st comment:
Votes: 0
Any chance someone could write up a tutorial (perhaps as an article) on how to code in a new variable for mobs (which would be saved)? Obviously I know how to code, but I'm unsure of everything that needs to be done (AREA_VERSION update?) and I'd really appreciate if someone wrote up a tutorial. I don't want to take a swing at this without knowing exactly what to do at the risk of corrupting area files.
06 Mar, 2007, kiasyn wrote in the 2nd comment:
Votes: 0
iirc this would have to also have to include changed to group_obj etc.
07 Mar, 2007, Zeno wrote in the 3rd comment:
Votes: 0
I uh, don't think group_obj involves mobs.
08 Mar, 2007, kiasyn wrote in the 4th comment:
Votes: 0
well if you do this for mobs an article for objs should probably be done too.. rooms also. is anyone actually doing this? if not ill do it.
08 Mar, 2007, Guest wrote in the 5th comment:
Votes: 0
It would be greatly appreciated if you could do this Kiasyn. Others can always update it if any of the information doesn't look right :)
03 Jun, 2007, Zeno wrote in the 6th comment:
Votes: 0
Has anyone taken a crack at making a tutorial yet?
03 Jun, 2007, Scandum wrote in the 7th comment:
Votes: 0
1. Grep the sourcecode for an existing variable that has the desired behavior.

2. Apply the changes on a test server.

3. Test and debug.

4. Apply the changes on the real server.

5. Kick back with some beers and kill some mobs while flirting with the opposite sex over the chat channel.

I hope this is of any help.

Scandum, Lord of the Source.
03 Jun, 2007, Zeno wrote in the 8th comment:
Votes: 0
Well yes, as I said doing that is simple. But this is not the case. This requires a global update to all areas using AREA_VERSION, and that hasn't been done in Smaug for mobs. So no existing variable is there to look over.
03 Jun, 2007, Guest wrote in the 9th comment:
Votes: 0
Late to the game here, as usual :)

If you're adding a new variable to the index data for a mob, and you want it saved to the area file, you'll definitely need to alter your AREA_VERSION_WRITE value. The stock format for areas is too rigid to allow you to just throw it in and not have it there for all of your old files. This is the kind of thing where converting to a KEY based system would solve a lot of things.

Simply broken down, you'd need to:

1. Create your new variable.
2. Implement a way to modify it online, so you can test and make sure it works, and allow it to be used by builders.
3. Add it to the fold_area code so it will save where you want it to.
4. Add it to load_mobiles with the appropriate version tag block so old files that don't have it will still load. And probably set a default value on mobs that don't have it yet.

That's about all there is to it, but step 4 wouldn't need to have any special coding to make work. Just if old mobs didn't have it you'd still need a way to make sure they do, if they have to have some default value.
04 Jun, 2007, Zeno wrote in the 10th comment:
Votes: 0
For #4, all I need is just one ifcheck against the area version?
04 Jun, 2007, Guest wrote in the 11th comment:
Votes: 0
Pretty much, yes. Something like:

if( version > 3 )
do_something();
else
do_nothing();
07 Jun, 2007, Justice wrote in the 12th comment:
Votes: 0
What I've done to simplify modifying the area files is to use code similar to how mprogs are loaded to add a section for mprogs that uses a key based system. This allows you to have the benefits of a key based system without having to completely rewrite the SMAUG code, and since it's a conditional section doesn't affect previous area version… Yeah I'm lazy, never even bothered to change the area version #. Heh, I also always output the section when an area file is written, since it doesn't increase the file size much, and it's more to prevent read issues than anything else.
08 Jun, 2007, Guest wrote in the 13th comment:
Votes: 0
Well yes, a KEY based area format like pfiles are done would solve many of these kinds of problems. About the only time adding versioning code comes into play then is when you alter the function of an existing field, or your new field needs a sane default value.
12 Jun, 2007, Zeno wrote in the 14th comment:
Votes: 0
Samson said:
Late to the game here, as usual :)

If you're adding a new variable to the index data for a mob, and you want it saved to the area file, you'll definitely need to alter your AREA_VERSION_WRITE value. The stock format for areas is too rigid to allow you to just throw it in and not have it there for all of your old files. This is the kind of thing where converting to a KEY based system would solve a lot of things.

Simply broken down, you'd need to:

1. Create your new variable.
2. Implement a way to modify it online, so you can test and make sure it works, and allow it to be used by builders.
3. Add it to the fold_area code so it will save where you want it to.
4. Add it to load_mobiles with the appropriate version tag block so old files that don't have it will still load. And probably set a default value on mobs that don't have it yet.

That's about all there is to it, but step 4 wouldn't need to have any special coding to make work. Just if old mobs didn't have it you'd still need a way to make sure they do, if they have to have some default value.


Look over the steps again, I'm confused. Wouldn't you have to update the area version?
13 Jun, 2007, Guest wrote in the 15th comment:
Votes: 0
I probably worded it badly. You need to version the area file in stock form. With a KEY system you don't. Step 4 would be unnecessary unless you needed to force the new value to something sane.
13 Jun, 2007, Zeno wrote in the 16th comment:
Votes: 0
Yeah I understand if it was a KEY system, I wouldn't need to do all of this.

Not sure what you mean by "version the area file" though.
14 Jun, 2007, Kayle wrote in the 17th comment:
Votes: 0
a versioned area file would look something like:

ln = fread_line( fp );
x1 = x2 = x3 = x4 = x5 = x6 = 0;
sscanf( ln, "%d %d %d %d %d", &x1, &x2, &x3, &x4, &x5, &x6 );
pMobIndex->hitroll = x1;
pMobIndex->damroll = x2;
pMobIndex->xflags = x3;
pMobIndex->attacks = x4;
pMobIndex->defenses = x5;
if( area_version >= 5 )
pMobIndex->infected = x6;


assuming I understood Samson correctly.
16 Jun, 2007, Zeno wrote in the 18th comment:
Votes: 0
But wouldn't you be sscanf'ing in an extra variable no matter what the area version is, in the case of your code? Getting more confused here. >.>

[EDIT] Okay I added the code, without knowing what I was doing. :P No one mentioned ifchecks for XBI (no idea what that is) or complex_mob.

Now I'm even more confused. Should I be checking AREA_VERSION_INDEX? I did that, but loading proto area crashes because it tries to load the new variable due to checking AREA_VERSION_INDEX even though the area version is 2, and not 3.
16 Jun, 2007, kiasyn wrote in the 19th comment:
Votes: 0
sscanf is pretty error tolerant iirc, it should just ignore the missing value

AREA_VERSION_INDEX should be updated each time you make a change to the -saving- of the area file, you do not check against AREA_VERSION_INDEX when you load, you use magic numbers (yay!).

where did XBI come into this? =]
16 Jun, 2007, Justice wrote in the 20th comment:
Votes: 0
XBI relates to the Smaug 1.4a extended bitvector stuff.

Previously a single int was used, under XBI, an array of ints are used.
0.0/24