PA Alpha Build 51531

It is totally enough for "small" extensions like 99% of the UI mods we currently build. Before the new system I had to update my mods every time a patch was released. With the system they just kept working. I'd say that IS a pretty huge improvement. Sure it may not be super fast, but most UI mods won't really need to be super fast. Also this just the first take on the system, we are in alpha after all.
If you want to make a super huge total conversion something, than feel free to ignore the system and just replace everything. I doubt any mod system will be able to handle really big changes in an elegant way without having serious drawbacks.

I agree with the sentiment, but yeah, you could do with toning down the hostility. It isn't going to make you friends, and while you're evidently pretty damned competent, there may come a time when you want to have a team of people to work with.

Or not, ya know.

I am one of the few guys that knows pretty much everything about modding Dawn of War these days, but I don't rub it in peoples' faces when they do it in a different way. I moan about it to my friends on Facebook or the like instead

As a developer, I'll take any system I can get. Even if it's not perfect right now. Even if it's only rudimentary support. As a long-time games modder, anything is better than nothing.

Ahh, work finished. Let's continue this shall we?

From what I can tell, the biggest issue is supporting mutlitple mods in one HTML file.

Case study:
------------
Yourlocalmadsci writes an in game mod which gives the user greater understanding of the player's economy. This requires some alteration to the live_game.html template. It contains its own css and javascript files.

Sneakyness writes an in game mod which add a timer to the game interface, it also makes a change to live_game.html. It has its own JavaScript file.. well it would have if it were done to industry standards

Both these guys decide they want their mods to be useful to the community but don't wish to be bothered with endless requests like "Sneakyness, can you please make your fantastic mod compatible with yourlocalmadsci's spectacular mod?"

Uber have already solved the javascript/css issue, although maybe not in a way to some people's liking. What I might suggest to improve this is to have the engine spit the mod's javascript/css include files out in the markup engine side instead of in the javascript. The new HTML headers would look something like this:

Code:

<script src="live_game.js" type="text/javascript"></script>
<%=$registeredModJavascriptIncludes %>

<link href="live_game.css" rel="stylesheet" type="text/css" />
<%=$registeredModCssIncludes %>

Now the tricky part, Yourlocalmadsci has completely changed the eco bars and wishes to remove Uber's markup altogether with his own. Whereas Sneakyness wants to add a DIV above the player's names. Does Uber utilize some kind of "engine side" DOM manipluation language to do this? - sounds more complex than it's worth. Do they break up the page into obvious fragments which can be overidden, and scatter placeholders like the css/js ones above which people can hook into? - sounds better but maybe not so flexible

This second part I don't know a good solution to, but jQuery does the trick, and the overhead is only on page load. Loading the mod's markup via an AJAX call like I mention before doesn't affect debugging complexity because the javascript is in one place loaded through Uber's implementation.

This is only a specific example. If you're writing a mod which you don't intend to be compatible with other mods then there's no issue. You can just re-write the HTML file and hopefully Uber will provide a nice way to override it like neutrino said is coming down the pipe.

Mind = blown. So I wouldn't have to explicitly distribute my mod? it would just auto-update every time someone played online? WOW. I can see a problem if the online server isn't available (say, you're playing MP at a disconnected LAN), but an IF statement should fix that for a local cache...

I doubt that is currently possible, but it sounds like an interesting option. Even though I personally don't think that would be very reasonable, as many people probably won't like the idea of having their UI loaded from a source that may change without any notification.

EDIT:
so out of curiosity I tried putting the whole ui of PA on a webserver and started PA with the UI pointing at it, I renamed the ui folder on my local machine.
It loaded for some time and worked partially. The cursor for some reason stayed black and ingame the actual game was not displayed. Dunno why.
I didn't investigate further, maybe just dropping the whole ui directory and serving it from an apache isn't optimal.

I just wanted to drop a few notes into this conversation regarding mods:

1 - The current mod support is very work in progress. More features are on the way, including broader feature support. Specifically, 2 relevant features we are discussing: appending directly to a source file (.css & js), and completely replacing any given file. Both of these will require C++ support, and using either of them will be discouraged. This is primarily because we expect full-override mods to be more likely to break between builds. (As an aside, with the support that showed up in this build, it's hard to argue that the append support is even necessary. That's a great example of why it's good to implement some of this stuff in stages.)

2 - We are definitely planning a mod manager, implemented as a first class feature of the game. There should always be an easy, reliable way for our users to return to stock behavior, for a lot of reasons. The above-mentioned resource overriding features will be integrated into this manager, allowing for possible features like conflict resolution, templating or whatever other crazy stuff would work better from a native code implementation. Direct integration with a mod repository might make more sense with a native implementation, for example.

3 - The current mod support provides a hook for mods to update the model before it registers with the game. For small mods, using this mechanism should make it much, much easier for your mod to work reliably. (Remember, we're updating the game regularly, and we expect users to use more than one mod at a time.)

4 - The resource bar update performance is tied to a very low level issue. It's not going to be fixed soon, because doing that will depend on other fixes that are in progress. It will, however, be fixed.

For those who are interested in the low level issue on that last item: This happens because UI updates need to be transferred from the Coherent host process to our local process. Right now, we only have a single view for the entire UI, which means that those tiny constant updates need to transfer the entire frame buffer. We are currently in the process of changing over the back end of our UI from its current state (a limited feature set that was fast to implement and helped us explore game design ideas) over to a more robust systemic API that will be provide more flexibility. Once that is in place, we should be able to move smaller dynamic updates to their own view and perform the compositing in our own OpenGL context. This is not an easy change to make, and it's going to take a while for it to be ready.

Thanks for being such a passionate community. It sounds like cheesy marketing double-speak, but your feedback really is helping us shape the future of our game. (Even if it can get a bit hot in here sometimes. You obviously care, and we like that.)

Thanks for that answer, it's very interesting.

EDIT: the load UI from the web option is actually interesting for a completely different aspect I think: I can basically backup my whole UI on the web and use it from anywhere. So I can visit a friend and play with my usual UI. Even though I wonder about the storage of settings and stuff, as a webserver is usually read only.

Host the webserver in a vm and enable read/write :3 or maybe make it have an IP whitelist that you can easily edit and add the computer you're using via ssh, or remote desktop

This is some groundbreaking, innovative, and possibly revolutionary design you guys are working on. I'm excited not just for the future of this game, but for the possibilities this could open up to other games that decide to take a similar approach.

I am in awe.

Thanks for the update, the future sounds promising

Agreed. Why would you ever need to append to a css file when a second css file can override core declarations anyway? I can't imagine any need to do this with JavaScript files either.. but there might be something I haven't thought of.

p.s. And thanks for the new "lite" web browser

Code:

PA.exe --uiurl http://www.google.com

this is the exact thing I've been thinking about ever since i backed up this game.

Heh. I don't know if "lite" is quite the right word considering the install size...

LOL. OK, I tried some flash and HTML 5 games, but I couldn't get them to load.

What kind of a web browser is this? It's one that passed the freakin' ACID 3 test with 100/100, with smooth progress! The only problem is that it displays "You should not see this at all" in the upper left. Pretty respectable!

I haven't explored the modding forums much, so maybe the answer to this is in there. But what web browser is built into this? A webkit-based one?

Webkit = correct. Basically for the ui/menus.

Coherent UI based on Chromium codebase. It's Chromium for 99% so it's use webkit, have WebGL support and javascript runned with V8 engine.

So you get exactly same performance and functions you can get in latest stable Google Chrome. There are few limitations, but they're very small: e.g devices API not working, and I also won't able to enable WebRTC.

Lite on browser features, heavy on AWESOME FEATURES

more units, when are you going to add more units and I am not talking about the orbital or space stuff, I'm talking more tanks, bots and strange characters.
Its getting kind of boring playing with just 2 tanks and 2 artillerly. :mrgreen:

Well you shouldn't be expecting play value out of an Alpha, the units works so they're focusing on more fundamental stuff like the system editor, Orbital units and interplanetary gameplay. Those are just ever so slightly more important right now.

Mike

What Mike said. Adding units is amongst the easiest thing to do once everything is working properly. It's building out the systems that the units use that's the hard part. We still have some major systems in progress.