23 Jul, 2010, Rarva.Riendf wrote in the 21st comment:
Votes: 0
'Well, this is a problem pretty much no matter what approach you take.'
Yep but the approach with global char iterator has made it 'in your face explode' (as the pointer is set to NULL) if I forget to test it, a very easy way to handle the bugs one at a time till there are none left (and then probably do a proper delayed extraction or safe iterator once I am sure the code actually already handle it)

'Don't worry, I've done my fair share of MUD (and other) programming. '
I never have any doubt about that, but still you did not actually answer. Have you ever worked with a stock ROM code :p
Your code is valid but IMHO you really underestimate how sucky ROM code is.

(I worked as a coder professionally for 9 years…Stock ROM code made me cry at how it was badly designed)
23 Jul, 2010, David Haley wrote in the 22nd comment:
Votes: 0
Quote
Yep but the approach with global char iterator has made it 'in your face explode' (as the pointer is set to NULL) if I forget to test it, a very easy way to handle the bugs one at a time till there are none left (and then probably do a proper delayed extraction or safe iterator once I am sure the code actually already handle it)

Well, if your goal is to cause catastrophic failure when character removal is handled poorly, then I guess having it explode in your face is better because you'll get an immediate core dump. I'm kind of a fan of having it not explode, while knowing that I won't iterate over invalid characters. :wink:

(And to be clear, I am not using "catastrophic failure" in a bad way; sometimes forcing crashes really is useful… but not when you have a game that's actually up and running with players etc.)

Quote
Have you ever worked with a stock ROM code :p

Yes, I have, although I spent more time with SMAUG, which shares a similar problem (and many others of its own).

Quote
Your code is valid but IMHO you really underestimate how sucky ROM code is.

Well, yes, but I'm not sure what you're getting at. If it's sucky, but we have valid code to improve it, isn't that a good thing? :smile:
23 Jul, 2010, Rarva.Riendf wrote in the 23rd comment:
Votes: 0
David Haley said:
Well, if your goal is to cause catastrophic failure when character removal is handled poorly, then I guess having it explode in your face is better because you'll get an immediate core dump. I'm kind of a fan of having it not explode, while knowing that I won't iterate over invalid characters. :wink:
(And to be clear, I am not using "catastrophic failure" in a bad way; sometimes forcing crashes really is useful… but not when you have a game that's actually up and running with players etc.)

I do not have that many players, it is a very old mud, that had so many problems a little crash here and there is already better than before so they can cope with it ;p (I personally prefer a perfectly working code (not that hard to achieve for a mud) than a 'weird randomly behaviour mud'

Quote
Well, yes, but I'm not sure what you're getting at. If it's sucky, but we have valid code to improve it, isn't that a good thing? :smile:

Just getting at: if you did not implement this solution in a stock ROM that may explain why you find it so easy, though I may not understand you. I agree the solution is 'easy' as in easy coding skill required, but not easy to implement as the base code was really not ready for it. It is not like you could work some methods and 'tada' it is done, but there are so many loops and code to check it is fucking hell.
Especially since again rom code has absolutely to test code done.
23 Jul, 2010, David Haley wrote in the 24th comment:
Votes: 0
Quote
I personally prefer a perfectly working code (not that hard to achieve for a mud) than a 'weird randomly behaviour mud'

Sure, I think that's probably true of everybody. Fortunately, though, the approach I suggested does not result in a weird randomly behaving MUD. :smile:

Quote
Just getting at: if you did not implement this solution in a stock ROM that may explain why you find it so easy, though I may not understand you. I agree the solution is 'easy' as in easy coding skill required, but not easy to implement as the base code was really not ready for it.

Well, let's put it this way: what kind of problems, concretely, will come up when adding in the code I described? The approach I have described fixes the problem of iterating over killed or otherwise invalidated characters when paired with delayed deletion/extraction. Nothing there is terribly hard to implement. At worse, it would be slightly tedious to replace the loops, but they're broken anyhow and any solution requires messing with them one way or the other. What is an example of something that is "easy […] but not easy" here?
23 Jul, 2010, Rarva.Riendf wrote in the 25th comment:
Votes: 0
'What is an example of something that is "easy […] but not easy" here? '
The fact that it will not crash, hence you cannot detect if the code is actually working or not.
23 Jul, 2010, David Haley wrote in the 26th comment:
Votes: 0
Lack of crashing is not evidence of proof of correctness.
23 Jul, 2010, Rarva.Riendf wrote in the 27th comment:
Votes: 0
That is exactly the point, implementing your solution will not solve any problems, it will only give you a safe solution for future code. It will not help you detect any of the existing bugs that are already hidden by the so called memory manager.
Your solution is how it should have been engineered in the first place.
Stock ROM code should be totally rewrited with this in place, and prevented to be released before it is done, because it opens a bag of hurt for any newbie coder that thinks it is a safe code to work on. (and for any other that do not realize it at first thinking no one could have been stupid enough to not know the concept of safe iterator)
23 Jul, 2010, David Haley wrote in the 28th comment:
Votes: 0
Um… Implementing my solution will make character iteration safe. Isn't that what we wanted? :thinking:

Well, in any case we completely agree that the stock code is pretty lame. :wink:

Maybe you should talk to the Ice/Fire people (see appropriate forum subsection) – it was a project to modernize ROM and this would be an excellent thing to fix in that distribution. (Unfortunately, people seem to have sort of lost interest in the project…)
23 Jul, 2010, Rarva.Riendf wrote in the 29th comment:
Votes: 0
David Haley said:
Um… Implementing my solution will make character iteration safe. Isn't that what we wanted? :thinking:

Not only not only ;p
David Haley said:
Well, in any case we completely agree that the stock code is pretty lame. :wink:

No doubt heh..

David Haley said:
Maybe you should talk to the Ice/Fire people (see appropriate forum subsection) – it was a project to modernize ROM and this would be an excellent thing to fix in that distribution. (Unfortunately, people seem to have sort of lost interest in the project…)

Had I knew this when I began, I would have. My code differs so much from the existing ROM that it would not help me anymore :p
And I bet it is the case of many other. (or I hope so hehehe)
But I may write a 'WARNING READ ME' that points to every potential problems you may fall in with stock ROM heh…
23 Jul, 2010, David Haley wrote in the 30th comment:
Votes: 0
Quote
But I may write a 'WARNING READ ME' that points to every potential problems you may fall in with stock ROM heh…

That sounds like it would be fairly useful and a nice contribution to the community.
25 Jul, 2010, Mudder wrote in the 31st comment:
Votes: 0
I'd like that. Do it please. :)
25 Jul, 2010, Rarva.Riendf wrote in the 32nd comment:
Votes: 0
I will, it will take some times though, as I will have to go through differences between my code and stock ROM one.
Just think about stuff like that…..: (that is in violence_update)
for ( ch = char_list; ch != NULL; ch = ch->next )
ch_next = ch->next;

Not to mention atrocities like the check_assist, than can give two rounds of multi_hit in the same round (you start a fight, people in your group are checked for assisting and start the fight, if they are after you in the loop, they will be found 'fighting' and have another round of attack for free yay !)

The listing is so long I actually do not know what to begin with.
25 Jul, 2010, Kjwah wrote in the 33rd comment:
Votes: 0
Rarva.Riendf said:
That is exactly the point, implementing your solution will not solve any problems, it will only give you a safe solution for future code. It will not help you detect any of the existing bugs that are already hidden by the so called memory manager.
Your solution is how it should have been engineered in the first place.
Stock ROM code should be totally rewrited with this in place, and prevented to be released before it is done, because it opens a bag of hurt for any newbie coder that thinks it is a safe code to work on. (and for any other that do not realize it at first thinking no one could have been stupid enough to not know the concept of safe iterator)


Then most MUD code needs to be rewritten from scratch. :D The problem with codebases like ROM is when where they last actively maintained? Almost twenty years ago. Yes, it's been that long. Makes you feel old, doesn't it? It does to me.

Sure, things are far from perfect but it's also not professional software you're paying for. :D You suggest other people not even use the base for whatever reason but if people put the same effort and energy to making another codebase act and feel like ROM, they could just rework ROM where needs to be done. It would probably even be a fun project for an excellent coder that likes to just code. Which seems to be lacking lately(Coders coding just to hear themselves speak, so to say.)
25 Jul, 2010, Ssolvarain wrote in the 34th comment:
Votes: 0
Kjwah said:
they could just rework ROM where needs to be done.


I was hoping this might get done before I was called an "old geezer". If there was a list if things missing or not working in ROM, I could probably contribute a few things. And I'm just a lousy builder ;D
25 Jul, 2010, ralgith wrote in the 35th comment:
Votes: 0
Or you could just use a different codebase that has already been modernized… such as tbaMUD. ;)
26 Jul, 2010, Rarva.Riendf wrote in the 36th comment:
Votes: 0
ralgith said:
Or you could just use a different codebase that has already been modernized… such as tbaMUD. ;)

Exactly what I am warning about.
Most of the coder that use a ROM base are I hope people like me who inherited a MUD, and prefer to use their time coding around it. Though conidering the time I already poured in, I could have migrate it to whatever base was better heh. I just want to avoid this to newbies or people in the same situation than me.

ralgith said:
Which seems to be lacking lately(Coders coding just to hear themselves speak, so to say.)

Fact is I am quite tired lately, but I do code at least 1 to 3 hours a day on the mud, debugging it.
But since I rewrited a lot of stuff, migrating my fix to ROM would take ages…Like I said, had I be warned about all the problems, I would have either fixed the engine first, or migrate to a fixed base.
A list will come once I finish to fix the mess, but I am still coding heh.
26 Jul, 2010, Tyche wrote in the 37th comment:
Votes: 0
ralgith said:
Or you could just use a different codebase that has already been modernized… such as tbaMUD. ;)


