' Wrote:Why would anything need to be changed?
It seems the server is getting along fine with only 200 slots, so whats the need to raise the number or do anything else to it?
Imo, dont fix what isnt broken.
Montezuma/Kukulcan Wrote:Why would anything need to be changed?
It seems the server is getting along fine with only 200 slots, so whats the need to raise the number or do anything else to it?
Imo, dont fix what isnt broken.
I'd say the fact I can't get on for over an hour in mid-day here is a bit of a problem. If the RM comes into New York, the lack of a fully armed bomber (read: me:D) may be the thin line between win and lose.
majkp Wrote:* First (and more real) one is an idea of 2 parallel Sirius universes (servers) but the database of both servers is synchronized. This means after player logs out from one server, all changes are transferred to the other server. Both servers are RP servers and players/factions can choose between them knowing that both servers have the last 'version' of their characters. The problem might come when 1 character is used on both servers at the same time (shared chars for example) - most probably the latest updated character will be used to be sent to the other server so some changes might be lost.
I like this idea, but there may be problems with open world PvP when all of one faction's navy is online on server A and the defending faction is all on server B. Server A will win and/or have nothing to shoot at and B won't know the difference.
And we all love our PvP!
Quote:* Second idea will definitely need much more flhook programming, time and also testing before it can go live. It counts with 2 servers (later maybe more) but only one Sirius universe, each of the servers 'serving' only 1/2 of the systems. During a jump player is (if needed) automatically re-logged to the other server. Jumping, messaging, transferring cash between the servers and other stuff is handled via an flhook link. But some things will most probably be impossible to implement (like groups - they will have to be re-joined after a jump to another server's system). More issues will definitely be known later. This way looks perfect, but don't expect it to come sooner than in the end of this year most probably even next year. It's also possible that we run into problems that we're not able to solve at all.
:blink:Ew, no. Too many problems for an RPPvP server. Then again, it depends on the structure of FLHook and the language it's coded in (I can help with C/++ if someone tells me how FLHook works!)
My vote: write a new FLserve that can work with multiple cores!:lol:
Oh, and real nice of the server to crap itself while I'm shooting up some rogues...:rolleyes:
1-we want it to grow to be able to compete with a small mmorpg (or at least some of us do)
2-we'd like to have massive events where everyone's on
3-reduce lag
4-more npcs and systems maybe?
I agree with Kazinsal, his idea of a new FLserver that works with different cores could prevent the attacking/defending factions from being on the server where the other isn't on, and you wouldn't have the problem of a player limit.
These days when I try to log on, that's mostly in the morning of the americas, There's almost always a full server. Even on dead hour there are almost always more than 100 people online.
It will take some major programming, and the mod comes first. If you have time, do it if you can. This could make the server have no limit, and we could all play in a more populated universe, since combining a new FLserver with better server hardware can let the NPC's on even when there's 190+ players online.
I hope those people who say "We'll just need to code a new FLserver and all the limitations are gone" know what would be involved in such a task.
As an example, just getting a workable opensource Broadcomm WiFi driver for Linux took almost 2 years, and involved a fair amount of very talented programmers.
Why ? Because in order to not infringe on any intellectual property and copyrights, such a task needs to be divided into 2 seperate tasks :
a) One group who, without dissassembling the FLserver executable, write specs for the new FLserver code, based on observations of what the current exceutable does machinecode wise at specific points in its execution (debuggers running during execution, register inspction, messagepassing inspection, protocol inspection are OK, dissassembling the excutable into source code is not).
b) Another group who, based on the specs written from the first group, code the new FLserver executable.
I don't know how many individual actual active players there are on the DiscoveryMod servers, but if we say that in total there are 5000 persons willing to play Discovery FL online, thats a very small community to draw programmers from, in the sense of rewriting the FLserver from scratch.
And still there will be the question whether Microsoft can bring the "deriative works" question into play in a court of law, if they so wish.
Even the current "hack" of the FLserver code used on Discovery RP 24/7 to support more than the official 128 player limit, could be seen by Microsoft as an infringement of their Intellectual Property, since that involves modifying the original FLserver exe.
So a rewrite of the FLserver executable is not something I see happening - ever. Feel free to prove me wrong with actual code, but for the love of Sirius, stop using the "we just need to rewrite FLserver" as a solution to any and all limitations the current flserver has.
Cpt. Miller, of the BHG|Core vessel "Miller's Draft"
Out of bats, Out of bots, Out of torps - Down to harsh language...