Also: forum admins, could you choose one of the 1.2.2-doesn't-work-on-a-mac threads, and lock the other ones so we can all focus on the same conversation?

[Default Java:]

With either of the following Java versions, MULE 1.2.2 does not bring up the game. It only launches and then quits.

Default Java:
java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03-333-9M3125)
Java HotSpot(TM) Client VM (build 1.5.0_22-147, mixed mode, sharing)

Using Java Preferences to only select Java SE 6 (64-bit):
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

System Version:   Mac OS X 10.5.8 (9L31a)
Kernel Version:   Darwin 9.8.0

I have the same problem. I'm running OSX 10.5.8 (9L31a), Darwin 9.8.0 on an iMac w/ Intel Core 2 Duo that has Java 1.5.0_20 and 1.6.0_15 available, and Java Preferences set to 1.6.0 doesn't fix the problem.

I concur.

I would also suggest that the central MULE server and future versions of the client be configured to use a server node/exchange/rendezvous point that is specific to the version of MULE (e.g. 1.1, 1.2.1, 1.2.2) etc., and the central MULE server be configured to allow older clients to run. Please do this rather than shut out users who can't run the latest version.

If two versions are interoperable (suppose that clients running 1.2.1 and 1.2.2 can communicate properly), then configure the central MULE server to let them interoperate. (e.g. behind the scenes, rendezvous point for 1.2.1 and 1.2.2 map to the same spot) If two versions are uninteroperable, let them be uninteroperable and let each have their own pool of inter-client communications. I would think it wouldn't be too hard to set up a service to act this way; Apache does URL rewriting all the time to handle resource mapping in this way.

take a deep breath... be patient...  some of us on Macintoshes are unable to play 1.2.2 at all... this will all be fixed sometime soon.

PLEASE let us download previous version :/

ha, cool... and maybe you can drill from an adjacent plot? (there are horizontal/angled drills, you know!)

custom game rules are fine by me (would be helpful to test playability), but

(a) you'd have to get all the human players to agree on them
(b) scores shouldn't count towards the high scores on this website, since there's no way to compare high scores in a custom game to high scores in any other game except the variety played.

this has been an idea of mine for a while. (NOTE: for a new MULE concept ONLY. Do *NOT* tweak the version of this game that is supposed to be close to the original)

What if it took longer to travel on the map, except for places where players built roads? Or that you couldn't sell goods unless there were roads connecting the plot in question to the store? Right now the only disadvantage to plots of land far from the store is the fact that it takes more time to travel there to install a mule, and the only distance that matters is the distance for your player to walk in whatever path it takes. Building a road would cost money/time initially, but it would be a way to make travel to further places go faster.

I noticed this too. See my other post here.