So what happens on tbaMUD when one casts an area spell that loops through the room damaging characters (like a chain lightning),
and a HITPRCNT trigger is run off a damaged mob that %teleports% the caster out of the room?
26 Jul, 2010, ralgith wrote in the 38th comment:
Votes: 0
Tyche said:
ralgith said:
Or you could just use a different codebase that has already been modernized… such as tbaMUD. ;)


So what happens on tbaMUD when one casts an area spell that loops through the room damaging characters (like a chain lightning),
and a HITPRCNT trigger is run off a damaged mob that %teleports% the caster out of the room?


Not sure. I've never done that ;)

Two possibilities as I see it:
it keeps looping through the targets in the original room. Most likely.
Or, it starts looping through the targets in the new room. Probably not.
27 Jul, 2010, ralgith wrote in the 39th comment:
Votes: 0
MMmm, I should have also added to the previous statement that I also believe the first possibility is the correct one. If you've already casted a spell in a room, it should affect the targets in that room. Not move with you. At least that's my view.
29 Jul, 2010, Rarva.Riendf wrote in the 40th comment:
Votes: 0
ralgith said:
MMmm, I should have also added to the previous statement that I also believe the first possibility is the correct one. If you've already casted a spell in a room, it should affect the targets in that room. Not move with you. At least that's my view.


The way it works in this way will only depends on how the skill is coded, the engine has not a lot to do with it.
The engine can help with tools to ensure the loop works fine but then all is up to the coder.
20.0/108