Entire TSO CAS and other things in HTML5

Most definitely you've come a great way in the couple days I've been busy with school lol. Now when the offline test preview is available with the sims be stored locally or on a network?
 
I've been quite busy with other things recently, so I haven't done much in the past few days. I have the matchmaker running from the game files though, even though it's not yet correctly tied into the UI engine.

Next thing I need to do is implement a main controller functional object to handle dynamic switching between the matchmaker and main game, as well as controlling the UCP and all game windows like chats etc.

Then I'll need to add support for mouse events to "fall through" UI elements if no elements are touched, so that I can get both the UI's mouse detection andthe game's mouse detection working synchronously. Only problem is that I need to add a special case where if the mouse is over a UI element I need to send a fake event or something to put the game's "mouse position" offscreen so that stuff doesn't stick highlighted when you mouse off into a UI element.

Then I'll need to fix up fullscreen for the matchmaker, which is currently non-functional. I'm not sure how I'll deal with widescreen aspect in far zoom (showing the edge of the map will be ugly, and cutting off the top and bottom of the map is a bad idea), but I can get widescreen display working easily for the nearer zoom.
 
What that means, youre working on implementing ui engine to the game or just to the create a sim? Whats you progress status?
 
salvadorc17 said:
What that means, youre working on implementing ui engine to the game or just to the create a sim? Whats you progress status?
The UI engine is currently completely implemented, I just need to extend it to work in conjunction with the game in the background. All existing screens (CAS, SAS, Load screens etc) work on only the UI engine and simple behaviors called on UI element changes.

I haven't started on the main game, if that's what you're interested in. I'll work on that after this, I think a good starting point would be devising the data format for storing the simantics state based off of the blueprints files. Though they aren't the format the lots were saved in, they're probably designed to do a 1:1 mapping to it to keep generating lots based on them easy.
 
How are you programing the engine (not the Programming Language, the method) - is there wiki.niotso.org page for a UI reader or something? By the way, I have compiled the FAR extractor for anyone that needs it (not that anyone really will) and I also downloaded some NIOTSO official binaries. Hopefully, Project Dollhouse will be finished next month - but only the CAS / SAS screens. I saw a video recently with TSORestoration showing CAS,SAS, and an empty lot... And, I also found a few TSOR info topics - apparently (acording to Ghost) Afr0 was the creator of TSOR (if anyone new didn't know) but his team (1st team) had to dissassemble to continue with their lives. Then, Ghost asked Afr0 if he could work on the TSOR project, and not soon after, there was a second team (2nd team).
Anyways, one of the points of this reply was to tell anyone that EA can't stop the projects (and Afr0 checked this years ago) because all we're (or you are - I use my own resources) doing is READING from the game files.
I have also seen some things like packet readers in the TSO files. Maybe it is possible to make a small server emulator...
It turns out that Ghost therefore faked (or so I think) the EA letter, and Afr0 was the one doing all the work all the time ;) Thank you, Afr0!
(If Afr0 wants to remove/change/add information he can - you have my permission to edit this reply, Afr0!)
 
xezno said:
How are you programing the engine (not the Programming Language, the method) - is there wiki.niotso.org page for a UI reader or something?

The page you're looking for is here.
It documents the UIS format in full detail (the format is readable with Notepad, by the way). So to make a UI-engine, what you do is that you parse each line in a UIS (UIScript), then you pass that to a lexing function. The lexer would then tokenize the line and spit out a series of organized tokens that could be used to generate UI items (for this you need a graphics library at the very least, like OpenGL or DirectX).
For the UIS format, you only really need to organize tokens in one of two ways; a tag, such as AddButton, or an argument to the tag, such as id, position or size.

If you think this is complicated, there's a reason for that: most games/engines would either hardcode their UI components/elements, or use an already existing scripting language such as Lua or Python. But Maxis being Maxis, of course they had to roll their own. And the scripting language isn't actually that bad, though there's no need for it.
 
Maybe it is possible to make a small server emulator...

It is possible to make a small server emulator, because Andrew managed to reverse part of the protocol.

There's lots more remaining though, so the server emulator wouldn't be very interesting.
 
Afr0 said:
xezno said:
How are you programing the engine (not the Programming Language, the method) - is there wiki.niotso.org page for a UI reader or something?

The page you're looking for is here.
It documents the UIS format in full detail (the format is readable with Notepad, by the way). So to make a UI-engine, what you do is that you parse each line in a UIS (UIScript), then you pass that to a lexing function. The lexer would then tokenize the line and spit out a series of organized tokens that could be used to generate UI items (for this you need a graphics library at the very least, like OpenGL or DirectX).
For the UIS format, you only really need to organize tokens in one of two ways; a tag, such as AddButton, or an argument to the tag, such as id, position or size.

If you think this is complicated, there's a reason for that: most games/engines would either hardcode their UI components/elements, or use an already existing scripting language such as Lua or Python. But Maxis being Maxis, of course they had to roll their own. And the scripting language isn't actually that bad, though there's no need for it.
Yeah, I read that - now I understand. And yeah, Maxis is being Maxis as usual.
 
I think a server emulator, will be some fun meanwhile this project is realized, we only need some files and protocols that recreate the master server (castanet is the one used by game), using all the tso client files, like world of warcraft server emulators. This is really so hard?
 
Yes, it's hard. It's a miracle Andrew even managed to get as far as he did, and that's only cos he's a bonified genious. I won't mention the things he's done (because of the legal implications), but let's just say... he's no mere mortal man.
 