(ref: game = http://www.planetmule.com/sector-map?mycolonies&game_id=11740)

We just played a game where the network lag was moderately high (150ms ping) and it made clear that there is an advantage to the game host in the way that the auction currently works. With long time lags, the host's view of who gets to buy/sell first is different than the other players'. I assume this is because the local copy of each game doesn't wait for the host server to determine all the timing, it adjusts player positions on screen to give an approximation of what's happening on the host (even though this is really incorrect, the "true" timing must happen on the host only).

The player who was hosting was able to outbid 2 of us for food/energy on the later turns because he hosted the game, even though we both held the up arrow key the whole time and were lower-ranked players.

Please consider slight tweaks to the auction to fix this issue. Since it takes a while for the sellers to reach the store or buyers, and buyers to reach the store or sellers, I think it's possible to allow fair auctions even considering network lags, without slowing the game down too much. This may take some programming subtlety, depending on how it's implemented right now. My guess is that this is solvable if there are discrete timeslices (perhaps 100-150msec), where for each of those timeslices each player's computer must transmit to the host computer whether the player has moved up, down, or stayed at the same position. This would allow the host computer to determine player position compensated for network delays (e.g. player 1's movement in timeslice 1 arrives after player 2's movement in timeslice 1). Don't bother slowing the game down for round-trip communications UNLESS there's close player-to-player positions and it is time to determine which player gets the buy or sale -- then wait a longer timeout to reconcile the timeslice movement decisions and make sure player positions are synchronized properly.

e.g. if player 3 is the host, and player 2 is about to sell to the host in timeslice 100 but player 1's net connection is slow and the host still hasn't received player 1's command for timeslice 100 **and** player 1 is close to the sale price, then wait to see what player 1's command for timeslice 100 is. If player 1 is NOT close to the sale price, it doesn't matter and player 1 can be safely eliminated from the sale.

The players move too fast in the auction anyway, and in the original, time and position were more quantized.


The other problem with the auction at present, is a little more subtle. Let's say some players have some type of good (say food or energy) and are selling it to the store. Then after their selling binges start, another player X decides, oh, hey I'll buy some of it, and moves up to the store price. It's too late, though. Player X is locked out of the buy/sell process unless there is an instant where none of the sellers is selling to the store.

Not sure how to solve this problem; maybe it isn't a problem since player X waited before deciding to buy. But you should warn people that this can happen.

food shortages are one thing. energy shortages are much more severe (lack of production in mules) -- yet for some reason the AI was producing food and not energy.

Also, it's one thing if the AI is doing risk-mitigation, another when it is looking at the short term benefits of production during a turn. When dealing with energy, I have two things to worry about:

1) [energy production vs. purchase] Am I making enough energy myself to support my ongoing energy requirements? If not, should I install an energy MULE or should I rely on the marketplace to supply my energy needs? (not a clear answer... my personal strategy is to always ensure I have at least a slight excess of energy, as the consequences of energy shortages are severe, I only need 2 adjacent plains/desert plots to provide lots of energy, and the marketplace is unreliable.)

2) [immediate consequences of energy shortage] The auction round on the previous turn will tell me how much surplus/deficit I have the next round, under the assumption that I will place one additional non-energy MULE onto one of my land plots. If I have neither a surplus/deficit, then I can place 1 additional non-energy MULEs. If I have a surplus of 1 energy unit, then I can place 2 additional non-energy MULEs. If I have a deficit of 1 energy unit, then as long as I don't add any more non-energy MULEs (e.g. do nothing or add an energy MULE) I will have just enough energy to produce on all my non-energy MULES -- but if I do add, say, a smithore MULE, this is a really bad idea, because it means that one of my MULEs at random will be chosen to be unproductive that turn. If I have a deficit of 2 energy units, and I convert a non-energy MULE to an energy MULE, I will have just enough energy to produce on all my non-energy MULEs. (etc.)

This second point is MUCH more important to consider than the first point (whether to achieve "energy independence"). Very little, if any, point in paying $$$ for a MULE if its production is going to be 0 because of lack of energy.

(not quite sure if this is the same issue mentioned in the FAQ)

AI had tons of smithore + farming MULEs, no energy mules, had shortage of energy, and on next turn instead of installing an energy MULE, it installed another smithore mule, thereby making its energy shortage worse, never mind the risk-mitigation advantages of having energy mules.

http://www.planetmule.com/hi-score-game/game?game_id=10734

so what's with the sector map anyway? (other than a cool visualization)

OK, we've had a bunch of posts that get into arguments like "make the pirates stop stealing smithore!" "no, keep it the way it is!" "but in the original game they didn't steal smithore...." "those days are over, move on...."

I'd be willing to bet that most people here are either purists (keep the game as close as possible to the original) or like the game more or less as it is, with a few tweaks if necessary, and that there aren't many people who are purists about some game features but like the new game for other features.

Could we have a discussion about overall game design philosophy? How would you like to see M.U.L.E. evolve?

C64!!!!!! (well, actually, a C128 which we got when our C64 joystick port got zapped by static and fried one of the ICs.)