[doktorbuzzo]

This is for @NilacTheGrim who asked about how one can post a crash log to the forum. The request for this info was initially misposted to a different bug thread.

Here's the info I provide and how I get it. I'm running Mac OS X as well.

1. The log_init.txt file has some information about things like the OS version, the Java version, system memory, graphics processor, etc. that help to explain the nature of the host computer. To retrieve log_init.txt, do the following:

• Open a Finder window.
• Go to the Applications folder (/Applications) or just press Shift-Command-A (??A), or go to the place where the mule application is installed on your system.
• You need to "Show Package Contents" for the mule application. Do this by either Control-clicking it and selecting "Show Package Contents" or you can use the "Action" menu button (the little gear-shaped icon near the center-top of the Finder window) to do so.
• The log files, including log_init.txt, are found in the "Contents > Resources > Java > data" folder (the Unix-style path is typically something like /Applications/mule.app/Contents/Resources/Java/data/log_init.txt ). You can copy the log_init.txt file to a different location if you want to upload it, or you can select & copy all of its contents to post them directly since it isn't a very large file.

2. The Mac OS X system will also generate a crash log every time a program crashes. You can find these handy text files (which typically are very large since they contain a lot of information) using the "Console" application, which is in your system's "Utilities" folder. To retrieve a crash report, do the following:

• Open a Finder window.
• Go to the Utilities folder (/Applications/Utilities) or just press Shift-Command-U (??U).
• Run the Console application.
• Crash reports are grouped into a category called "Diagnostic and Usage Information," which is one of the categories you'll see in the left panel of the Console app's main window.
• Crash reports from the Mac OS X mule application are generally named something like "java_2011-04-01_233539_zzzz.crash" since the mule app is a Java program. The rest of the filename is three strings that you can see will resemble a date ("2011-04-01"), a time ("233539," for 11:35:39 P.M. my local time) and the name of your computer ("zzzz" in my case).
• Locate the relevant crash report based on the time at which your mule program crashed. There may be a lot of crash reports to choose from but usually you can narrow things down by restricting your search to those starting with "java" and then looking at the date & time parts of the log file names.
• Once you've found your crash report, select it from the list on the left to see all of its text appear in the right side of the Console app's main window.
• To copy this text, you can just click your mouse in the text area and press Command-A (?A) to select all of the text. Then press Command-C (?C) to copy the text.
• Open any text editor, like "TextEdit."
• Click inside the editor's text area and press Command-V (?V) to paste the crash log file's contents. Save the file.
• The crash log will be too long to post to the Planet M.U.L.E. forum. What I'm able to do is to upload the saved copy of the log to one of my webpages I get for free from my ISP. You'll have to do something similar, or upload it to a filesharing service that others can read from. Once you've uploaded the file to the 'net, copy the link to it and paste that link into your bug report when you post to the forum.

Hope this helps,

doktorbuzzo

[doktorbuzzo]

Dammit! Again!

Game log: http://www.planetmule.com/hi-score-game/game?game_id=42008

Java crash log: http://bit.ly/gecwhJ

Please somebody have a look at this, it's the third time in a week that this crash behavior has happened to me.

It is definitely related to keyboard input for chatting.

Every time this has occurred it was when I was getting chirpy. I like chirpy. I'm a Flapper fer cryin' out loud! Chirp is what I do!

Tweet tweet,

doktorbuzzo

[doktorbuzzo]

Sigh.

Here's another similar crash report http://bit.ly/geEgQE from game http://www.planetmule.com/hi-score-game/game?game_id=41922. As before, the program on my computer crashed while I attempted to enter chat text.

What a bummer!

doktorbuzzo

[doktorbuzzo]

Rats.

Here's a game (still currently in progress as I report) that I just abandoned due to my P.M. program crashing as I typed chat text before my turn: http://www.planetmule.com/hi-score-game/game?game_id=41783. So very sorry, guys, I did not abandon, my sneaky computer done blowed up!

I think I've seen this before but I can't recall the game. It was recent, though, certainly when running the current P.M. version.

Here's a link to the Java crash report: http://bit.ly/i6QfQ2