The servers that Andrew made on niotso.org contain all the code that the original TSO servers did. You could take this further actually but you may only get as far as the cities screen :( You can also edit the cities, TSO does allow that...
 
I'm surprised that Andrew has achieved all he has, extracting all the info about the city protocol from the game is an amazing feat. Only problem is that the full server includes a special simulator dll (+ null sound, video), which is not provided in any distributed client of the game, and will require remaking the entire game perfectly anyway to replace.

Recently I've been working on a Gameboy Colour Emulator webapp that runs on phones; right now it runs at full speed on iPhone 5S and iPhone 5 (only DMG gameboy games on 5, iOS 7 safari seems to fail running CGB games on 32 bit ARM...). The app abuses various web technologies to download and save ROMs (from user provided URLs) to a WebSQL database for easy, fast and potentially offline access to them for playing on the emulator.

No roms will be distributed with the emulator, however I'm probably going to contact the owner of CoolROM to see if he could allow cross domain access to his downloads server and add some extra messaging (window.sendMessage()) features to his mobile site, so that users could browse it and the site would return a link for the app to download from.

I haven't tested on android yet, so if any of you have an android phone I can post a link once I've set up controls that scale with resolution.

I'm nearly finished, so once I've got the whole thing working as intended I'll work some more on my TSO stuff. I like to keep things varied, and I didn't really enjoy writing the remaining parts of the UI Engine + linkage, which is why I decided to take a break. Hopefully SimAntics will be less tedious. :p

The first step for SimAntics is obviously planning out the structure that the simulator state will be stored in. I don't think there is any documentation for TS1's house format, so I'll have to base it off of the structure given in the Blueprints files. It looks like decoding the wall data will be trial and error...
 
Uhm, what? Walls are stored in *.wll files, which are IFF files internally. My Iffinator already contains code for rendering them, and I believe NIOTSO at least has code for reading 'em.
 
I meant the blueprint definition of where walls are, eg:

Code:
<wall level="1" y="29" x="22" brp="0" blp="0" trp="361" tlp="0" trs="1" tls="0" placement="0" segments="2"/>
<wall level="1" y="51" x="22" brp="0" blp="361" trp="271" tlp="0" trs="1" tls="0" placement="0" segments="8"/>
<wall level="1" y="52" x="22" brp="0" blp="0" trp="271" tlp="0" trs="1" tls="0" placement="0" segments="2"/>
<wall level="1" y="28" x="23" brp="0" blp="271" trp="0" tlp="0" trs="0" tls="0" placement="0" segments="8"/>
<wall level="1" y="29" x="23" brp="0" blp="0" trp="361" tlp="0" trs="1" tls="0" placement="0" segments="2"/>
<wall level="1" y="51" x="23" brp="0" blp="361" trp="271" tlp="0" trs="1" tls="0" placement="0" segments="8"/>
<wall level="1" y="52" x="23" brp="271" blp="0" trp="271" tlp="0" trs="1" tls="0" placement="0" segments="6"/>
<wall level="1" y="53" x="23" brp="271" blp="0" trp="0" tlp="0" trs="0" tls="0" placement="0" segments="4"/>
<wall level="1" y="28" x="24" brp="0" blp="271" trp="0" tlp="0" trs="0" tls="0" placement="0" segments="8"/>
<wall level="1" y="29" x="24" brp="0" blp="0" trp="361" tlp="0" trs="1" tls="0" placement="0" segments="2"/>
<wall level="1" y="52" x="24" brp="0" blp="0" trp="0" tlp="361" trs="0" tls="1" placement="0" segments="1"/>
<wall level="1" y="53" x="24" brp="0" blp="361" trp="0" tlp="361" trs="0" tls="1" placement="0" segments="9"/>
<wall level="1" y="54" x="24" brp="0" blp="0" trp="271" tlp="0" trs="1" tls="0" placement="0" segments="2"/>
<wall level="1" y="28" x="25" brp="0" blp="271" trp="0" tlp="0" trs="0" tls="0" placement="0" segments="8"/>
<wall level="1" y="29" x="25" brp="0" blp="0" trp="361" tlp="0" trs="1" tls="0" placement="0" segments="2"/>
<wall level="1" y="53" x="25" brp="0" blp="361" trp="0" tlp="0" trs="0" tls="0" placement="0" segments="8"/>
<wall level="1" y="54" x="25" brp="0" blp="0" trp="271" tlp="0" trs="1" tls="0" placement="0" segments="2"/>
<wall level="1" y="28" x="26" brp="0" blp="271" trp="0" tlp="0" trs="0" tls="0" placement="0" segments="8"/>

(excerpt from nightclub00_00.xml)

The part I'm talking about is the "segments" attribute, which might be a bitmap defining what shapes of wall lie on a space. (maybe something like 0101000 is left and top segments have walls in them, not really sure)

brp, blp, trp, tlp etc look like information defining the wall used, "br" meaning bottom-right, "bl" bottom-left, "tr" top-right, "tl" top-left. Not sure about those other two attributes, they seem to be set to 0 or 1.

If I make something to draw the data without resources, then I can mess around with the segments till I either find out that it's definitely not what I thought it was or till the walls line up correctly with a reference image of the job lot provided on tsomania.
 
I'm getting a weird bug where files are reading off my http server as empty... So I can't reinstall the game.
 
Nope, both my Apache and Mongoose HTTP servers are randomly serving files as of 0 length.
 
Back
Top