The problem turned out to be a case problem. The entity file was named FrigateXinLongrange.entity (note the lower case r in range) while the entity wanted was FrigateXinLongRange (note the upper case R in range). The next patch will have case insensitive searches.
The server in sins only provides a single location for all clients to talk to and makes sure everyone is in sync. It doesn't require really any CPU. Every client is processing the entire simulation on their own computer. If one computer is slower it will drag down everyone else. A dedicated server won't help here.
Hi ThrakaAndy, sorry you are having issues playing multiplayer. Could you be more specific on how the game is dying? What exactly is happening? Is the game crashing? Does it just say "so and so has disconnected"?
There is also a bug in 1.02 that will cause all particle effects to not show up and has a high chance the game will crash when you load the mod after the game is started. To get around this turn on "Load Mod on Startup" and start the game up again. This will be fixed in 1.03.
There is a bug in 1.02 that requires you to copy every texture into your mod directory if you want new textures. This will be fixed in 1.03.
Are you both running exactly the same mod with the same files. Could you verify that the mod checksum that is reported when you load the mod is the same on both computers? Thanks.
How are you adding the weapons? How many weapons are you adding? Unfortunately due to memory constraints all ships only support a maximum of three different *types* of weapons. You can then have up to 10 points per bank. So in total you can have 120 weapon points (3 weapons * 4 banks * 10 points).
You will have to create a mod with new .entity files that Kildyu has mentioned. If you also mod the GalaxyScenarioDef.galaxyScenarioDef file with these new .entity types GalaxyForge will read it and you should be able to place your new .entity types directly.
Thanks for pointing that out. In the meantime until we fix it, you can now double click names to open up the player info dalog.
This is as designed. You have to keep your stations up to preserve structure and frigate/cruiser unlocks. We want you to have to choose whether your slots are used by research or by other things.
You have to kill enemies to see the victory screen. This means every player's portrait must be cracked in the diplomacy window. Human's disconnecting from multiplayer games don't change the simulation state (so the game can be saved and transfered). This means their planets are still around so they haven't officially "lost" the game, even though they are no longer in it.
It is one of Microsoft's "Games for Windows" requirements that we store all user-generated application data in this directory.
Haha, I'll never forget playing Dune II for the first time in high school. Being compared to it favorably is a dream come true. :)
You can currently get around 1. by saving the game and hosting it again, putting an AI in the new empty slot.
You can send your friend your save file and the game should load up fine. Your friend will lose his hotkey groups and other client specific information.
Hmmm, that looks like you have a corrupt installation. The game has found data files it can't read. Where you in the beta by any chance? The safest thing would be to completely uninstall and install again from scratch.
If you are both behind the same router then there should be no problems. If not, then you may potentially have to configure the router to direct traffic to the host port. (port forwarding).
Does the slow down also happen when you send a chat message?
Did your friend have the beta installed? If so have him uninstall Sins before downloading and installing the final release version. Thanks!
They are in binary purely for optimization reasons. There is no purposeful obfuscation.
Thank you for the detailed description on how to recreate this bug! It is now fixed and your modules will construct until they can construct no more! (when they really run out of actual slots).
Hmmm, we will have to think about how to handle that one. I agree it could be a problem. Thanks for the feedback!
Nice find! This was caused due to a certain programmer's over eagerness to optimize the rendering of these graphs. New points in the line are only added if the y value actually changes. The programmer has since been reprimanded and now the extra points needed are added to show accurate changes in you simulation state.
Nice find! We already have ally colors setup (you can see the entry in your .colors file under MinAllianceFriendly, MaxAllianceFriendly). Unfortunately there was a bug in code that used the wrong colors. This has been fixed. Infocards will also respect this setting as well. For example the breakdown on groups of ships won't be in the player's actual color anymore, but instead use the alliance color.
Could you send of save game of this to [email protected] with a description of the problem (or a link to this thread). Thanks!