Here's the text from my log_init file:

 INFO [Properties.<init>]                           VERSION: 1.3.4
  INFO [Properties.<init>]                           Classpath: data.jar
  INFO [Properties.<init>]                           Java VM: 19.1-b02-334
  INFO [Properties.<init>]                           Java Runtime: 1.6.0_24-b07-334-10M3326
  INFO [Properties.<init>]                           OS: Mac OS X 10.6.7 x86_64
  INFO [Properties.<init>]                           Java Library Path: lib
  INFO [Properties.<init>]                           Max Memory: 265093120
  INFO [Properties.<init>]                           Avaialble Processors: 2
  INFO [PropertiesBase.readFromFile]                 Reading Settings from file settings.txt
  INFO [SubstanceLoader.initLookAndFeel]             Window Skin: Default
  INFO [Main.main]                                   lpSolve: 5.5 Release 0 Build 15
  INFO [SoundPlayer.initialize]                      Initializing Sound System
  INFO [SlickLogSystem.info]                         Initialising sounds..
  INFO [SlickLogSystem.info]                         - Sound works
  INFO [SlickLogSystem.info]                         - 64 OpenAL source available
  INFO [SlickLogSystem.info]                         - Sounds source generated
  INFO [MasterClient.setServerAddress]               MasterClient: Address http://www.planetmule.com/server
  INFO [MasterClient.logSend]                        MasterClient: Sending Login
  INFO [MasterClient.apply]                          MasterClient: Session ID: 78983be3fb4289d2778df71e3c604244
  INFO [Login$MasterListener$1.run]                  Logged in as "doktorbuzzo" (id 17294)
  INFO [MetaFrame.<init>]                            Creating Meta Frame
  INFO [MapSkinParser.findSkins]                     No extra skins found
  INFO [MasterClient.logSend]                        MasterClient: Sending Enter Lobby
  INFO [Login.dispose]                               Disposing login
  INFO [Main.main]                                   Creating game container
  INFO [MuleGameContainer.<init>]                    LWJGL Version: 2.4.2
  INFO [MuleGameContainer.<init>]                    Desktop Display Mode: 1600 x 900 x 32 @0Hz
  INFO [MuleGameContainer.<init>]                    Current Display Mode: 1600 x 900 x 32 @0Hz
  INFO [MuleGameContainer.<init>]                    Display Adapter: null
  INFO [MuleGameContainer.<init>]                    Display Driver: null
  INFO [MuleGameContainer.setVSync]                  Setting vsync: true
  INFO [MuleGameContainer.<init>]                    Setting pixel format
  INFO [MuleGameContainer$1.run]                     Pixel format: Samples=0 Alpha=0 Depth=8 Stencil=0
  INFO [MuleGameContainer.<init>]                    GL Vendor: NVIDIA Corporation
  INFO [MuleGameContainer.<init>]                    GL Renderer: NVIDIA GeForce 320M OpenGL Engine
  INFO [MuleGameContainer.<init>]                    GL Version: 2.1 NVIDIA-1.6.26
  INFO [MuleGameContainer.<init>]                    GL Max Texture Size: null
  INFO [SlickLogSystem.info]                         Use Java PNG Loader = true
  INFO [MuleGameContainer.<init>]                    Display finished
  INFO [Main.main]                                   Entering game loop
 

I hope this helps track down & zap this nasty bug!

Thanks,

doktorbuzzo

P.S.: LOL yes, the text I was trying to type was indeed "uckfay."

I guess. To me, switching from fullscreen to chat-screen serves that purpose as a side-effect of making things in the game area easier to see with my tired old eyes.

Indeed.

I think a design is possible that can accommodate real-time data-hiding but that will allow for decryption by a knowledgeable administrator. Since events prior to the game's start don't require encryption, I think the combination of global data and local data in an unencrypted "frontmatter" portion of the machine log should be sufficient to enable an admin-level person or developer (who has the hashing function at hand) to decrypt logs from games that have not gone final.

LOL Am I reinventing the public-private encryption method?

What I like most about playing in fullscreen mode is the very clean presentation of the game's action.

Please do not clutter up my fullscreen view by making chat visible. I like having the ability to make chat invisible for as long as I wish.

I think adding an indicator to the status area to show which players are in fullscreen mode is a fine idea.

[Very Good Thing]

I agree with dynadan's objection to the overexposure of game history and upcoming events. If a player wants to record all observed game events (full disclosure: I manually chart everything and use the knowledge to my advantage) then that's their choice and their burden. The hosting robots should not act in any other capacity except to make games available, which I think we all agree is a Very Good Thing.

