@SIMGURUMODSQUAD : Converting pyo files to py

If it's a company rule or licensing issue that's preventing EA/Maxis from releasing raw source code, I'd assume that giving clear instructions how to retrieve the python code (even just for reading) from the pyo files would be in violation as well, which is unfortunate, but probably not something that SimGuruModSquad can change.

I hope Easy Python Decompiler works (I downloaded it, but won't get the game until Thursday, so I can't test it for now).

The problem doesn't seem to be that most decompilers won't work on Python 3.3. The problem seems to be that none will. This makes it sort of difficult to do anything except stand around saying I'd like to get at that code but there's nothing that will decompile it.

ETA: Python 3.3 was released in 2012 and, apparently, in the years between then and now no one has managed to make something publicly available that will decompile it. This is sorta something that doesn't fall in the realm of modding a game. A person modding a game isn't going to be able to make a decompiler for this. Any suggestions EA?

"MyreMylar;12531010" wrote:
Where are you guys getting these compiled .pyo files from? Are they hidden in one of the CAS demo packages?

Sims4/data/simulation --> zips.

So it's just as I suspected. They want to appear as if they are more willing to help modders when in reality they are limiting and controlling us as best they can. Why pyo files? Probably part of the decision was that it would be very difficult for us to get at the source. I'm not surprised.

I've also tried unpyc3. Problem with marshalling. Doesn't work. I'm looking at pyREtic-master but haven't tried it yet. Not easy to set up.

Thanks EA, for nothing.

I'll find a way, or I'll stop being a supporter and avid fan after 10 years.

Did you try the method at the end of this thread?

http://www.modthesims.info/showthread.php?t=532279&goto=lastpost

The posters seem to be reporting good results on the Sims files with the modified unpyc3.py.

.pyo files skip the interpreter's translation step.

We have a modified version of unpyc3 that is decompiling most of the pyo files in the simulation.zip file. Not sure how accurate they are. But it displays most if not all of the script. So now we can wait for the documentation on how they would like us to do it. Hopefully it means that we can use their methods on more data than just what they would like us to be able to play with. And since I have no plans to try to replace a game pyo file, complete accuracy might not be necessary... At least not initially. :)

As a programmer myself, I love seeing that I'm not the only one who subconsciously lowballs expectations.

Boss: "Can you do X?"
Me: "No, that's physically impossible."
Boss: "I'll ask again in an hour."
Me: "But it's literally impossible. Can't be done. The very laws of computers, programming, and even physics disallow it. We'll have to do something else."
Boss: "Un-hunh".

*one hour later*

Boss: "Can you do X?"
Me: "I thought about it, and figured out a way to do it. I'll have it done today."
Boss: "You do this every plumming time."

"Maclimes;12543983" wrote:

"Spiceweasel;12543934" wrote:
But truthfully, I consider giving accurate estimates an important skill as a developer. It takes experience, but too many people just shrug it off, saying "I suck at estimates" without ever trying.

Fair point! It's something I'm working on. ;)

In many shops, giving an overly low estimate or an overly high estimate can really slow down the process :smile:

In our shop, we have one guy who always answers "30 to 60 days" for a new feature, no matter how trivial. We have another that says "Give me an afternoon and I'll have it ready." Neither of them get asked for estimates much anymore.

Update my script posted in the ModTheSims thread probably for last time as game is close to release. I've been able to use it fairly well with a properly configured Intellij for browsing the source. I suspect that is enough for most modders to get by for a while. Surprisingly only had to create about a dozen stubs that are probably the C++ classes in the engine to load the code in python which means that they skewed toward a lot of the source in python files rather than just exposing wrappers which is likely good for modders.

Regarding time estimates, I only expect someone to give a reasonably accurate estimate if its an activity they have done before. Too often I'm asked to estimate something like "How long will it take to create a dashboard for tracking convoluted company metric x?" but without any of the useful stuff like what visualization tool do you want it in and where is the data and what is x anyway?

Edit: Doesn't seem like the most popular thread but some findings on the hot reloader (maybe this should be its own thread). Looks like it will not be enabled by default event if __debug__ is True as we are loading from zip files which sets SCRIPT_ROOT to None where that variable controls the root folder for reloading. I suspect some monkey patchable may be sufficient to troubleshoot stuff in the future but not out of the box. Some interesting files for those that are interested: core.zip\paths.py, core.zip\sims4\core_services.py, core.zip\sims4\core_services.py. Looks like user script mods will load from either zip or as loose py files though only the later are reloadable.

I actually cannot determine how user scripts are loaded at the moment as it looks like it uses USER_SCRIPT_ROOTS which currently is pointed squarely at core.zip. Some other zip files that are of interest are the tests.zip, debug.zip, lib.zip, build.zip which might be usable to bootstrap loading custom scripts since they do not exist in the deployed game. Hopefully I'm just overlooking something obvious but looks like they expect either all source files or all zip files and not a mixture. That might be reasonable for the developers but my not be so good for us. I'm sure that they will help out when we starting hitting these blocks.

User scripts go into Documents\Electronic Arts\The Sims 4\Mods\Scripts as zip files. No clue to structure.