Can someone give a help?
- Thread starter blinnqipa
- Start date
AidanM
Member
If you really think about it displaying it on a public website is somewhat of a convention. Personally I believe EA will take action once they feel a threat, and/or someone starts or implies they want complication for hosting/coding their own TSO. Who knows they might not even wait to that point, or not even bother with it at all.xezno said:
Basically if someone is looking to make money off this there will be trouble, and so far everyone just wants to play. I think distributing game files maybe the biggest concern, but there are certain SITES that can SHARE software. As long as there's no association between PD and that site your in the clear. Since its still hosted I'd say lets come to that when needed.
Afr0
Well-Known Member
xezno said:And it says this
In addition, unless expressly authorized by EA, you may not distribute, publicly perform or display, lease, sell, transmit, transfer, publish, edit, copy, create derivative works from, rent, sub-license, decompile, disassemble, reverse engineer or otherwise make unauthorized use of Content or Entitlements.
So distributing or editing or decompiling (! - Fatbag!) is illegal without EA's permission.
I was thinking specifically about the license that comes with the game. I will read through it when I have time. Rhy is right though, "We are not distributing, editing or decompiling any of the game."
salvadorc17
New Member
There is no way to by pass authentication login from tso to play like in a local server, just for test it??? That also need a server emulator to allow you enter the game?
Afr0
Well-Known Member
Sigh, if you're so hellbent on "testing" the game right now, Fatbag has released a server emu that can be downloaded from the NIOTSO wiki, but you'll need to edit TSOClient.exe yourself in a hex-editor, as explained on the wiki. Just be aware it won't get you further than to CAS though.
salvadorc17
New Member
Im not talking about playing like offline for solo play, i mean to get by pass the ea authentication server, by adding some emulator, dont know how to do that, because tso restoration used the same idea, more easy than recompile or rewrite all the game structure.
Pd. Afro, the program that you has for iff files, can be used in windows or just linux based? I need some good program to modding tso objects into sims 1. (thats what im trying to do right now)
Pd. Afro, the program that you has for iff files, can be used in windows or just linux based? I need some good program to modding tso objects into sims 1. (thats what im trying to do right now)
Afr0
Well-Known Member
Fatbag had released a server emu, but apparently he's removed it (probably because of the legal implications).
Anyways, the game's protocol is described here, and honestly isn't that hard to follow.
You should be able to roll your own emu using PHP, Python or even Javascript. It'll only get you as far as the CAS though.
Anyways, the game's protocol is described here, and honestly isn't that hard to follow.
You should be able to roll your own emu using PHP, Python or even Javascript. It'll only get you as far as the CAS though.
Afr0
Well-Known Member
Afr0 said:
http://niotso.org/2013/06/10/select-a-s ... m-cracked/
There's still a link to the city server emulator (to get into SAS and CAS) here. I don't remember him getting farther than that.
Afr0
Well-Known Member
Right...
And so, if people are desperate to get the Server Emu working, they should try to post packets to the client (which input state causes that output state).
Problem is that even though you know the packet IDs and the name of the packets, you don't know their arguments. And that's one hell of a big problem.
But I'm guessing the first thing the client does when a sim's created, is sending:
TransmitCreateAvatarNotificationPDU
And so, if people are desperate to get the Server Emu working, they should try to post packets to the client (which input state causes that output state).
Problem is that even though you know the packet IDs and the name of the packets, you don't know their arguments. And that's one hell of a big problem.
But I'm guessing the first thing the client does when a sim's created, is sending:
TransmitCreateAvatarNotificationPDU
salvadorc17
New Member
I not so desperate, just need to know why you prefeer the difficult way than the easy one recreating just the server and not re creating all the game structure.
Because it's not that easy.
To run the existing game in server mode, we need a few things:
- DLLs to run server functionality, specifically TSOServiceServerD.dll, TSOSimulatorServerD.dll, TSOWorldServerD.dll and a whole load more server specific DLLs that were never distributed with the game.
- NullView DLLs to run the game without displaying anything, crucial for running multiple simulator instances without completely bogging down the server.
- An EXE that starts up everything in the exact way required to run the game server - it was enough trouble doing this for Edith and even that doesn't work correctly for the most part.
We can't just replace these files easily either, since the TSO server actually facilitates multi-player by running the full game and sending updates to all clients simulators. Not only do we not know the specifics of this transfer, (even what is transferred or how much the client is sent per tick) but to recreate it accurately enough for the game to accept it we would have basically recreated the game by that point anyway, not to mention the extra work of dealing with Maxis's existing protocol without any advance knowledge of how any of it works, also that it would need to be 100% accurate or the client's vm would probably desync (assuming the server sends minimal packets detailing interactions to follow, expecting the client to come up with the same result) all the time.
Other MMOs tend to be a lot simpler - they don't have many complicated virtual machines running for every room. The Sims Online is this way because the complexity worked offline - it made The Sims the game it is.
Now, all of this is assuming the original server did run simulators for each lot, which is pretty likely considering the file references, and what the alternative would be (trusting clients with hosting lots - very bad idea as it would allow easy hacking). If it didn't, we could easily write a server emulator, but what would the legal implications be? EA would have more basis to shut us down if we directly violated the game's TOS like that. (not sure about actual legal implications of server emulators)
Recreating all the game's structure is just that - the "game" part is already there, we just need to make a compatible wrapper. All user interaction will have to be redesigned (build, buy, live interactions), but all objects, graphics and most of the game logic (which is in the objects!) are already finished for us. All the hundreds of person to person interactions, group interactions, and internal person logic do not need to be re-implemented, as people are objects! Also, by building it this way, we don't even have to have it 100% completed before deploying a beta - we could skip out on OnlineJobs (there's actually a way of telling objects that they're not available) and it would still run. The real game however would probably still freak out about it, as it would expect the server it's connecting to to support them.
The server to test CAS and SAS was doable because that section of the game just accesses a simple http server that manages connections to different cities. Getting into CAS does require connecting to a more advanced city server - but the few packets used to tell the client to start CAS there are a lot less daunting (they're static, there's few of them, no underlying logic required ie. simulator) than the slew of packets that would need to be exchanged while ingame, so were feasible.
It's pretty cool to see it working, but we won't get much farther on server emulation (maybe into the city though?) until we have a fully functional SimAntics emulator and full examination of how the game communicated with SimulatorServers.
To run the existing game in server mode, we need a few things:
- DLLs to run server functionality, specifically TSOServiceServerD.dll, TSOSimulatorServerD.dll, TSOWorldServerD.dll and a whole load more server specific DLLs that were never distributed with the game.
- NullView DLLs to run the game without displaying anything, crucial for running multiple simulator instances without completely bogging down the server.
- An EXE that starts up everything in the exact way required to run the game server - it was enough trouble doing this for Edith and even that doesn't work correctly for the most part.
We can't just replace these files easily either, since the TSO server actually facilitates multi-player by running the full game and sending updates to all clients simulators. Not only do we not know the specifics of this transfer, (even what is transferred or how much the client is sent per tick) but to recreate it accurately enough for the game to accept it we would have basically recreated the game by that point anyway, not to mention the extra work of dealing with Maxis's existing protocol without any advance knowledge of how any of it works, also that it would need to be 100% accurate or the client's vm would probably desync (assuming the server sends minimal packets detailing interactions to follow, expecting the client to come up with the same result) all the time.
Other MMOs tend to be a lot simpler - they don't have many complicated virtual machines running for every room. The Sims Online is this way because the complexity worked offline - it made The Sims the game it is.
Now, all of this is assuming the original server did run simulators for each lot, which is pretty likely considering the file references, and what the alternative would be (trusting clients with hosting lots - very bad idea as it would allow easy hacking). If it didn't, we could easily write a server emulator, but what would the legal implications be? EA would have more basis to shut us down if we directly violated the game's TOS like that. (not sure about actual legal implications of server emulators)
Recreating all the game's structure is just that - the "game" part is already there, we just need to make a compatible wrapper. All user interaction will have to be redesigned (build, buy, live interactions), but all objects, graphics and most of the game logic (which is in the objects!) are already finished for us. All the hundreds of person to person interactions, group interactions, and internal person logic do not need to be re-implemented, as people are objects! Also, by building it this way, we don't even have to have it 100% completed before deploying a beta - we could skip out on OnlineJobs (there's actually a way of telling objects that they're not available) and it would still run. The real game however would probably still freak out about it, as it would expect the server it's connecting to to support them.
The server to test CAS and SAS was doable because that section of the game just accesses a simple http server that manages connections to different cities. Getting into CAS does require connecting to a more advanced city server - but the few packets used to tell the client to start CAS there are a lot less daunting (they're static, there's few of them, no underlying logic required ie. simulator) than the slew of packets that would need to be exchanged while ingame, so were feasible.
It's pretty cool to see it working, but we won't get much farther on server emulation (maybe into the city though?) until we have a fully functional SimAntics emulator and full examination of how the game communicated with SimulatorServers.
Afr0
Well-Known Member
Are you sure about that? I'm no expert in server application architecture, but the things I know, I know from other server emulators. And none of them use NullView DLLs to run the game (serverside) without displaying anything. Obviously, the server needs to simulate the game, but you can do that quite nicely without using NullView DLLs. Yes, TSO is obviously different from other games, but it wouldn't really be a stretch to imagine that for writing a server emu, you'd "simply" implement a SimAntics VM and run that serverside (without NullView Dlls, which seems overkill to me).
You can find references to the NullView DLLs in TSOClient\gamedata\sys\default.ini, so they definitely existed (used for running TSOHouseSimServerNullView). There's also a Normal view server package called TSOHouseSimServerView.
It makes sense that they would go with this approach as TSO wasn't exactly built from the ground up. The simulator probably has its roots buried deep in the graphics, audio and animation plugins, so the logical conclusion would be to develop new ones that only provide the functions the server requires (and not spend a load of time drawing anything). That way they wouldn't have to rewrite the simulator to be completely independent, plus I'm sure some functions depend on animation/sound timing, so removing it completely doesn't seem reasonable.
For the question of if it's necessary really depends on how much SimAntics depends on HIT, animations and graphics, and how much of those things it gets fed from the server. Which we've yet to figure out!
It makes sense that they would go with this approach as TSO wasn't exactly built from the ground up. The simulator probably has its roots buried deep in the graphics, audio and animation plugins, so the logical conclusion would be to develop new ones that only provide the functions the server requires (and not spend a load of time drawing anything). That way they wouldn't have to rewrite the simulator to be completely independent, plus I'm sure some functions depend on animation/sound timing, so removing it completely doesn't seem reasonable.
For the question of if it's necessary really depends on how much SimAntics depends on HIT, animations and graphics, and how much of those things it gets fed from the server. Which we've yet to figure out!