a multiplayer game of parenting and civilization building
You are not logged in.
Pages: 1
Has anybody thought of adding stand-alone modes into the vanilla game in a modular fashion?
Think of it as a monkey patching if you are familiar with Python or JavaScript.
I really like:
zoom functionality of the Awbz mod (the UI scales with zoom),
WASD moving and Q for backpack of the hetuw mod (the UI does not scale with zoom),
object-search of the JastinLove/Wondible mod (neater than the hetuw mod's object search).
What would be awesome is to put parts from the mods into the game directory and perfom monkey-patching during run-time of the vanilla executable.
Thereby avoiding merging with the Jason's branch and compiling.
What about the PXshadow mod, can it accomplish such modularity?
Offline
I think PXShadow was aiming for a modular design, though at one point they were considering a commercial client on an open core, and currently I think PX is more interested in a forked game than a client for onelife.
My changes are organized as patches to keep features together; the don't end up completely independent and I try to keep things on features switches so it's user configurable.
Even with patches it has to be compiled. I don't think anybody has looked at dynamic hooks; the game updates weekly. I think it does ship with debug information which might make it possible to locate function entry points; I'm not actually sure how fine-grained it could get.
https://onemap.wondible.com/ -- https://wondible.com/ohol-family-trees/ -- https://wondible.com/ohol-name-picker/
Custom client with autorun, name completion, emotion keys, interaction keys, location slips, object search, camera pan, and more
Offline
Hey sorry for the delay in response, I wanted to come back with you with something substantive.
What would be awesome is to put parts from the mods into the game directory and perfom monkey-patching during run-time of the vanilla executable.
Thereby avoiding merging with the Jason's branch and compiling.
Yes OpenLife is quite modular and you can do monkey patching quite well for everything besides the rendering component right now, It also allows an easy to use relay system so you can connect whatever client you prefer i.e hetuw with zoom mod, wasd. Connect the client to the relay and the relay connects to the server and sends messages back and fourth while being able to read and write messages.
I also have some experience monkey patching for assets and some code for that, but that's for another time.
I also agree with wanting to avoid Jason's branch and compiling and it was one of the motivator to attempt to make a more Open ecosystem for OneLife moding/utility clients server hence OpenLife.
Has anybody thought of adding stand-alone modes into the vanilla game in a modular fashion?
Think of it as a monkey patching if you are familiar with Python or JavaScript.
In order to give more credence to the idea of monkey patching in those types of languages I took a few days to finish the export target nodejs and release a npm package for it here: https://www.npmjs.com/package/openlife
I am biased towards using Haxe so I'd recommend trying it but one of the nice parts about it, is that it can compile to Javascript, Python and many more so I decided to put some work on allowing this modular idea in javascript first, here is my current example of using the engine. And I'd be more than happy to help foster this modular modding ideas for clients/bots etc
PXshadow#9132
Senior full stack developer
Offline
OpenLife sounds awesome but it looks a bit overwhelming. Are there simple examples showing the workflow? Say, I have two basic parts of C++ code: one registers Q to access backpack, the other uses E to eat. How can I combine these and embed into OpenLife and the OHOL vanilla executable?
Offline
Are there simple examples showing the workflow? Say, I have two basic parts of C++ code: one registers Q to access backpack, the other uses E to eat. How can I combine these and embed into OpenLife and the OHOL vanilla executable?
For vanilla you'd have probably to rewrite the command sending; it's intertwined with the click handler. I've tried to keep features in somewhat separate feature patches, but the main keyboard interface is one patch, and it depends on another patch that extracts all the command issuance as separate functions for easier use.
I'm using stacked git to manage my patch set. I haven't done a lot of individual import-export, and I'm not actually that sure that it would work exceptionally well for piecemeal patch juggling.
https://onemap.wondible.com/ -- https://wondible.com/ohol-family-trees/ -- https://wondible.com/ohol-name-picker/
Custom client with autorun, name completion, emotion keys, interaction keys, location slips, object search, camera pan, and more
Offline
If you're planning to do c++ modification to the source, then it's probably not worth it to make a bridge into OneLife vanilla client (Hetuw client on the other hand is quite straightforward for keybinds) and I would agree with wondible that his patch method is better for that. However if you don't want to deal with compiling the vanilla client or server for that matter, and even having the possibility of not even compiling yourself and having a module script system. Than OpenLife is the best option, and will give you clean and concise events according to the protocol spec, the same naming convention, client and server commands etc. OpenLife will stay a separate competing instance to implement the protocol, in the future I would like to finish a visual client that uses OpenLife but currently it's not nearly finished enough to say it's an option right now, but that would make modular modding of every part of the game possible.
So if you want to help on the the Modular Modding front and have it be a possibility sooner, let me know, I have a few devs working on various different fronts of the project (bots/server/client), if you want to make this a possibility I'd be happy to talk more. my discord profile is in the message footer.
PXshadow#9132
Senior full stack developer
Offline
Pages: 1