francot514
Well-Known Member
Now niotso is inactive, that will affect PD development progress?
TSO-SE Discussion Thread
- Thread starter Blayer98
- Start date
lol, he was inactive there for a long time already... and that will no affect PD because that its two different projects.
Actually, since August, I've been talking to Blayer about how I (or we) could add new functionality to TSO-SE.
Here's our mock-up for the server administration page:
http://niotso.org/files/administration.html
Here's our mock-up for the server administration page:
http://niotso.org/files/administration.html
francot514
Well-Known Member
This link is no longer working!
https://auth.east.ea.com/AuthLogin?username=&password=&serviceID=2147&version=2.5
https://auth.east.ea.com/AuthLogin?username=&password=&serviceID=2147&version=2.5
Heh. They took down the DNS records for auth.east.ea.com (159.153.234.80) and auth.west.ea.com (159.153.199.220), but the https://auth.east.ea.com/AuthLogin?username=&password=&serviceID=2147&version=2.5 link still works if you put these DNS records in your hosts file.
Here's some exciting news! Me and Fatbag have managed to figure out a way to get the TSO N&I Patcher working!
Well, I figured it out, and Fatbag is currently did some work on it. This is all thanks to the Buddy.exe and .ini files left in TSOPatch! These files still exist, even in EA-Land.
However, we are currently stuck at a pitstop right now, since we need to make a TSOSessionCookie for the patcher to recognize, or it'll think Cookies are disabled, which of course, they're not...
Here's a few images!
It's important to know that there is an EXACT clone of authlogin.dll, which also contains https in the same place, patching as shown on niotso.org/2013/06/ will allow the patcher to function as it originally would, except it's not secure now. Buddy.ini also contains server and other data relating to the AuthLogin, CitySelector, and the Transmitter for PatchZero. (downloads.tso.ea.com is archived on archive.org, and yes, you can download the channels, but they do nothing unless you have a server.)
Well, I figured it out, and Fatbag is currently did some work on it. This is all thanks to the Buddy.exe and .ini files left in TSOPatch! These files still exist, even in EA-Land.
However, we are currently stuck at a pitstop right now, since we need to make a TSOSessionCookie for the patcher to recognize, or it'll think Cookies are disabled, which of course, they're not...
Here's a few images!
It's important to know that there is an EXACT clone of authlogin.dll, which also contains https in the same place, patching as shown on niotso.org/2013/06/ will allow the patcher to function as it originally would, except it's not secure now. Buddy.ini also contains server and other data relating to the AuthLogin, CitySelector, and the Transmitter for PatchZero. (downloads.tso.ea.com is archived on archive.org, and yes, you can download the channels, but they do nothing unless you have a server.)
I think it would be pretty cool to simply get original update system working instead of reinventing the whole thing. It would be also quite nice to be able to "upgrade" TSO to PD using this tool.
Afr0
Well-Known Member
That's pretty cool!
Interestingly, I just modified the PDPatcher so it doesn't rely on PDBootstrap anymore.
Much simpler and much more stable, since PDBootstrap just kept crashing.
pisarz1958: This is a remake project. We're remaking TSO because it's the fastest and most effective way to get it back.
You know how to code, and I already told you on Github to chip in. Thus you're in an extremely bad position to make such comments. Please fix one or more of the issues in the issue tracker instead of complaining.
Interestingly, I just modified the PDPatcher so it doesn't rely on PDBootstrap anymore.
Much simpler and much more stable, since PDBootstrap just kept crashing.
pisarz1958: This is a remake project. We're remaking TSO because it's the fastest and most effective way to get it back.
You know how to code, and I already told you on Github to chip in. Thus you're in an extremely bad position to make such comments. Please fix one or more of the issues in the issue tracker instead of complaining.
@Afr0,
Uhm, but I'm not really complaining, I just thought it would be cool to reuse something that's already there.
And as I don't have much experience with either C# or game dav and also have my own projects in Qt I'm trying to push forward a release soon (for example, my XMPP client), I'd rather not just grab the code and start making changes in "I have no idea what I'm doing" style. Don't worry, I'll jump into as soon as I'll feel like being able to do so. :>
Uhm, but I'm not really complaining, I just thought it would be cool to reuse something that's already there.
And as I don't have much experience with either C# or game dav and also have my own projects in Qt I'm trying to push forward a release soon (for example, my XMPP client), I'd rather not just grab the code and start making changes in "I have no idea what I'm doing" style. Don't worry, I'll jump into as soon as I'll feel like being able to do so. :>
Last edited:
I have added documentation for some new PDU formats that are related to (or appear to be related to) the IM and PM systems in TSO on the wiki: http://wiki.niotso.org/Maxis_Protocol
Here are some screenshots of the TSO New & Improved trial.
Here are some screenshots of the TSO New & Improved trial.
Wow, very nice to see again the progress of TSO-SEI have added documentation for some new PDU formats that are related to (or appear to be related to) the IM and PM systems in TSO on the wiki: http://wiki.niotso.org/Maxis_Protocol
Here are some screenshots of the TSO New & Improved trial.
but would it be possible to have all the news of this project since Niotso.org ?Rhys, first I can tell you that I haven't figured out any of the simulation PDUs yet. I don't even know what the simulation PDUs would be... I'm just taking a wild guess here: maybe TransmitDataBlobPDU, BroadcastDataBlobPDU, RSGZWrapperPDU, etc. Actually, LogAvatarActionPDU looks relevant...
I have not gotten action queues (pie menu actions) working, or buy/build mode working, in -NoNetwork mode; I'm guessing that the client would normally send these actions to the server, and the server would later respond that "this user performed this action", at which point the client displays the action; and so since we're in -NoNetwork mode, I think the client simply does not send any messages to the server (not even an emulated server) and does not receive anything back from the server.
I am guessing that the server normally sends to the client: "Exactly 0.250 seconds have elapsed since I last talked to you. During that time, these players have made these actions.", so the client applies those actions and runs 0.250 seconds' worth of simulation. (As I said in the previous thread, my guess is that if the connection between the server and the client ever pauses for a second, the client predicts 'no action'; if it's wrong, it rewinds the simulation, applies the changes, and fast-forwards.) My simulation patch (here) simply causes the client to run the simulate function to catch up to the current time many times per second. (The client already calls a function many times per second which does "If the simulation is currently behind the 'current time', run the simulation until it is no longer behind" without my patch, but with a 'current time' value that never changes; my patch modifies the function so that the 'current time' is updated [synchronized with your computer's QueryPerformanceCounter time] right at the top of the function.)
Offredo95: Sorry for being a little disorganized. I think the Maxis Protocol page is a better place for TSO-SE news than the Niotso Blog. The page *is* the news.
I have not gotten action queues (pie menu actions) working, or buy/build mode working, in -NoNetwork mode; I'm guessing that the client would normally send these actions to the server, and the server would later respond that "this user performed this action", at which point the client displays the action; and so since we're in -NoNetwork mode, I think the client simply does not send any messages to the server (not even an emulated server) and does not receive anything back from the server.
I am guessing that the server normally sends to the client: "Exactly 0.250 seconds have elapsed since I last talked to you. During that time, these players have made these actions.", so the client applies those actions and runs 0.250 seconds' worth of simulation. (As I said in the previous thread, my guess is that if the connection between the server and the client ever pauses for a second, the client predicts 'no action'; if it's wrong, it rewinds the simulation, applies the changes, and fast-forwards.) My simulation patch (here) simply causes the client to run the simulate function to catch up to the current time many times per second. (The client already calls a function many times per second which does "If the simulation is currently behind the 'current time', run the simulation until it is no longer behind" without my patch, but with a 'current time' value that never changes; my patch modifies the function so that the 'current time' is updated [synchronized with your computer's QueryPerformanceCounter time] right at the top of the function.)
Offredo95: Sorry for being a little disorganized. I think the Maxis Protocol page is a better place for TSO-SE news than the Niotso Blog. The page *is* the news.
Last edited: