Ok, heres one for you brainy bunch to work out...
I've noticed when ever a builder makes a new ifcheck prog such as:
>entry_prog 100
if level($n) > 50 then
mea $n Welcome to the immy area, $n.
else
mea $n You shouldn't be here, $n...
mptran $n 21000
endif
It ends up coming up with a nice strange error...
Log: [*****] BUG: Mptransfer - No such location, Room #1200.
Log: [*****] BUG: Missing endif, Room #1200.
So heres the funny part, any ifchecks which was previously coded into areas such as DH, Battlegrounds etc... if they have ifchecks, their ifchecks work perfectly without bugs. It only happens with newly created if checks.. strange no?
So heres a few things i've tried:
Removing anything i've added to mud_prog.c (It didn't work..)
Downloaded SmaugFUSS 1.7 again, and added mud_prog.c to my SRC... also didn't work.
What precisely are the symptoms here? Are you saying that if a mudprog that existed before has a bug, e.g. a room it tries to transfer to doesn't exist, it doesn't report the missing endif?
Well, as you could see at the prog above... the end if exists in the prog, but the bug reports that the endif doesn't exist. And their for the ifcheck doesn't work all together.
It also seems that it doesn't allow mpcommands to work also, which it reports in the bug below the endif one.
All these bugs only appear when you write the mudprog new, an old existing mudprog works fine. So if i was to be building a new area, i would not be able to create ifchecks.
Well, for starters if you want to check the people entering the room you'd use a greet or greet all program. Enter progs are triggered when the mob itself moves to a new room. Might not be a bad idea to add a sanity check to prevent sending away NPCs that shouldnt be seen by players.
Zeno- Ok did what you said, i removed an ifcheck, and added the same one back in the same place... and now that has the bug. Im guessing it has something to do with the code? for ones that are not in area file? so the mud isn't understanding that if the area isn't installed it should be still doing the progs, i'll do some more tests and get back to you anyway with the results...
Oh by the sounds of it, the progs do not understand ELSE part of an ifcheck either... so i'll do an installarea and see what happens.
Meerclar - We dont have all_greet as its SmaugFUSS 1.7, i think the smaugfuss team had taken it out and replaced it with greet/entry, but both of them seem to work the same as each other. and sanity check? I'm guessin you mean a NPC check? the prog that i put up was just an example of whats happening... I wouldn't allow such a code to be used in established areas =)
Ok, so after installing a new area onto the mud... it's still coming up with the bug. However once i reboot the mud and the area is fully installed, the bug doens't exist...
So my throught of it being only when areas are being built etc was right... is there a section in mud_prog.c which would effect this? or am i lookin in the total wrong area?
No, that just doesn't make any sense. I think I didn't make my question clear enough; I was trying to distinguish the case of mudprogs that have errors seeing the endif and mudprogs that don't have errors that see the endif.
It is possible that if there is a bug in the mudprog, the mudprog driver gets confused and won't correctly parse the rest of the prog.
It is also possible that your client is sending strange characters to the edit buffer, which is confusing the driver somehow. Check the programs in the .are files to see if they look normal.
There's really no reason for an absolutely identical program to work before you touch it but not after, as long as it truly is absolutely identical.
Ah, well me and a few builders have tried to "fix" the problem inside the mud. Using different clients, mine being Zmud, another being MudMagic and one uses Telnet (::twitch::).
The problem seems to be based in when its being created, such as its not fully based into the mud. I have to install an area which is being built, and then reboot the mud before the area progs work... every prog then works perfectly.
If we are editing a currently existing area, it is also the same. The new progs we put into the existing room/mob/objects we still get error messages, we then fold the area and reboot the mud. Once the mud has been rebooted the progs we've added work fine, but before we reboot the progs come up with the "Endif" bug, and "ELSE" doesn't seem to be noticed either.
The progs are error free, apart from the ENDIF bug... and some mpcommands too. I know they are error free because they work perfectly once they have been installed fully and been rebooted.
This is the one from gods.are, and currently works.
> entry_prog 100~
if level($n) >= 51
mea $n Welcome to the immortal lounge $n!
else
mea $n You shouldn't be here!
mptrans $n 21000
endif
~
I will now delete this prog, and write a similar one its its place:
<32000hp 30000m 108mv> <#1200> rpstat
Name: The Tree of Life. Vnum: 1200.
>entry_prog 100
if level($n) >= 51
mea $n Hello $n, please remember to check the board.
else
mea $n Mortal players shouldn't be here, be gone!
mptransfer $n 21001
endif
and it still displays the old prog in the .are I will now FOLDAREA to see if it changes the prog in gods.are
Results:
> entry_prog 100~
if level($n) >= 51
mea $n Hello $n, please remember to check the board.
else
mea $n Mortal players shouldn't be here, be gone!
mptransfer $n 21001
endif
~
When i move out of the room, and move back into the room I recieve this:
Hello Samryn, please remember to check the board.
Mortal players shouldn't be here, be gone!
Log: [*****] BUG: Mptransfer - No such location, Room #1200.
Log: [*****] BUG: Missing endif, Room #1200.
So the IFCHECK doesn't seem to be existing either... because its giving me both responses.
Hope this is the information you needed Zeno.
Cheers again.
Eh... I think something bigger is going on here. If/else checks are known to work. Are you sure you haven't changed the mudprog code? Do you have a way of determining exactly what you have changed?
I added abits/qbits but i believe this was happening before this... as since then i've resorted back to mud_prog.c which comes straight from the tin.
I went back on SmaugFUSS website and re-downloaed the codebase, and then added the mud_prog.c into the src... so its back to where i started. I tested the SMAUG and it still comes with these errors.
Hmmm, could the problem go even deeper? I had to uncomment apart of the makefile for it to code cleanly on this server.
#Some systems need this for dynamic linking to work.
EXPORT_SYMBOLS = -export-dynamic
It's probably not the dynamic linking. But it is very strange that even basic if/else isn't working for you, because like I said that is a feature known to work for very many people.
Quote: I went back on SmaugFUSS website and re-downloaed the codebase, and then added the mud_prog.c into the src
I don't understand what exactly you did:
(1) you added your mud_prog.c to a stock SmaugFUSS archive
or
(2) you added SmaugFUSS's copy of mud_prog.c to your code
Number 2. I am using SmaugFUSS 1.7 anyway, so i redownloaed the stock smaugfuss, and added mud_prog.c to my code. I was hoping that would make it work, but without any luck.
OK. Try taking completely stock SmaugFUSS and see if you can reproduce this. That is, download the FUSS archive, change absolutely nothing, and see if this problem exists.
Chances are you changed something else, somewhere, in perhaps subtle ways, and maybe even forgot. (Happens to all of us!)
Oh, and you are remembering to make clean from time to time (e.g. after changing header files), right?
So i decided to try and to a gdb to check it out... and this is what its came up with:
Fri Jul 6 18:48:06 2007 :: IMC: imcfread_word: EOF encountered on read.
Fri Jul 6 18:48:06 2007 :: IMC: IMC2 network data loaded. Autoconnect not set. IMC2 will need to be connected manually.
Fri Jul 6 18:48:06 2007 :: Day of Dreams ready on port 4000.
Program received signal SIGINT, Interrupt.
0x001697a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) backtrace
#0 0x001697a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00242a0d in ___newselect_nocancel () from /lib/tls/libc.so.6
#2 0x080eaa06 in game_loop () at comm.c:953
#3 0x080e9cbe in main (argc=1, argv=0xbfef0e64) at comm.c:550
Those are actually two separate problems, and neither makes a lot of sense at first glance. :/
For the first, try doing csh --version and see what version of csh it's running.
Also, please paste the first line of the startup script; the one that starts with something like #!/bin/csh ...
For the second one, you might want to ask the SmaugFUSS forums; maybe somebody has seen it before. It might be something with the FUSS additions.
IMC has come up a number of times, you should be able to search for that exact error message here and find the solution you need. As for the other, yeah we need to see whats in your startup script.
I finally got a code to work, and then began implementing the changes i did to see where the bug appeared... and guess what? I've found the bugger!
There is a bug in SMAUG which causes telnet to not function the description right correctly... this function is copy_buffer.
Now the reason it causes the problem (as stated on: http://www.fussproject.org/index.php?a=topic&t=1098 ) is because it doesn't have \r. Now when you finally put \r into copy_buffer... it begins to cause the endif bug.
Now I'm sooo sorry for wasting your time. But surely there has to be another way to fix this? Because if I dont use \r the line isn't refreshed when using telnet, however if i do put \r into copy_buffer is causes mud_prog issues... anyone got any suggestions?
I guess the mudprog could internally wipe the \r, right? Or it could be programmed to just skip it as a character. I agree that this shouldn't be that huge of an issue...
Its just finding a solution now...
hmmm, I suppose I could try putting a boolean in? so like if its coming from a mud prog's point of view... it will change it to \n instead of \r\n?
The mudprog wont internally remove it, but i'm guessing it could somehow be programmed. Something like:
However, i'm not sure if its the actual writing the prog which is causing the problem, or is it the reading of the prog what is? if you get?
Once I know that, I can begin doing the boolean in the read or write part of the prog... making it so when it uses the copy_buffer. Now would this work, or not?
I think you're over-solving the problem. If the problem is only that the presence of \r characters confuses the mudprog driver, then the driver should be fixed to just skip over them as it parses the string. I don't think it's necessary to mess with the buffer contents or do fancy things like detecting where input/output is going.
Ok, heres one for you brainy bunch to work out...
I've noticed when ever a builder makes a new ifcheck prog such as:
...
it ends up coming up with a nice strange error...
Log: [*****] BUG: Mptransfer - No such location, Room #1200.
Log: [*****] BUG: Missing endif, Room #1200.
I can't reproduce this. Using stock Smaug FUSS 1.7, I can change progs without any problems.
OK, there are so many MUD clients around, for Windows, Mac, Linux, why are you changing the MUD code, in a way that stops it working, rather than getting your builder to simply use a client that works properly?
In any case, I wouldn't change it in that spot. There are lots of places (eg. help files) where the carriage-return is probably not present.
I would change the output routines, that if it gets a newline, that is not preceded by a carriage-return, that it inserts one there.
Not, to stick a carriage return into the editing buffer.
Hmmm so let me see if I'm understanding this correctly.
When Smaug is outputting the buffer, stick it on the end? So like, when its displaying room descriptions, notes, progs, etc... it will stick it on the end?
How would this be done though? as from what i can see, the description is just read and dumped into the players client. So wouldn't that mean seperating each line and sticking the carriage-return in?
Sorry if these seem dumb questions but thought i better ask to make sure i'm understanding correctly. Thanks again.
I think that Nick was suggesting that your builder should get a client that works properly, and can handle the various \r and \n codes etc., instead of messing with the code too much. :-)
Yes, I *was* suggesting getting a proper client. I can understand a newbie not having a client, as they may be playing a MUD for the first time. But a builder?
Quote:
When Smaug is outputting the buffer, stick it on the end? So like, when its displaying room descriptions, notes, progs, etc... it will stick it on the end?
No, that won't work. For one thing, the sequence in \r\n, not \n\r, so putting \r at the end is the wrong place.
Also, some text in the output buffer will have multiple lines in it, particularly when read from help files, and also inside the code, it may generate multiple lines.
You would have to write a routine that inspected each buffer, and do something like this:
Is the current character a newline? (\n)
If so, was the previous character a carriage-return? (\r)
If not, insert a \r before the \n.
Move onto the next character
You would need to allow for the buffer becoming larger. This would also introduce a marginal speed decrease for everyone.
The MUD already does something like this to convert internal colour codes into ANSI codes, maybe you could find where it does that and modify that.