I've successfully compiled swrfuss under cygwin, but when i start swr and create a new char, or enter as the default admin, the mob progs don't work. I didn't do anything to the code, just download, compile, run.

The droid at the academy don't give water or food, the luke skywalker doll girl don't say anything, the girl that talk about the clones, dont say anything too...

Is this a bug or what?

Don't know what to do... if someone could help i would appreciate..

Thanks

Dekar

are you invis?

Some progs check character level before executing code following an if statement. I guess this is common behavior. The academy progs are fine for new players last I checked. I was using cygwin.

dban2 -> no, not invis...
Stan -> new players (lvl 1) don't see anything either...

In the case of the luke skywalker doll girl, when you say door/key she cries, but don't say anything...

You say 'door'
A small child bursts into tears.

i think that it's the only thing (prog) working in the academy area...

the food/water droid don't give rations and canteens...
and the others don't do anything in others areas too...

in menari spaceport the "A small child begs for money" dont say "Spare some change?" for example...

#MUDPROG
Progtype  speech_prog~
Arglist   door door? key?~
Comlist   if ovnuminv (10320) >= 1
say You want the key for this door?
point north
say here let me open it for you
mpat 10399 mpoload 10423
unlock north
open north
mpat 10399 drop all
mpat 10399 purge
else
cry
endif
~
#ENDPROG

The program is doing what it was told to do. If the doll had the key it would open the door etc... no key so it just cries.

the code is right, but seems that it don't "start"
the prog code is exactly the same...

try to download/compile/run and create a new character,
then walk to the "clone" girl, food/water droid and the doll girl...

nothing happens...

Ok, this is a code issue. Open up db.c
around line 6055 find

               SET_BIT( prog_target->progtypes, 1 << mprg->type );

change that to this

               SET_BIT( prog_target->progtypes, mprg->type );

around line 6474 find

               SET_BIT( prog_target->progtypes, 1 << mprg->type );

change that to this

               SET_BIT( prog_target->progtypes, mprg->type );

This makes it so it will set the progtypes correctly and they will work again.

Problem is on loading up it doesnt set the progtypes right so it just ignores them lol.

There is also another problem (while not critical it would be annoying) where it changes the order of the programs every time the mud boots up.
For example use the one in your example that gives you the doll if you say yes it has 3 programs the top and bottom will change order each boot up if you boot it up, fold the area, hotboot, fold the area, hotboot, etc... I don't have the time to look into if it is in loading the programs or saving them but somewhere it changes the orders and I think it is in loading since the way they are in the area file will not be how it displays them in the mud after startup.

Remcon said:

There is also another problem (while not critical it would be annoying) where it changes the order of the programs every time the mud boots up.
For example use the one in your example that gives you the doll if you say yes it has 3 programs the top and bottom will change order each boot up if you boot it up, fold the area, hotboot, fold the area, hotboot, etc... I don't have the time to look into if it is in loading the programs or saving them but somewhere it changes the orders and I think it is in loading since the way they are in the area file will not be how it displays them in the mud after startup.

This is something that happens in just about any Smaug derivative.

It Works!
Thanks!!!

Remcon said:
"This makes it so it will set the progtypes correctly and they will work again.
Problem is on loading up it doesnt set the progtypes right so it just ignores them lol. "

there's one thing i've seen...
without the Remcon changes...

if i add some prog (just add a prog with anything written in it and then keep or remove it)
or rewrite the prog in the mud (logged in, not in file)
the prog works perfectly...

Now that I think about it. This is probably something I should fix in the bases, huh? Guess I'll get an updated release ready.

Dekar said:


if i add some prog (just add a prog with anything written in it and then keep or remove it)
or rewrite the prog in the mud (logged in, not in file)
the prog works perfectly...

just to say that if a mob have 4 progs for example...
and you do anything i've said up here...
not only one but all the progs that the mob have, works...

Yea during testing I seen that also which is why I figured that on loading it wasn't setting up what kind of programs it had correctly. And before the change you didn't have to add/delete simply taking and editing one and saving it worked also.

Yea kayle it should probably be fixed in the base

Hmm I will have to look into it then if it affects all the bases I've never paid it any attention till now lol.

Well looks like you are right and probably most them do that. I'll be fixing that sometime later in LoP though since I think they should stay in the order they get put in lol.

The only thing i need to do is make the changes that is in your post up here?
or there's something else that i need to do?

and the bases will be updated?

I'll be getting the distributions updated sometime soon, hopefully. Dealing with a bit of a server issue atm though, so it's slow going.

Yea the posted changes will fix the issue. The one I was talking about in my last post is the part where it changes the orders of the programs each time the mud is ran.

Remcon said:

The one I was talking about in my last post is the part where it changes the orders of the programs each time the mud is ran.

Can you post it when it's done?

Omg! I've been wondering about this same exit problem for about 2 months xDD

Thanks Remcon! It's also happening in the swfote base also, just those 2 lines of code makes this huge of a headache. Geez, lol.

is this problem is smaug1.4a too?

dbna2 said:

is this problem is smaug1.4a too?

No. Both the invalid setting of progtypes and the order of load bugs are FUSS specific and
do not effect SMAUG or non FUSS derivatives (at least none I have seen). The bugs specifically
relate to the FUSS tagged area file loading format, so older versions of the FUSSes might also
not be affected.