Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - beren

Pages: [1] 2
1
General / Re: wanting to loose this_player()
« on: March 02, 2016, 01:24:50 AM »
We are using a custom mudlib (none of the standard DS/LPUNi etc mudlibs since we are pretty old from 1991 and at that time I think only TMI existed) so have no idea what is the build-in map code you are referring tο
(even though I am curious so would not mind if you point me to the right direction)
And as I said from the very beginning it is a mapper for a GUI (MUDlet) not ingame.

As for the reset idea. Reset is not called every time a player enters a room and I want the mapper to update in real time as a player walks through the game.
At the moment I call the code through init() but that obviously carries the this_player() definition which is causing me the problems.


2
General / Re: wanting to loose this_player()
« on: February 28, 2016, 05:12:57 AM »
No that won't work. We don't give players the whole map.
The map for each player is updated in their GUI when they actually enter the room.
So they start with a blank and they slowly build it up.
It is even a "quest" and a very sought after ranking for which player has actually mapped or explored most of the world and has found most of the hidden places.

As for the custom exits you misunderstand. Most rooms use a standard mechanism that they inherit from a base room object.
That is only overriden when a coder wants to do something special with that exit.
I would guess only something like 5-7% of rooms have such overrides but we would still need to actually lookup every single room file (that is where the 10.000+ number comes in)
if we attempted to standardize how the override is done to accomodate how we update the mapper.
That was one of the solutions I considered but has the downside of actually having to search through 10.000 files and update a few hundred.

3
General / Re: wanting to loose this_player()
« on: February 27, 2016, 09:41:05 AM »
Also you seem to misunderstood.
My problem is not how the exit functions are working. They are working as they should for play.

My problem is that I actually want to evaluate those functions to send the proper data to the mapper through GMCP.
Otherwise ofcourse this_player() should be actually defined.

Anyways it was a long shot.

4
General / Re: wanting to loose this_player()
« on: February 27, 2016, 09:28:14 AM »
Changing how exits work is easier said than done.
With 10k+ unique rooms a lot of them do have such functions so we would need to go through them one by one.
Not practical at all.

That is why I was asking if there was this particular solution achievable some how.
I have a couple more ideas how to circumvent the problem
but all of them have their own unique problems.

5
General / Re: wanting to loose this_player()
« on: February 26, 2016, 12:00:19 PM »
OKs maybe I should explain a bit better what I am trying to do :

I have enabled GMCP and when a player enters a room I send through GMCP info about that room including the exits and an id of the destination of room of each exit so as to build a map in our custom GUI.
In most cases that is not a problem but some exits are defined as
set_exits([ "north" : "@@some_function@@" ])

The function may do a check on lvl/guild/whatever and return a valid exit or deny but in most cases it just gives some message to the player when he moves in that direction or it might do some action on the player.

If I use something like process_string(some_function)  (to get the room id to send through GMCP) because this_player is defined whatever message, or more worryingly, action is defined in there will be performed on the player object even before he moves towards that exit.
At the moment I just ignore exits like that but it causes the mapper to fail in some rather popular areas and I would like to try and find a solution for this.

6
General / wanting to loose this_player()
« on: February 26, 2016, 10:01:17 AM »
I have come up with a situation where I want to loose this_player()
ie I don't want it to return the player object that has caused this particular function to have been called (it can return zero)

Is there a way to actually cause this ?
I have  this_player_in_call_out defined so that little trick can't work.


7
General / Re: Lag Debugging
« on: January 06, 2015, 03:00:23 AM »
Will try that even though I am not certain it will work.

Apart from things happening on heartbeat we have dozen call outs that not always happen on heartbeat intervals doing a variety of things that might be causing some of the lag.
Was hoping that there was a way that the driver kept an in memory log of things executed last heartbeat so I would just dump those into a file when I noticed the lag.

Thanks for the pointer though

8
General / Lag Debugging
« on: January 05, 2015, 04:53:39 AM »
I am using the latest version of FluffOS from github on a Centos7 64bit VM. (finally moving away from cygwin)
We are on a 2 second heartbeat but on occasions the interval between heartbeats is 4 or 6 seconds due to some commands taking longer to complete.

I managed to pin point and correct a few problems but on occasion we still get these small lag occurrences.

Is there a way to determine which commands were executed by the driver during the previous heartbeat ?
If I enable the LPC debug on the driver the driver lags almost constantly as it attempts to write all the commands to the debug.log or stdout so
that was not very useful.
Any other ideas ?

9
Drivers / Re: Latest FluffOS under cygwin errors
« on: October 27, 2014, 09:52:09 AM »
Yes cygwin is horrible and real developers use butterflies and all that jazz BUT sometimes you do have to work with the tools you are given even if you hate them.

