FreeOrion 0.1 Issues thread
Moderator: Oberlus
-'Multiplayer hotseat' sort of works. Start freeoriond.exe and run freeorion.exe twice. Have one client host a game, and the other join it. Problems start when task switching between the two clients (both clients in fullscreen mode). mouse and display aren't in synch, and seem to move around randomly after task switching. This is fixed by setting the game resolution the same as the desktop resolution (or vice-versa presumably).
-'mp hotseat' with clients in windowed mode is workable. The guest client's UI (the one that's not the host of the game) is very unresponsive if the host's window is visible.
-Only one freeorion.log file is produced, even if there are muliple human clients running on the same machine. It would be hard to tell which error messages are from which client.
-in mp hotseat windows xp sometimes sounds a chime after switching windows. The chime goes (high pitch note, low pitch, pause, low pitch, high pitch). (I think) it means 'new USB device detected' or somesuch, it's something to do with my USB mouse.
-view of the other player's fleets and planets is not updated (one player colonises a planet with starting fleet, the other player sees the starting fleet orbiting an empty planet).
-sending combat ships to undefended enemy systems will crash one of the clients on a new turn (combat in empty systems works).
-defense bases don't enter combat. One mark1 won vs 2 defense bases - seems unlikely? Or is combat just a coin toss at this point?
-after turning on combat logging (combat\combatsystem.cpp:17, uncomment the #define) and recompiling the server I got:
This was for a combat between Empire0's mark1 and Empire1's homesystem with two DefBases and the starting fleet of 3 noncombat ships. So it seems like the DefBases aren't being used in combat.
-windows 95 is not supported I guess. My poor old win95 box complains that "The GiGi.dll file is linked to missing export kernel32.dll:GetFileAttributesExA". This error at least may be fixable: http://msdn.microsoft.com/library/defau ... utesex.asp (there are probably more such errors not reported).
-'mp hotseat' with clients in windowed mode is workable. The guest client's UI (the one that's not the host of the game) is very unresponsive if the host's window is visible.
-Only one freeorion.log file is produced, even if there are muliple human clients running on the same machine. It would be hard to tell which error messages are from which client.
-in mp hotseat windows xp sometimes sounds a chime after switching windows. The chime goes (high pitch note, low pitch, pause, low pitch, high pitch). (I think) it means 'new USB device detected' or somesuch, it's something to do with my USB mouse.
-view of the other player's fleets and planets is not updated (one player colonises a planet with starting fleet, the other player sees the starting fleet orbiting an empty planet).
-sending combat ships to undefended enemy systems will crash one of the clients on a new turn (combat in empty systems works).
-defense bases don't enter combat. One mark1 won vs 2 defense bases - seems unlikely? Or is combat just a coin toss at this point?
-after turning on combat logging (combat\combatsystem.cpp:17, uncomment the #define) and recompiling the server I got:
Code: Select all
Wed Mar 10 11:30:50 2004 DEBUG : COMBAT resolution!
Wed Mar 10 11:30:50 2004 DEBUG :
current forces
Empire1 ships (cmb,non cmb,destr,retr): (#0:0,#3:3,#0,#0); planets : #1:15
Empire0 ships (cmb,non cmb,destr,retr): (#1:1,#0:0,#0,#0); planets : #0:0
Wed Mar 10 11:30:50 2004 DEBUG : Damage done by Empire1 0
Wed Mar 10 11:30:50 2004 DEBUG : Damage done by Empire0 0
Wed Mar 10 11:30:50 2004 DEBUG :
current forces
Empire1 ships (cmb,non cmb,destr,retr): (#0:0,#3:3,#0,#0); planets : #1:15
Empire0 ships (cmb,non cmb,destr,retr): (#1:1,#0:0,#0,#0); planets : #0:0
Wed Mar 10 11:30:50 2004 DEBUG : Damage done by Empire1 0
Wed Mar 10 11:30:50 2004 DEBUG : Damage done by Empire0 1
Wed Mar 10 11:30:50 2004 DEBUG :
current forces
Empire1 ships (cmb,non cmb,destr,retr): (#0:0,#2:2,#0,#1); planets : #1:14
Empire0 ships (cmb,non cmb,destr,retr): (#1:1,#0:0,#0,#0); planets : #0:0
(...)
Wed Mar 10 11:30:50 2004 DEBUG : Damage done by Empire1 0
Wed Mar 10 11:30:50 2004 DEBUG : Damage done by Empire0 1
Wed Mar 10 11:30:50 2004 DEBUG :
current forces
Empire1 ships (cmb,non cmb,destr,retr): (#0:0,#0:0,#0,#3); planets : #0:0
Empire0 ships (cmb,non cmb,destr,retr): (#1:1,#0:0,#0,#0); planets : #0:0
-windows 95 is not supported I guess. My poor old win95 box complains that "The GiGi.dll file is linked to missing export kernel32.dll:GetFileAttributesExA". This error at least may be fixable: http://msdn.microsoft.com/library/defau ... utesex.asp (there are probably more such errors not reported).
Yes, this seems to be the difference. I can confirm this bug. I looked at it yesterday but i found another issue when colonizing a planet from a colony ship only fleet.vorenhutz wrote:I had colonised a planet in that system, I think that's the difference.noelte wrote:Hmm, i did this myself and it worked. I will check this again.vorenhutz wrote:-color of the system name should change when system is conquered
<edit> It still work for me!
You are talking about multiplayer? I can see the problem, you can't determine if a planet is colonized at the same turn by another empire. I will keep this issue in mind.vorenhutz wrote:-view of the other player's fleets and planets is not updated (one player colonises a planet with starting fleet, the other player sees the starting fleet orbiting an empty planet).
Ronald.
Surely you shouldnt be able to see if someone has colonised a planet until the next turn.noelte wrote:You are talking about multiplayer? I can see the problem, you can't determine if a planet is colonized at the same turn by another empire. I will keep this issue in mind.
Which begs an interesting question - how are you going to handle 2 people trying to colonise a planet at the same time?
The COW Project : You have a spy in your midst.
about colonisation
In MOO3 if two colonyships arrive at the system exactly at the same time to colonise the same planet and neither has any military support, planet remains uncolonised until some military support arrives or either of the colonyships leaves the system or chooses to colonise another planet on same system. I think this would be a fair solution. Later when speed of the ships will be taken account, faster/the one arriving earlier though on same turn, would win the planet.
Difference between a man and a gentleman is that a man does what he wants, a gentleman does what he should. - Albert Camus
I had thought of that but forgot to mention it explicitly. Actually what I meant was that even after several turns, one player sees a colonised planet and no colony ship, and the other player continues to see a colony ship and an empty planet (which is wrong). A lot of this will probably be sorted out when visibility/scouting is implemented so perhaps it's not worth worrying about now.noelte wrote:You are talking about multiplayer? I can see the problem, you can't determine if a planet is colonized at the same turn by another empire. I will keep this issue in mind.vorenhutz wrote:-view of the other player's fleets and planets is not updated (one player colonises a planet with starting fleet, the other player sees the starting fleet orbiting an empty planet).
Ronald.
As discussed above:
-in mp when both players choose to colonise the same planet in the same turn, the second client crashes.
How about doing colonisation last thing in between turns?
* no need to deal with colony ships destroyed in combat
* newly built colony ships can choose to colonise in system (on second thought this could be irritating)
* colony ships arriving from deep space can colonise
The server could pick a random order for empires to do colonisation to avoid the conflict. Also the current colonisation UI could be used to assign system+planet destinations to colony ships, in which case colonisation would proceed automatically.
I think in essence this is how moo2 did it, iirc.
-in mp when both players choose to colonise the same planet in the same turn, the second client crashes.
How about doing colonisation last thing in between turns?
* no need to deal with colony ships destroyed in combat
* newly built colony ships can choose to colonise in system (on second thought this could be irritating)
* colony ships arriving from deep space can colonise
The server could pick a random order for empires to do colonisation to avoid the conflict. Also the current colonisation UI could be used to assign system+planet destinations to colony ships, in which case colonisation would proceed automatically.
I think in essence this is how moo2 did it, iirc.
Colonisation should definitely be the last ship based action performed.
w.r.t. who gets to colonise in the event of conflict.
Dont like the idea of a random dice toss deciding it. Too... er.... random
Modelling arrival times to fractions of a turn, giving prioriy to those who got there first would be good.
Alternatively just have a stand-off if two ships try to colonise the same planet. They should both be actively trying to colonise in order to block each other though. What i'd hate to see is what we ended up with in Moo3 - if ships from 2 races are in-system (no matter what types) then no colonisation can be carried out. So if you have a NAP with a race you can completely stifle their ability to grow by parking an small ship in every one of their systems.
w.r.t. who gets to colonise in the event of conflict.
Dont like the idea of a random dice toss deciding it. Too... er.... random
Modelling arrival times to fractions of a turn, giving prioriy to those who got there first would be good.
Alternatively just have a stand-off if two ships try to colonise the same planet. They should both be actively trying to colonise in order to block each other though. What i'd hate to see is what we ended up with in Moo3 - if ships from 2 races are in-system (no matter what types) then no colonisation can be carried out. So if you have a NAP with a race you can completely stifle their ability to grow by parking an small ship in every one of their systems.
The COW Project : You have a spy in your midst.
[pedantic]Daveybaby wrote:Modelling arrival times to fractions of a turn, giving prioriy to those who got there first would be good.
Doesn't that just depend on where the colony ship started from, which is ultimately determined by where your home system is, which is, err, random?
[/pedantic]
Coin toss just seems simpler.
A few random UI related comments, feedback on v.01:
1: System names should disappear at a certain zoom level.
2: If you have a colony ship in system, a colonize button should appear next to uninhabited planets. Going through the fleet dialog is a bit of a chore.
3: Scrolling around the map with click-drag is a chore. How about using the arrow keys and the FPS keys (WASD) to scroll? With the FPS keys, the player doesn't have to move his hand in a awkward position to scroll.
4: A button to automatically zoom you to your home-system would be spiffy, along with <-- --> buttons to navigate along your occupied systems (like a data-entry dialog for a database). Could stick the UI for this at the top or bottom of the sidebar.
4: You shouldn't be able to see planets in unexplored systems. Need a nice "Unexplored" bitmap to stick into the sidebar. (also, maybe system names should be hidden or greyed out on unexplored systems--makes it easier to tell which has been scouted)
5: The stars don't look right against the nebulas. Easy to fix: use stars without excessive glows. Plus bdaddy and I were talking about animated stars long long ago, but, ah, we got lazy
6: Nebulas look keen, but more variation would be nice. Also, I believe they'd do the parallax thing more conviningly if they were (a) attached to the bottom layer instead of the top and (b) there were more layers. Again, long long ago bdaddy and I were talking about animated nebulas via particle systems. Seems doable to me, though I don't know that it's worth programmer time.
7: Rotating planets=nice. But...rotate them very slowly and smoothly. To get enough frames without hogging memory and hd space it really have to be a 3d sphere with a texture attached. Not a priority for v.2 at all, imho.
8: Speaking planets, those shadows I stuck on them melds too easily into the dark background. Planets 0.2 should probably have much more subdued shadows.
9: The fleet dialog works. But I feel it could be more intuitive--no idea how to accomplish this yet.
10: Shouldn't lose one's place when ending the turn. If the sidebar was opened to a specific system during the turn, should remain that way when control is returned to the player.
(Actually, I find the splash screen tween turns jarring. It would be better to have just a small status box in the top center of the screen. Esp. important during multiplayer games: players should be able to continue chatting and looking at their empire's state between turns.)
11: when the side bar is open, should be able to scroll the width of the map within the remaining potion of the galaxy screen.
12: The icon of a traveling ship should point towards it's destination. Also, it would be nice if there was some "exhaust" trailing the ship, it's length matching the distanced traveled in the last turn.
alrighty, I'll quit typing now.
1: System names should disappear at a certain zoom level.
2: If you have a colony ship in system, a colonize button should appear next to uninhabited planets. Going through the fleet dialog is a bit of a chore.
3: Scrolling around the map with click-drag is a chore. How about using the arrow keys and the FPS keys (WASD) to scroll? With the FPS keys, the player doesn't have to move his hand in a awkward position to scroll.
4: A button to automatically zoom you to your home-system would be spiffy, along with <-- --> buttons to navigate along your occupied systems (like a data-entry dialog for a database). Could stick the UI for this at the top or bottom of the sidebar.
4: You shouldn't be able to see planets in unexplored systems. Need a nice "Unexplored" bitmap to stick into the sidebar. (also, maybe system names should be hidden or greyed out on unexplored systems--makes it easier to tell which has been scouted)
5: The stars don't look right against the nebulas. Easy to fix: use stars without excessive glows. Plus bdaddy and I were talking about animated stars long long ago, but, ah, we got lazy
6: Nebulas look keen, but more variation would be nice. Also, I believe they'd do the parallax thing more conviningly if they were (a) attached to the bottom layer instead of the top and (b) there were more layers. Again, long long ago bdaddy and I were talking about animated nebulas via particle systems. Seems doable to me, though I don't know that it's worth programmer time.
7: Rotating planets=nice. But...rotate them very slowly and smoothly. To get enough frames without hogging memory and hd space it really have to be a 3d sphere with a texture attached. Not a priority for v.2 at all, imho.
8: Speaking planets, those shadows I stuck on them melds too easily into the dark background. Planets 0.2 should probably have much more subdued shadows.
9: The fleet dialog works. But I feel it could be more intuitive--no idea how to accomplish this yet.
10: Shouldn't lose one's place when ending the turn. If the sidebar was opened to a specific system during the turn, should remain that way when control is returned to the player.
(Actually, I find the splash screen tween turns jarring. It would be better to have just a small status box in the top center of the screen. Esp. important during multiplayer games: players should be able to continue chatting and looking at their empire's state between turns.)
11: when the side bar is open, should be able to scroll the width of the map within the remaining potion of the galaxy screen.
12: The icon of a traveling ship should point towards it's destination. Also, it would be nice if there was some "exhaust" trailing the ship, it's length matching the distanced traveled in the last turn.
alrighty, I'll quit typing now.
i'm working on this with noelte atm, it's smooth if we use 128 frames(we are using multiple .pngs atm, one for every frame -> 2,8mb), 64 isn't that smooth, but could also work.7: Rotating planets=nice. But...rotate them very slowly and smoothly. To get enough frames without hogging memory and hd space it really have to be a 3d sphere with a texture attached. Not a priority for v.2 at all, imho.
i would like to use a video format for this purpose, but i don't know how hard it is to implement. i've rendered to an .avi file(xvid codec) and the animation is only 300kb. it looks clean and smooth.
if you use a 3d sphere with attached texture you won't be able to get a
nice atmosphere effect. prerendered looks much better!
maybe you could also use .mng for the animation, but again i don't know how hard it is to imlement. and i know nothing about the compresion.
if we don't get this working with video or .mng we could maybe release an additional eye candy package, so that the user can decide whether he wants rotating planets, or not.