On the issue of running a tail -f on logfiles (or using a similar inspection method, for those running toy operating systems), I believe it's possible to use a fast ASCII obfuscation scheme like ROT-13 or some other fast character-replacement scheme to make logfiles illegible (in a practical sense) until the game's score is saved. This could even be done by making up a 1-to-1 "decoder ring" replacement code by using a hash of the of the game's start time on Irata. Doing so would make it impossible to generate a log-descrambler beforehand, particularly if the hash is properly salted before being rehashed to determine the random code pattern. (Well, it would make it impossible for me to generate one.)

Of course the ingenuity of the human mind and the instinctive drive to exploit any and all resources to obtain social advantage means no system will ever be 100% effective in preventing this type of "front-running" behavior (Hello, Wall Street!). But to me, that doesn't mean we shouldn't at least try to make it more difficult to discover information before the game's intended disclosure.

I haven't played in many bot-hosted games, but I hope the bot:noauctions command is retained. I would also like to see a bot:noassays command to prevent the recall of assay results that are no longer displayed in the status area of the colony map. Any bot:no* commands should only require a single vote to prevent * information being disclosed by the bot. Of course, I'm content to play host and only join non-bot-host games if the community decides they wish to retain the loudmouth county recorder 

More importantly, if we accept that a new generation of players is a good thing (it is), shouldn't we also try to make sure they learn how to play the game without artificial advantages conferred by our game's infrastructure, innovations that don't conform to the original design by Bunten and Ozark Softscape?

Maybe I'm just a grumpy old M.U.L.E. but when the host robot blabs a game's event history, assay findings and upcoming plot auctions then this makes our new players complacent and lazy in their play and their planning. I make the extra effort to feed my brain with my hand-mapped and recorded diary of each game and I don't begrudge others their own chosen game tracking methods. But the game itself (in the guise of the host-bot) should stand silent and not divulge that which could have been readily observed. Players who know me know that if asked, I'll usually chat the answers to questions like, "Did pirates come yet?" and other event-realted inquiries.

Now you kids get off my lawn!

+1 For creativity & joyful noise. More please! If I had one gram of artistic talent or photoshop skillzzz I'd be on this like a colonist on a 3-tite 3-mountain plot.

Bravo!

Pen and paper, old skool. I print double sided & recycle my used up pages. It's not surprising how similar my system is to those shown in the posting, great minds think ... how does that go?

Seriously: charting the game is part of the fun. It's like keeping score when you go bowling. Actual bowling, like Jeffrey Lebowski. Not the other kind.

That's just the way it goes. Lots of people don't chat at all, a few will chat abusively. As you stated, it is the internet. No escape from that fact on Planet M.U.L.E. That's why I often don't look at chat at all, or else I only watch it & chat when I'm playing with people I know.

My advice: fullscreen all the time. So much easier to find that pesky Wampus.

As long as we're making suggestions about the new ranking system, how about incorporating it into the initial turn-order determination in games? The order can still be randomly determined, but don't use a uniform probability distribution to draw the starting order. For example, use player ranks to make individual draws on differently parameterized probability distributions thusly:

1. Let each player's unit-variance normal distribution be centered about a mean value that increases with improved player rank (so a player ranked 3rd will have a distribution centered about a higher value than a player ranked 33rd).

2. Draw a small "fudge factor" value from a fixed (identical for all players and for all games) uniform distribution with a range of, say 0 to 0.1 (this range should be fairly small) for each player. Call this value U(player).

3. Draw one random value from each player's normal distribution (1 above, normal). Call this value N(player).

4. Add the two random values to obtain the rank ordering for all players

R(player) = U(player) + N(player)

5. The game's starting order is then determined according to the descending order of R(player) values. So the player with the highest R(player) value starts in first, the player with the next highest R(player) value starts in second, etc., like so:

1. Player1, R(Player1) = a
2. Player2, R(Player2) = b < a
3. Player3, R(Player3) = c < b
4. Player4, R(Player4) = d < c

Ideally this system will serve as a meaningful but not entirely predictable (or pre-ordained) handicapping system to "seed" players into a starting order before a game. Players of similar rankings will see the greatest amount of variation in their starting positions, while players of widely varied rankings will mostly find themselves ordered with the lowest ranked player starting fourth and the highest ranked player starting first. The addition of the U(player) value should prevent the system from becoming too rigidly deterministic and avoid unduly penalizing highly ranked players.

Time for another crackpot idea from the desk of Disgraced Economist & Man About Town, Doktor Buzzo.