The problem is that crypt and crypt.h are where they always were in cygwin.
Previous versions of FluffOS still compile and run with out such problems (on the same machine the latest version fails)
and as far as I could see nothing changed concerning crypt that should cause the problem and yet the compile errors exist.

Anyways will go through the code again and see if I can fix it.



10
Drivers / Latest FluffOS under cygwin errors
« on: October 26, 2014, 03:40:14 AM »
Under cygwin (64 & 32 bit alike) I get the following error

In file included from std.h:20:0,
                 from efuns_port.cc:10:
efuns_port.cc: In function ‘void f_oldcrypt()’:
macros.h:186:34: error: ‘crypt’ was not declared in this scope
 #define OLDCRYPT(x, y) crypt(x, y)
                                  ^
macros.h:159:43: note: in definition of macro ‘string_copy’
 #define string_copy(x, y) int_string_copy(x)
                                           ^
efuns_port.cc:68:21: note: in expansion of macro ‘OLDCRYPT’
   res = string_copy(OLDCRYPT(sp->u.string, salt), "f_crypt");

under linux (fedora) it compiles without problems so I suppose this is something cygwin specific.
Any ideas why this should be ?

11
Drivers / Re: FluffOS 3.0-alpha8 and clean_up
« on: January 15, 2014, 12:27:26 AM »
Interesting.

What are the compile options for FluffOS you are using ?
Which inherited object contains the code for clean_up in your mudlib ?

12
Drivers / Re: FluffOS 3.0-alpha8 and clean_up
« on: January 14, 2014, 03:52:41 AM »
According to my tests most objects had flag values > 1 even though nothing inherited them.

The objects that were heavily inherited like baseroom or baseobject etc had real big values of over 200 but
I could not easily detect a pattern to use to execute clean_ups.

In our previous driver which was MudOS with a few customizations it worked as you describe.

13
Drivers / Re: FluffOS 3.0-alpha8 and clean_up
« on: January 14, 2014, 12:34:30 AM »
We do use reset or call_outs for most in game mechanics (ie food going bad, monsters or objects respawning in rooms etc)
and clean_up was used for what it was meant to be ie unloading objects from memory to save memory.
Checked today after the MUd running for 4 days and we were at  200+ Mb or RAM which is not a huge problem really.

Now it might have been an unintended consequence  of the clean_up where rooms that were not visited for quite some time
(our time to clean up was 2hours) were unloaded from memory but now with rooms effectively staying for ever in memory it
causes certain issues that are annoying for players.

To explain an unpleasant senario in our particular MUd :
Consider a string of rooms that lead to a "boss" mob. When the rooms load the first time a player visits them after boot (happens ever 5 days for us)
they are populated each by mobs that guard the way and a player knows that he has 60mins before the next reset is called to get to the
boss before the rooms are populated again.

With clean_ups happening ever 2 hours and because those rooms are rarely visited after 2 hours those rooms unloaded and when a player visited them
for example 12h later all was as described above.

Now that the rooms don't unload from memory depending on the exact part of the reset cycle you visit those rooms you will find yourself with mobs
appearing all around when you expected none.

Since that was how the game mechanics worked (for 23years) players and wizards coding areas always had that in mind when designing.

I understand that clean_up was used to save memory which we have more than plenty atm but as you see it has other consequences as well
even if they are unintended.

14
Drivers / Re: FluffOS 3.0-alpha8 and clean_up
« on: January 13, 2014, 08:35:35 PM »
Well I would expect that it is 0 for most items and either 1 or non zero just for the items that are inherited. 

Fired up our old MudOS driver in a test machine and that seems that was the behavior.

As it stands at, the driver nearly always send non zero value for all loaded items which causes clean_up never to be called again for that item which defeats the purpose of clean_up.

15
Drivers / FluffOS 3.0-alpha8 and clean_up
« on: January 12, 2014, 11:45:26 PM »
I have moved our MUd (midnightsun2.org 3000) from MudOS to the latest version of FluffOS.
There have been a few glitches here and there with the code but only one thing (I have identified up to now)
that I would consider major considering the rather big change:
clean_up is not behaving as it was in MudOS or as the FluffOS documentation suggests.

The driver is supposed to pass the flag 1 in clean_up if the object is inherited.
FluffOS does not behave like that and I would like to know what is the logic behind the flags passed to clean_up.

I know DS uses a custom solution to manage clean_ups but ours is a completely custom mudlib and it will be quite hard to completely change all the logic
behind clean_ups.

Any help will be greatly appreciated.


Pages: [1] 2