PlaneShift
Gameplay => Wish list => Topic started by: novacadian on August 10, 2010, 07:14:04 pm
-
Hopefully this is not already something that is installed and has simply been overlooked by me....
So my guild and Alliance tabs are no longer showing and the chat bubbles have been removed yet all that goes on in those channels is still flooding my logs. This would not be a problem for me if it was IC yet it is not.
It would be wonderful if one could choose the tabs that they wish logged to the log file. Perhaps it could coincide with the Enable/Disable choice in the Chat Bubble Options; by just adding another one called Save to Log.
Without this feature my logs are becoming pretty useless and my participation in Guilds shall have to be reconsidered.
- Nova
-
Dare I ask what the point is in being a member of a Guild but not participating in Guild channel conversations? You might as well be an unofficial (not in the guild via mechanics) member.
-
You might not always want to have that chat in the logs./me remembers a guildie simply muting the guild channel when there was a lot of nonsense and she in a rp ;D
-
This would not be a problem for me if it was IC yet it is not.
I do not really get the idea of your argument. Would you consider logfiles to be "in character" at all?
Or is it a technical issue with the size of the logs and the difficulty to find things you would like to look up? In that case, just split, filter and/or compress the logs. This should be straight forward with plain text files.
-
This would not be a problem for me if it was IC yet it is not.
I do not really get the idea of your argument. Would you consider logfiles to be "in character" at all?
Or is it a technical issue with the size of the logs and the difficulty to find things you would like to look up? In that case, just split, filter and/or compress the logs. This should be straight forward with plain text files.
Its not meant as an argument, Boni. It is mostly with difficulty finding things and when they are found to then extract them from the flle. It is not how I use the logs. When I have an interesting session with a character I make a sub-directoy and cut and past that encounter to its own file and place it in that character's sub-directory. The spam in my logs makes this a very time consuming job to cut out the actual encounter.
Dare I ask what the point is in being a member of a Guild but not participating in Guild channel conversations? You might as well be an unofficial (not in the guild via mechanics) member.
Did medieval guilds have guild channels that they could talk across the continent to one another? Modern ones do. Its called a cell phone. The present situation would be ok to me if the chatter was at least IC. It it not. Or if the ooc chatter used brackets. It is not. My logs are showing more non square bracket marked chatter than RP. I cannot even run a grep excluding all lines of the log which have a square bracket. My logs could easily be purged of the ooc stuff that way; yet alas square brackets are not used in the Guild or Alliance channels which are being logged.
Presently my character's participation in her guild is to further the word and teachings of Talad. For that reason she had turned down invites to DoX and the Rangers. She is presently trying to organize a ceremony for Talad at the Gug Temple followed by a wine and cheese party to be followed by a full banquet at the Stonehead with a free flea market of donations of previously enjoyed items. Tonight she took out a less developed guild member on a hunt to tank for them on Eagle Gobbles which they would have been all day with on their own. They leveled up nicely on the hunt. Things like that is what being a member of a guild means to me.
If you consider being a good guild member as following ooc chatter on the guild channel then we have different opinions of what a guild should be used for. That is just my personal opinion and meant as not disrespect to yours.
- Nova
-
Can't you filter out any lines with "Guild" and "Alliance" in it. Though occasionally you'd get IC lines ripped out by such a filter, but it's a start.
The channels are there for OOC co-ordination mostly.... believe it or not most guilds cannot function completely and organize events without OOC planning and on-the-moment OOC decision making... ie: at such and such an event (a Taladian religious ceremony, for example) such and such does not work as planned due to an OOC factor (someone crashes perhaps, and they are a 'torch carrier' or something important, and they cannot relog, perhaps). Guild channel is used to come up with a quick workaround to this OOC problem.
Perhaps, you could ask the other members of the Guild to cut OOC chatter to a minimum. If it's that bad of a problem.
-
Here is a thread about a short python-script "logcleaner (http://www.hydlaaplaza.com/smf/index.php?topic=32218.0)", which provides with easy and simple means to clean logs from defined junk. As it is now guildchat, tells and groupchat is removed from logs processed (also the timecode and OOC-stuff defined by "[", but its really easy to modify everything to your need].
-
grep -v "\[Guild\]\|\[NPC\]\|\[Tell\]\|\[Group\]" <charname>_chat.txt
-
Can't you filter out any lines with "Guild" and "Alliance" in it. Though occasionally you'd get IC lines ripped out by such a filter, but it's a start.
Is that not what the wish is asking of the game mechanics?
The channels are there for OOC co-ordination mostly.... believe it or not most guilds cannot function completely and organize events without OOC planning and on-the-moment OOC decision making... ie: at such and such an event (a Taladian religious ceremony, for example) such and such does not work as planned due to an OOC factor (someone crashes perhaps, and they are a 'torch carrier' or something important, and they cannot relog, perhaps). Guild channel is used to come up with a quick workaround to this OOC problem.
During such times the tab could be turned back on through game mechanics; yet it would still not be wanted in the logs; so having both separately configurable would allow that.
Perhaps, you could ask the other members of the Guild to cut OOC chatter to a minimum. If it's that bad of a problem.
It has been requested and turned down. After making the request it became clear to me that decision was a valid one for two reasons.
1) Without that release valve we would probably see a lot more ooc in tells and main.
2) That aspect of player to player communication is important to many and should not be taken away from their enjoyment. Perhaps without that player to player communication many would find it hard to develop IC bonds between characters; bonding being an important aspect to guilds.
Here is a thread about a short python-script "logcleaner (http://www.hydlaaplaza.com/smf/index.php?topic=32218.0)", which provides with easy and simple means to clean logs from defined junk. As it is now guildchat, tells and groupchat is removed from logs processed (also the timecode and OOC-stuff defined by "[", but its really easy to modify everything to your need].
Thanks, but is that not what the wish is asking of the game mechanics? If someone would go to such lengths as to code a stript to do it, does that not justify the wish? What about players that support the wish yet have no technical abilities?
grep -v "\[Guild\]\|\[NPC\]\|\[Tell\]\|\[Group\]" <charname>_chat.txt
The -v options is known to me. That would not allow the option of turning the logging on and off but simply clean out all incidences of Guild and Alliance entries. A guild war, for example, may want to be logged for IC reasons.
The strong reaction to my request makes me wonder if it is a technical issue or a political one.
- Nova
[Edit - Just out of interest this is what my logs look like. The last one dated 081110 is since the guild was joined. IT should be clear to those familiar with the ls output the relation of ooc to ic entries that is going on. My estimate is 3:1.
-rw-rw-r--. 1 booner booner 187276 Jun 29 15:57 Venorel_Weruno_chat_062910.txt
-rw-rw-r--. 1 booner booner 270092 Jul 3 07:55 Venorel_Weruno_chat_070310.txt
-rw-rw-r--. 1 booner booner 310981 Jul 5 16:26 Venorel_Weruno_chat_070510.txt
-rw-rw-r--. 1 booner booner 302442 Jul 9 14:23 Venorel_Weruno_chat_070910.txt
-rw-rw-r--. 1 booner booner 0 Jul 13 11:52 Venorel_Weruno_chat_071310.txt
-rw-rw-r--. 1 booner booner 702881 Jul 18 01:11 Venorel_Weruno_chat_071810.txt
-rw-rw-r--. 1 booner booner 363914 Jul 23 05:19 Venorel_Weruno_chat_072310.txt
-rw-rw-r--. 1 booner booner 478140 Jul 28 03:51 Venorel_Weruno_chat_072810.txt
-rw-rw-r--. 1 booner booner 308519 Aug 1 04:16 Venorel_Weruno_chat_080110.txt
-rw-rw-r--. 1 booner booner 316987 Aug 5 03:48 Venorel_Weruno_chat_080510.txt
-rw-rw-r--. 1 booner booner 1042164 Aug 11 05:57 Venorel_Weruno_chat_081110.txt
P.S. In case you are wondering the log of 071310 was hit with 'echo -n > Venorel_Weruno_chat_071310.txt' by mistake. :(
]
-
Are you asking that the Guild and Alliance channels have toggle buttons in the UI that prevent those messages from going to the logs? Or are you asking for the client to filter OOC comments out of the logfiles?
Technically speaking, this is not game mechanics, it is client functionality. You are asking that on-the-fly GREP and text-editing capability be added to the client to come into play when the log information is getting processed and dumped to the disk, toggles for different channels, and that interface objects be added to allow control of that in the UI.
The issue of post-processing text is something that is really best handled outside of the client. I have written scripts or used BBedit to do this, as has everyone else. And, I mean, why stop with just these functions? Wouldn't it be even better if it used an exist CSS and formatted the log entries in a visually pleasing manner as well?
Thats what the script I wrote did. But I didn't consider a lack of these features to be a detraction to PlaneShift itself. And the fact that many people have coded these workarounds may justify the wish, but its not going to magically free up the resources/people and the time that would have to go into making it.
Better yet would be to add GREP strings to a program like Text Wrangler and just process the files afterwards and retain copies of your originals. Anyone who has been playing this game for a while has tons of logfiles with all kinds of extra stuff in them. We all spend a lot of time editing logs, but I would rather that the team concentrated on game functionality and mechanics, rather than making a text editor.
-
Are you asking that the Guild and Alliance channels have toggle buttons in the UI that prevent those messages from going to the logs? Or are you asking for the client to filter OOC comments out of the logfiles?
The former.
Technically speaking, this is not game mechanics, it is client functionality. You are asking that on-the-fly GREP and text-editing capability be added to the client to come into play when the log information is getting processed and dumped to the disk, toggles for different channels, and that interface objects be added to allow control of that in the UI.
The code still sits unexplored by me on my disk; with all my PS time being dedicated to game play at the moment. That being said allow me to make the leap to assume that as the channels are already being handled individually (able to turn many aspects of them on and off) that adding the non-logging feature would not be a huge leap.
Instead of calling it game mechanics or client functionality let's just call it a wish.
The issue of post-processing text is something that is really best handled outside of the client.
At the moment it is the only way. How nice to not have to ever leave the client and know what you want to be saved is being saved and what you don't want saved is not being saved.
I have written scripts or used BBedit to do this, as has everyone else.
That seems to reinforce the need for those who feel the same as me yet have no technical know how.
And, I mean, why stop with just these functions? Wouldn't it be even better if it used an exist CSS and formatted the log entries in a visually pleasing manner as well?
Sarcasm? Otherwise.... sure.
Thats what the script I wrote did. But I didn't consider a lack of these features to be a detraction to PlaneShift itself. And the fact that many people have coded these workarounds may justify the wish, but its not going to magically free up the resources/people and the time that would have to go into making it.
Guess, to me, it does not appear to be the coding nightmare which you suggesting. Allow me the option of being corrected on that.
Better yet would be to add GREP strings to a program like Text Wrangler and just process the files afterwards and retain copies of your originals. Anyone who has been playing this game for a while has tons of logfiles with all kinds of extra stuff in them. We all spend a lot of time editing logs, but I would rather that the team concentrated on game functionality and mechanics, rather than making a text editor.
Again, to me, you seem to only be reinforcing the need for the wish
- Nova
-
Here is a thread about a short python-script "logcleaner (http://www.hydlaaplaza.com/smf/index.php?topic=32218.0)", which provides with easy and simple means to clean logs from defined junk. As it is now guildchat, tells and groupchat is removed from logs processed (also the timecode and OOC-stuff defined by "[", but its really easy to modify everything to your need].
Thanks, but is that not what the wish is asking of the game mechanics? If someone would go to such lengths as to code a stript to do it, does that not justify the wish? What about players that support the wish yet have no technical abilities?
Hm, I am not really agreeing. Those days I had to process loads of logs to extract the story played only, and neither I think that could work automatedly nor I do think things like the timecode should be left out.
Aiw, you make me aware of the meanwhile altered format of that log-content. Those prefixes to indicate the originated channels make filtering much more easy - even though I consider your command more advanced and not something everybody would think of themselves, let alone its a linux command.
-
grep -v "\[Guild\]\|\[NPC\]\|\[Tell\]\|\[Group\]" <charname>_chat.txt
The -v options is known to me. That would not allow the option of turning the logging on and off but simply clean out all incidences of Guild and Alliance entries. A guild war, for example, may want to be logged for IC reasons.
The strong reaction to my request makes me wonder if it is a technical issue or a political one.
Sorry, was really only a suggestion how to deal with it. I usually like it better to have all available information in my logs (an that includes even stupid OOC crap) and choose afterwards what I want to look at. That's why I prefer the grep method which doesn't touch my original logs at all and keeps all infos in them. Who knows what funny flame tells I may get that are worth posting in the OL forums for the enjoyment of others if I have my logging for tells turned off. ;)
Oh..and just because I am too stupid to get it...how can anything in guildchat or alliancechat be IC at all?
But I agree that sometimes an option to choose more precisely what to log would be nice. Not really hard to do at all. It would only need a few additions in the src/client/gui/chatwindow.cpp file. In the pawsChatWindow::LoadChatSettings() it could be loaded from the chat.xml file what channels should be logged. Something like this would do the trick:
...
else if (nodeName == "LogNPCChat")
settings.logNPCChat = option->GetAttributeValueAsBool("value", true);
else if (nodeName == "LogGuildChat")
settings.logGuildChat = option->GetAttributeValueAsBool("value", true);
else if (nodeName == "LogGroupChat")
settings.logGroupChat = option->GetAttributeValueAsBool("value", true);
else if (nodeName == "LogTellChat")
settings.logTellChat = option->GetAttributeValueAsBool("value", true);
else if (nodeName == "LogAllianceChat")
settings.logAllianceChat = option->GetAttributeValueAsBool("value", true);
else if (nodeName == "LogHelpChat")
settings.logHelpChat = option->GetAttributeValueAsBool("value", true);
else if (nodeName == "LogChannelChat")
settings.logChannelChat = option->GetAttributeValueAsBool("value", true);
...
The pawsChatWindow::SaveChatSettings() would of course also need some adjusting to write back the values in the xml file:
...
npcChatLogNode = optionNode->CreateNodeBefore(CS_NODE_ELEMENT,0);
npcChatLogNode->SetValue("LogNPCChat");
npcChatLogNode->SetAttributeAsInt("value",(int)settings.logNPCChat);
guildChatLogNode = optionNode->CreateNodeBefore(CS_NODE_ELEMENT,0);
guildChatLogNode->SetValue("LogGuildChat");
guildChatLogNode->SetAttributeAsInt("value",(int)settings.logGuildChat);
groupChatLogNode = optionNode->CreateNodeBefore(CS_NODE_ELEMENT,0);
groupChatLogNode->SetValue("LogGroupChat");
groupChatLogNode->SetAttributeAsInt("value",(int)settings.logGroupChat);
tellChatLogNode = optionNode->CreateNodeBefore(CS_NODE_ELEMENT,0);
tellChatLogNode->SetValue("LogTellChat");
tellChatLogNode->SetAttributeAsInt("value",(int)settings.logTellChat);
allianceChatLogNode = optionNode->CreateNodeBefore(CS_NODE_ELEMENT,0);
allianceChatLogNode->SetValue("LogAllianceChat");
allianceChatLogNode->SetAttributeAsInt("value",(int)settings.logAllianceChat);
helpChatLogNode = optionNode->CreateNodeBefore(CS_NODE_ELEMENT,0);
helpChatLogNode->SetValue("LogHelpChat");
helpChatLogNode->SetAttributeAsInt("value",(int)settings.logHelpChat);
channelChatLogNode = optionNode->CreateNodeBefore(CS_NODE_ELEMENT,0);
channelChatLogNode->SetValue("LogChannelChat");
channelChatLogNode->SetAttributeAsInt("value",(int)settings.logChannelChat);
...
The struct ChatSettings in the chatwindow.h file had to be expanded:
...
bool logNPCChat;
bool logGuildChat;
bool logGroupChat;
bool logTellChat;
bool logAllianceChat;
bool logChannelChat;
...
The pawsChatWindow::LogMessage method would need some logic to detemine if this message should be logged at all:
...
if ((((type == CHAT_NPC) || (type == CHAT_NPC_ME) || (type == CHAT_NPC_MY)) && !settings.logNPCChat) ||
((type == CHAT_GUILD) && !settings.logGuildChat) || ((type == CHAT_GROUP) && !settings.logGroupChat) ||
((type == CHAT_TELL) && !settings.logTellChat) || ((type == CHAT_ALLIANCE) && !settings.logAllianceChat) ||
(((type == CHAT_ADVISOR) || (type == CHAT_ADVICE)) && !settings.logHelpChat) ||
((type == CHAT_CHANNEL) && !settings.logChannelChat)) return;
...
With this you could already change the logging behaviour when editing the text files and restarting the game. But I guess not what you wanted so pawsconfigchat.h and pawsconfigchat.cpp had to be edited also to enable some check boxes for what to log.
pawsconfigchat.h:
...
pawsCheckBox* logNPCChat;
pawsCheckBox* logGuildChat;
pawsCheckBox* logGroupChat;
pawsCheckBox* logTellChat;
pawsCheckBox* logAllianceChat;
pawsCheckBox* logChannelChat;
...
pawsconfigchat.cpp / pawsConfigChat::pawsConfigChat():
...
logNPCChat = NULL;
logGuildChat = NULL;
logGroupChat = NULL;
logTellChat = NULL;
logAllianceChat = NULL;
logChannelChat = NULL;
...
pawsconfigchat.cpp / pawsConfigChat::PostSetup():
...
logNPCChat = (pawsCheckBox*)FindWidget("lognpcchat");
logGuildChat = (pawsCheckBox*)FindWidget("logguildchat");
logGroupChat = (pawsCheckBox*)FindWidget("loggroupchat");
logTellChat = (pawsCheckBox*)FindWidget("logtellchat");
logAllianceChat = (pawsCheckBox*)FindWidget("logalliancechat");
logChannelChat = (pawsCheckBox*)FindWidget("logchannelchat");
...
pawsconfigchat.cpp / bool pawsConfigChat::LoadConfig()
...
logNPCChat->SetState(settings.logNPCChat);
logGuildChat->SetState(settings.logGuildChat);
logGroupChat->SetState(settings.logGroupChat);
logTellChat->SetState(settings.logTellChat);
logAllianceChat->SetState(settings.logAllianceChat);
logChannelChat->SetState(settings.logChannelChat);
...
pawsconfigchat.cpp / bool pawsConfigChat::SaveConfig()
...
settings.logNPCChat = logNPCChat->GetState();
settings.logGuildChat = logGuildChat->GetState();
settings.logGroupChat = logGroupChat->GetState();
settings.logTellChat = logTellChat->GetState();
settings.logAllianceChat = logAllianceChat->GetState();
settings.logChannelChat = logChannelChat->GetState();
...
and at last you had to put the checkboxes, their positions and text in "data/gui/configchat.xml"
adding some lines like:
<widget name="lognpcchat" factory="pawsCheckBox">
<frame x="xxxx" y="yyyy" width="wwww" height="20" />
<text string="Log NPC-chat to file" />
</widget>
<widget name="logguildchat" factory="pawsCheckBox">
<frame x="xxxx" y="yyyy" width="wwww" height="20" />
<text string="Log Guild-chat to file" />
</widget>
<widget name="loggroupchat" factory="pawsCheckBox">
<frame x="xxxx" y="yyyy" width="wwww" height="20" />
<text string="Log Group-chat to file" />
</widget>
<widget name="logtellchat" factory="pawsCheckBox">
<frame x="xxxx" y="yyyy" width="wwww" height="20" />
<text string="Log tells to file" />
</widget>
<widget name="logalliancechat" factory="pawsCheckBox">
<frame x="xxxx" y="yyyy" width="wwww" height="20" />
<text string="Log Alliance-chat to file" />
</widget>
<widget name="logchannelchat" factory="pawsCheckBox">
<frame x="xxxx" y="yyyy" width="wwww" height="20" />
<text string="Log Channel-chat to file" />
</widget>
The xxxx, yyyy, wwww had to be replaced with useful value of course...
So, no it's no problem to include this in game at all..also not in a way that doesn't annoy anyone as they can keep exactly the behavior they have right now and only get some more options. But of course you won't get this..some dev will come up with a stupid reason why there is no time to do this and that there are more important things that need to be done. Next time better ask for a change that adds some colorful effect or something else that attracts more noobs to the game..you have a much higher chance to get something like this implemented than asking for something that actually could be useful. But stay for some time and you will find this out on your own. And don't listen to people like Akkaido...almost every post of him is just about telling others why they don't need what they ask for instead of giving it any thought at all. But that attitude makes him a prefect candidate for the PS team.
Edit:
- Added one line
- Typos
-
On a sidenote:
Dont discourage Akkaido/ Xoel to post whatever stuff, I love it! :P
-
not sure whether it helps you, but there used to be a log viewer (http://hydlaaplaza.com/smf/index.php?topic=32274.0) which worked quite well for sorting stuff - maybe it could be revived?
I suppose that'd be a lot more useful than being able to just enable/disable logging of certain tabs (which can easily be removed via regex, anyway)
-
http://en.wikipedia.org/wiki/Reading_(process) (http://en.wikipedia.org/wiki/Reading_(process))
Here is a thread about a short python-script "logcleaner (http://www.hydlaaplaza.com/smf/index.php?topic=32218.0)", which provides with easy and simple means to clean logs from defined junk. As it is now guildchat, tells and groupchat is removed from logs processed (also the timecode and OOC-stuff defined by "[", but its really easy to modify everything to your need].
Thanks, but is that not what the wish is asking of the game mechanics? If someone would go to such lengths as to code a stript to do it, does that not justify the wish? What about players that support the wish yet have no technical abilities?
grep -v "\[Guild\]\|\[NPC\]\|\[Tell\]\|\[Group\]" <charname>_chat.txt
The -v options is known to me. That would not allow the option of turning the logging on and off but simply clean out all incidences of Guild and Alliance entries. A guild war, for example, may want to be logged for IC reasons.
-
http://en.wikipedia.org/wiki/Reading_(process) (http://en.wikipedia.org/wiki/Reading_(process))
ROFL, thats what I meant! Glad to see you back on fire, Aiw! \\o//
-
http://en.wikipedia.org/wiki/Reading_(process)
And you thought I was being sarcastic.
Edit: Sorry Phage, I removed my sarcastic remark to try and keep to the point. I think Nova may have gotten the point about sarcasm by now.
Seriously, Nova, its not that its a bad idea, its just not as simple as one would think it would be. Add a very basic feature request to the bug tracker for this.
-
[..]
what good the "code sitting unexplored on your disk" does if you don't have enough technical know-how to implement a script or even run a GREP search-and-replace in an editor?
If nothing else, you could still look up any jerk having bragged in tells about his IQ.
-
Without looking at the details of an individual's specific ways of playing, I'd support any request that improves the flexibility of the game interface.
Besides, if I understood correctly, this request here concerns only the client code; so it could be picked up and coded by someone outside of the dev. team, then submitted when done. If so, let someone add an official green light in the bugtracker's comments and the thing may be implemented faster than expected...
-
Aiwendil, you have given me a great head start for playing with the code when my PS addiction tones down to a dull roar. ryldontknow you have offered a very practical solution in the meantime.
My thanks to you both!
- Nova
-
lol...you think so khoridor?
http://bugs.hydlaaplaza.com/flyspray/index.php?do=details&task_id=3967 (http://bugs.hydlaaplaza.com/flyspray/index.php?do=details&task_id=3967)
http://bugs.hydlaaplaza.com/flyspray/index.php?do=details&task_id=4189 (http://bugs.hydlaaplaza.com/flyspray/index.php?do=details&task_id=4189)
Both posted in march.
-
you still didn't post a proper diff :P
trying to find something in an odd paste is a pain Aiwendil ;)
and for the other... has to be decided by someone whether it shall be done at all
-
Brings me back to my questions about svn diff....
How do I make a svn diff for a file that wasn't in svn before?
How do I get svn diff to not include whitespace changes?
-
Yes, a very cool thing died with the unanswered question how to make that patch :-\
I personally can't evaluate how much effort it would be to implement the already existing code in the svn, but I would have thought that it's only minutes? Saying that because I know a couple of players who stopped to care about planeshift and left, because their pretty much ready contributions seem to have been simply ignored.
Sen
-
Brings me back to my questions about svn diff....
How do I make a svn diff for a file that wasn't in svn before?
How do I get svn diff to not include whitespace changes?
cd into your planeshift directory
svn add all files you added
svn diff
paste the output on pastebin/codepad/whatever
for whitespace changes: just don't do them :P
-
src/client/psengine.h
http://pastebin.com/rVut2mcT (http://pastebin.com/rVut2mcT)
src/client/psengine.cpp
http://pastebin.com/2QG7FpYE (http://pastebin.com/2QG7FpYE)
src/client/autoexec.h
http://pastebin.com/1aTbX4pu (http://pastebin.com/1aTbX4pu)
src/client/autoexec.cpp
http://pastebin.com/SqZMWgi4 (http://pastebin.com/SqZMWgi4)
Looks for me same as the stuff I pasted in the bugtracker already...except that I pasted a copy of the complete files and not a patch to an empty file with only "+" lines. And sorry, can't be arsed to update my sourceode to any newer revison...or remove all the other hacks I added to make a complete svn diff.
Edit:
For the whitespaces...seems a "svn diff --diff-cmd diff -x -uw /path/to/file" does the trick.
-
lol...you think so khoridor?
http://bugs.hydlaaplaza.com/flyspray/index.php?do=details&task_id=3967 (http://bugs.hydlaaplaza.com/flyspray/index.php?do=details&task_id=3967)
http://bugs.hydlaaplaza.com/flyspray/index.php?do=details&task_id=4189 (http://bugs.hydlaaplaza.com/flyspray/index.php?do=details&task_id=4189)
Both posted in march.
Yes I do. Am I naive? :)
Well, you submitted request and code at the same time, so I'd expect approval of the idea to take longer, but with simultaneous code integration, basically closing the request with the approval (if approved of course).
I've also seen months passing before a first comment is made on a request. Makes sense to me for "low" severity.
That plus the many reasons why some code could be disapproved... But at the end of the day, I'd still be optimistic.
This is also why I mentioned a green light comment earlier. Something that comes after a request has been approved, telling that the team puts no priority on it, and that it is open game for outside submissions. Something that is also easy to search in the tracker, for coders who could help on small tasks but wouldn't know where.
Then, to avoid wasting devs time, the code could be submitted on the forum, reviewed by other volunteers and freelances, until it is found acceptable for actual submission. Such process is still slow, but at least it would preserve the motivation of the participants.
-
Yes I do. Am I naive? :)
Sorry...impossible for me to say no here.
But I know...I was already told to not waste precious developers time with some stupid patches so not really a problem at all anymore. I already stopped submitting patches. ;)
-
This is also why I mentioned a green light comment earlier. Something that comes after a request has been approved, telling that the team puts no priority on it, and that it is open game for outside submissions. Something that is also easy to search in the tracker, for coders who could help on small tasks but wouldn't know where.
if you're looking for such tasks - the prospect ones are exactly that. they usually don't require deep knowledge, but are a bit tedious to do and not high priority. (search for those with status "prospect task" on the bugtracker)
as for yours Aiwendil - reviewing them takes a bit time - especially with feature requests
FRs have to be approved by a leader or even a director
additionally submissions have to be reviewed with regards to code-style, doing it "the right way", etc.
-
Well, you submitted request and code at the same time, so I'd expect approval of the idea to take longer, but with simultaneous code integration, basically closing the request with the approval (if approved of course).
I've also seen months passing before a first comment is made on a request. Makes sense to me for "low" severity.
That plus the many reasons why some code could be disapproved... But at the end of the day, I'd still be optimistic.
as for yours Aiwendil - reviewing them takes a bit time - especially with feature requests
FRs have to be approved by a leader or even a director
additionally submissions have to be reviewed with regards to code-style, doing it "the right way", etc.
Yeah, got it by now. Submitting code is a bad idea as it would been much faster to only review a feature request and discard or accept it and then have the dev-team write the proper code for it. When a feature request that already includes code is submitted the reviewing of only the feature idea takes much longer as it depends also on the code submitted and is maybe rejected in total because of coding style issues or other problems with the source-code. In the end submitting code has the contrary effect of what is was meant for...it makes it harder and is no help at all. It doesn't help at all to get features implemented faster the PS team gives low priority but which some players would like to have nonetheless. If you want to submit code the best way is just to become a PS prospect...and then work on the tasks that are given to you instead of what you think would be nice to include in the game. If you don't want to get in the PS team better stay with submitting only the ideas of feature requests as this might get them faster (if accepted) in game than if there was already a suggestion how to include it in the code along with the idea. It seems I have to apologize to LigH for coming up with patches for his scriptable login idea as this made it far more unlikely to get implemented soon.
I guess I am the only one who sees a problem with this feature request-workflow for a opensource project.
-
Don't get sarcastic and take it all wrong -.-
the review of the code isn't related to the approval of the feature request at all
if there's something wrong with the code, it'll be tweaked straight away or you'll be asked to fix the issues.
-
Don't get sarcastic and take it all wrong -.-
Ahm...two years too late for that.
But for the rest, true you didn't state explicitly that the approval of the feature request and the review of the code are related.
additionally submissions have to be reviewed with regards to code-style, doing it "the right way", etc.
So this sentence has to be taken like: "First it needs time to get a word of some higher-ups if this is wanted at all and then it takes additional time to review the submitted code"? That doesn't really change much about what I said before. For the rest of that comment:
The point is that unless otherwise directed by the team, the packaged distro client is what should be used with our servers. If you want to try to improve the client, build your own server and test it on your own, and submit it to a dev for consideration if it fixes a bug or enhances a feature to benefit the entire player base. You'd be encouraged to discuss your intent with a dev first to avoid wasting your time (and ours), and you probably should consider applying to the team at contributor or prospect level to get a more clear understanding of the development process and direction.
So what I said still stands...if you submit code it will take longer and you better apply for the team if it should be included in the game.
-
So what I said still stands...if you submit code it will take longer and you better apply for the team if it should be included in the game.
not at all. put aside prospects choose their tasks themselves, too, there's no difference whether you're a team member or not.
the FR still has to be approved first and the code still has to be reviewed
-
My experience of QC (Quality Control) with even simple LPC on MUDs is a process that takes time and is often not appreciated by those submitting. Both sides of the equation are understandable. The fact is, though, that good QC is required for quality software development. Just the nature of the beast from my experience.
- Nova
-
My experience of QC (Quality Control) with even simple LPC on MUDs is a process that takes time and is often not appreciated by those submitting. Both sides of the equation are understandable. The fact is, though, that good QC is required for quality software development. Just the nature of the beast from my experience.
- Nova
Hint: that's what TDD/BDD techniques are for. After-the-fact QC measures are a poor substitute for a strong unit test framework.
-
Hint: that's what TDD/BDD techniques are for. After-the-fact QC measures are a poor substitute for a strong unit test framework.
even a strong unit test framework can't guarantee things are done properly (i.e. verify proper code style and it actually being placed in the right classes, etc.) nor can it approve FRs, it can just guarantee it works in the common/border cases ;)
-
For the original topic, I haven't played in a while so i am not all that current on chat logging options. But perhaps a chat logging inspired by Logging Frameworks would be good idea. For each channel you could give a number of destinations.
For example usage you have an allChannels.log, where messages of all channels are logged. You add guild.log to the guild channel and you add IC.log to guild, tell, chat and group. When you play Planeshift, all messages on the guild channel get added to allChannels.log, guild.log and IC.log. Tell messages get only added to IC.log and AllChannels.log. System messages only appear in AllChannels.log. Channels without any destination don't get logged at all.
A unit test framework helps to find implementations not working as the test writer understood the specification. It does not speed up arriving at the specification, nor does it guarantee the test implementation is correct for the specification. It only checks the working of an implementation, not the coding style. As the previous poster already said, coding style is beyond a unit test framework.
An implementation that looks like decompiled optimized object code will pass a unit test framework. But it should never pass quality control on any code base. There are various flavors of code that works, but shouldn't be accepted.