Consider the holiday shopping season, the fickle minds of our loved ones and the deft manipulation of our material desires by those devils that practice the sinister art of advertising. What happens when a toy store begins to run low on its supply of this year's Must Have Gift for Youngsters? Think back to the year 1996 and the Tickle Me Elmo hysteria (or you can go here: [wikipedia]http://en.wikipedia.org/wiki/Tickle_Me_Elmo#Employees_injured). In other words: bedlam. The current logic of the store, say, buying up 100+ units of ore for $230 on turn 9 (when there are only a handful of plots remaining to be configured using a yet-to-be-purchased M.U.L.E.) or selling the entire food supply for $50 per unit before turn 3 is quaintly out of step with how a real (simulated) economy would set prices.

It seems a little old-fashioned for the store to sell and buy at prices that do not adjust as supplies decrease or increase. Yes, prices can change from one turn to the next, but that isn't very realistic when we consider that each turn represents a month's time. Elmo dolls sold for much less (comparatively) on December 29th than they did on December 21st, and for obvious reasons. Things should work the same way in the store on Irata.

The classic example we can all relate to is the "buy up all the ore" play. If I ran the store, I might start with a particular selling price but decide I need to increase this price quickly if there's a run of purchases. Otherwise I won't have any way to make the expected number of M.U.L.E.s to be deployed during the next turn. Similarly, if there has been a recent food shortage and now the colonists have produced an overabundance of food, I might buy the first few units at a high price but have little interest in buying the entire month's production at that same inflated rate, since the total production might conceivably last for several more months.

What I'm describing is the marginal rate of price change. This should derive directly from each commodity's changing marginal utility to the colonists and the store. I propose that during times of shortage or impending shortage the store's offer price (either buying or selling) be high and that the rate of change for marginal sales increase slowly until a near-term shortage has been averted. This would make the economy of Irata more like the economy most of us are used to living with here on boring old Earth. Fires, earthquakes and personal disasters would still have their appropriately disruptive effects. Players could still decide it is advantageous to hoard supplies in order to manipulate prices. But the monthly "lock-step" manner in which prices currently change has a disproportionately large effect on the game's balance and does not represent an efficient store policy, for both the price discovery and critical supply maintenance purposes that the store would (and should) serve.

Every commodity has a base minimum and maximum price, and those should remain unchanged. But the offer prices should move more appropriately when the store's supplies are rapidly decreasing or increasing. Early sales to the store of scare goods should be more highly rewarded, and late purchases from the store of goods that are scarce or approaching scarcity should cost more. In the case of requiring a "tie-breaker" to determine who makes the transaction, the current system of lowest-ranked player having highest priority should continue to be sufficient, so long as this too is updated each time the store transacts for a unit. Commodity pricing for sales between players would not change in any way, since the current system still serves as an efficient mechanism for price discovery. Similarly there is no reason to change the behavior of "spinning the dial" on the store's buy line when it has sold out of a commodity, since the elevated price will not be paid the store but only by another player.

And just in case anyone worries that this might effect Crystite: nope. I don't see any reason to mess with a perfectly good, perfectly random process.

Thanks for reading! I hope this proposal is not deemed too heretical; I do not wish to be branded an apostate.

I want to thank the developers for the speedy improvements they've made this week. Sure there was the oops with version 1.3.2 freezing but it was fixed quickly.

The new 1.3.3 is fantastic, thankyou to all the hardworking folks at Turborilla. The round 1 Land Auction possibility is a wonderful feature from the old game, thanks for putting it back in. The fixes that remedy the host ping advantage issue are also very much welcome.

Great job, everyone!

For the record, Khal is posting regarding a game in which I was the sub-100 player. You can see the chat transcript here: http://www.planetmule.com/server/chats/chat_game_31075_user_18085.html.

I'm not going to belabor the point, but the transcript speaks for itself.

Saying a player's move is a "dick move" is not the same as insulting the player, but I understand that this distinction may not matter to some. For which I accept responsibility. But Khal misrepresents events on two significant counts, namely:

1. I and another player were quick to assert that neither of us believed Khal's move was a deliberate abuse. In fact this assertion was repeated several times. I don't know what more I or anyone else could do to mitigate my outburst (mild at best) of frustration, but such is life.

2. Khal's reaction to this was to sulk and then terminate the game, robbing another player of what was a likely win. And in addition to being a "dick move" it also, IMO, betrays a selfish "dick personality," the PM analogue of the child that quits games and takes the only ball home.

I really don't know what came over Khal to terminate the entire game. Kick me out but don't rob somebody else's win just because your feelings got hurt by a sub-100 jerk that habitually disrespects new players (just ask them, they'll tell you what an ass I am).

PM... pout mule or planet mule? I'll let the transcript speak for me.