The "TS-adapted" (actually completely remade with an original model by LKO) war factories don't look bad, so we don't really mind them. If we switched to OpenRA we might still use the new WFs, actually.

The biggest benefits in the big picture are all the new features that we'd get; Iron Curtain and Chronosphere, gap generators, "proper" Chrono tanks, replays etc. We'd also be free from TS engine issues, like fairly unstable online play (sync errors, although multiplayer saves mitigate the issue to some point) and compatibility issues with the latest operating systems.

thehx

Posted: Tue Sep 19, 2017 3:51 pm Post subject:

Well, at least, with OpenRA, I think you'll be able to use classical War Factory assets, not the TS-adapted ones.

Matthias M.

Posted: Mon Sep 18, 2017 4:22 pm Post subject:

We could also make the map import rules.ini aware if more mods are interesting to switch engines.

Graion Dilach

Posted: Mon Sep 18, 2017 1:15 pm Post subject:

TBH if/when you start considering OpenRA seriously, you probably would need a custom map importer command since I assume you reorganized the overlay list (and some overlays need to be converted to actors like walls) and whatnot.

Lin Kuei Ominae

Posted: Mon Sep 18, 2017 6:34 am Post subject:

All maps and all the new terrain graphics would need to be made from scratch again.
That would be too much work.

thehx

Posted: Mon Sep 18, 2017 1:36 am Post subject:

Wouldn't it be better to switch back to square tiles instead of isometric ones, in case of using OpenRA engine?

Or is the decision mostly due to lots of assets already made for isometric TS mod?

Bittah Commander

Posted: Mon Sep 11, 2017 9:11 am Post subject:

Good to know. I'm looking forward to hearing how it works out.

Matthias M.

Posted: Sun Sep 10, 2017 6:48 pm Post subject:

Bittah Commander wrote:

Do the animations that are attached to most tiles with water also work?

Yes, UI skin is effectively painting in a PNG file and changing the layout often doesn't even require touching the C# code. The Red Alert and Tiberian Dawn mod use a different usability concept and art style yet they often share the same backend. The positioning of the UI elements is done in MiniYaml files stored in https://github.com/OpenRA/OpenRA/blob/bleed/mods/ra/chrome/ for example which may remind you how it is done with XAML for WPF applications or Mozilla's XUL. Those are stiched together with modular *Logic.cs chunks which give the buttons their function. It should be easy to grasp yet a bit fiddly to work with it.

Graion Dilach

Posted: Wed Sep 23, 2015 4:08 am Post subject:

Although ambientmusic ain't exposed to Lua atm, Media.PlayMusic("storm", recall-itself) at enable and Media.PlayMusic(null, null) at disable works okayish - which was the main reason I started that PR in the first place.

I wanted to elaborate on this, since it nicely demonstrates the flexibility of modding OpenRA, where it is possible to implement complex new behaviour by composing small reusable modules. Here is how you could go about implementing the ion storm and then extend the scope to also cover meteor showers / strikes and droppods. See https://github.com/OpenRA/OpenRA/wiki/Lua-API and https://github.com/OpenRA/OpenRA/wiki/Traits if you want more details on the specific things I mention (note: the traits list and lua api can both be extended by mods). This assumes a map-specific implementation using lua, but I imagine that we will eventually want to do this as a trait that can toggled in the lobby options and causes a random chance of an ion storm in any map.

When you decide to enable the ion storm in the map script (using one of N trigger types, for example):

Change the map lighting using the Lighting.Red/Green/Blue calls.

Define a global upgrade type which triggers any unit-specific behaviours:

Define a placeholder actor type which has a ProvidesPrerequisite trait that grants a "ionstorm" prereq.

Spawn an instance of this actor for each player using the Actor.Create lua call.

Use the upgrade to activate an instance of the KillsSelf trait on aircraft, DisableUpgrade on hover units, and so on.

Note: This is currently a lot hackier than it needs to be, and we will simplify this in the future by allowing an upgrade to toggle the ProvidesPrerequisite trait directly (removing the need for the placeholder actor type).

Enable the ambient ion storm track (don't have a lua API for this yet, since this is based largely on new code contributed recently by Graion Dilach - this will be fixed soon).

Apply an upgrade to the world actor that activates a trait that fires a weapon at a random position on the map at random times (don't have a trait for this yet). This weapon can have a custom projectile that renders the custom bolt effect (or just draws the unused bolt shp).

Once that works, there's no reason why you couldn't also implement meteor showers. This just uses the same random firing trait, but with a different weapon projectile that instead spawns a meteor (or a shower of meteors) instead of an ion bolt.

Once that works you can easily implement a meteor shower superweapon. Just replace the trait that randomly fires the meteor projectiles with a support power trait that lets you pick the target.

Once that works you can also do drop pods - just replace the meteor projectile with one that looks like a drop pod, and add a custom warhead that spawns an infantry when it detonates on the ground.

Out of all of these, the only things that couldn't be done in your own mod dll (and would therefore require us to do upstream engine changes) is exposing the ambient music API to lua and adding upgrade support to ProvidesPrerequisites. The engine exposes all the APIs you need for creating the random-firing trait, the weapon-firing support power (but we'll be adding this upstream shortly anyhow), custom projectiles, and custom warhead effects inside your own mod.

DTA uses a lot of TS engine features so I am not surprised. You can keep track of the implementation status from most gameplay mechanics at https://github.com/OpenRA/OpenRA/issues/7874 or the sub tickets where strategies to code them are exchanged.

That's exactly the list that I used as the source for our requirements list.

Matthias M. wrote:

If you want to speed things up, you will probably have to take some matters into your own hand: hobbyist Open Source is giving and taking or scratching your own itch. Before starting on your own it may be viable to discuss how to do it (as clean and quick as possible re-using existing trait logic) in the live chat. http://www.openra.net/community/

I'm a fairly experienced C# programmer and could probably code many things myself once I've studied the OpenRA code. That being said, before coding anything we'll have to figure out how to handle the transition, especially converting our in-game content like maps and missions.

Matthias M. wrote:

Even map.ini triggers to Lua prefab templates conversions are technically possible. A group of German students created a prototype in a few weeks. The auto-generated code isn't as readable as hand-written Lua scripts though, but it may be viable to get started.

This sounds promising.

Matthias M. wrote:

An engine change is a huge move and it will take a lot of time especially learning new markup languages and engine features as well as QA testing. However you also get the chance to create a game without ugly hacks and workarounds which I assume aren't easy to polish.

We're not afraid of YAML, but it'd indeed take a while to learn the engine and port over our existing content. Naturally, the benefit of OpenRA will be improved modding possibilities and resolved issues, like (the rare, but still occuring) compatibility issues with the latest operating systems and TS engine bugs like common sync errors in multiplayer with AIs.

Those videos have likely been old. The latest DTA versions don't really suffer from Z offset problems, but there's many videos of older versions that did suffer a lot from them.

Matthias M. wrote:

Another major benefit I see is cross-platform support. If you want to play on modern OSes and Linux/Mac niche it may be a viable choice. I guess you and your player base are mostly Windows users.

Yes, questions on how to run DTA on Linux and Mac are fairly rare. I personally think of cross-platform support as a bonus, not as a necessity. That will of course change if Windows market share drops significantly below 90%.

Matthias M. wrote:

As I am running Linux and the DTA screenshots were always very promising I had to get my hands on and make some initial experiments on my own. Hope you don't mind.

Nah, we appreciate it

Matthias M. wrote:

What you probably want is UPnP automatic port-forwarding (already possible, disabled by default) when behind a router or connecting to dedicated servers. The community runs some and we plan to improve that feature by popular demand. https://github.com/OpenRA/OpenRA/issues/7252

In that case, dedicated servers sound like the better way. I doubt our school routers handle UPnP port-forwarding due to security reasons. DTA has relied on CnCNet since 2011 and while we think that it'd be a shame to cut off the partnership (I'm actually one of key CnCNet staff myself), it won't keep us from porting DTA to OpenRA if OpenRA can provide an equally awesome multiplayer service.

Matthias M. wrote:

As far as I understand the Q logic, OpenRA vehicles already behave this way by default. You choose a target and they will continue to fire when you move them around. Their behavior is controlled by https://github.com/OpenRA/OpenRA/wiki/Stances which are cycled through by hotkeys. It is a long term plan to expose this to some sort of proper GUI.

Interesting. I didn't notice that during a game of OpenRA that I played recently, but then again, it was only a single short game and I wasn't concentrating that much due to the very slow (by DTA standards) game speed.

Btw, is the UI easily modified? I really prefer our current client UI (not only the style, but the design and usability too) over the current OpenRA menus, and I doubt I'm alone in this. If the UI is easily modified, it'd be another plus. The current OpenRA UI is too minimalistic and I feel that several windows are currently implemented better in DTA, like the map selection screen and the game lobby. For example, in your screenshot it looks like you need to scroll heavily on the server list since you can only see 3 games at once, I'd rather make it a list box with less info, similar to how it is in the current DTA/TI/YR CnCNet Client. If the UI is well done with proper window managers and controls and the like, I could re-design and / or re-write the UI myself if DTA is ported to OpenRA.

Matthias M.

Posted: Tue Sep 22, 2015 6:13 pm Post subject:

Manners please! Not sure why it escalated this quickly. I would appreciate a professional, objective on topic tone. No one likes overzealous fanboys. Also remember that you are a guest on these forums. It is the DTA area.

DTA uses a lot of TS engine features so I am not surprised. You can keep track of the implementation status from most gameplay mechanics at https://github.com/OpenRA/OpenRA/issues/7874 or the sub tickets where strategies to code them are exchanged. If you want to speed things up, you will probably have to take some matters into your own hand: hobbyist Open Source is giving and taking or scratching your own itch. Before starting on your own it may be viable to discuss how to do it (as clean and quick as possible re-using existing trait logic) in the live chat. http://www.openra.net/community/

As I have shown, Arts.ini and Rules.ini conversions aren't impossible, actually quite simple and automatic conversion with manual tweaking and cleanup can be a huge time saver. Even map.ini triggers to Lua prefab templates conversions are technically possible. A group of German students created a prototype in a few weeks. The auto-generated code isn't as readable as hand-written Lua scripts though, but it may be viable to get started.

An engine change is a huge move and it will take a lot of time especially learning new markup languages and engine features as well as QA testing. However you also get the chance to create a game without ugly hacks and workarounds which I assume aren't easy to polish. I noticed some visual mostly Z offset problems when watching DTA gameplay videos on YouTube. Another major benefit I see is cross-platform support. If you want to play on modern OSes and Linux/Mac niche it may be a viable choice. I guess you and your player base are mostly Windows users. As I am running Linux and the DTA screenshots were always very promising I had to get my hands on and make some initial experiments on my own. Hope you don't mind.

We probably will never and don't need to implement legacy deficiencies. CnCNet is a huge workaround. Tunneling LAN traffic through virtual networks isn't an efficient way. What you probably want is UPnP automatic port-forwarding (already possible, disabled by default) when behind a router or connecting to dedicated servers. The community runs some and we plan to improve that feature by popular demand. https://github.com/OpenRA/OpenRA/issues/7252

Something that is really great about CnCNet is imho the global IRC based chat feature for match making. Next release will feature exactly that integrated in-game. I am very keen on how it will be received. The UI isn't final and might change again:

As far as I understand the Q logic, OpenRA vehicles already behave this way by default. You choose a target and they will continue to fire when you move them around. Their behavior is controlled by https://github.com/OpenRA/OpenRA/wiki/Stances which are cycled through by hotkeys. It is a long term plan to expose this to some sort of proper GUI.

^Rampastein

Posted: Tue Sep 22, 2015 4:47 pm Post subject:

Quote:

And oh please. I've also put thousands of hours into AS in the last 5 years as well - how else could I achieve all that vivid colors I was famous for? Oh I did everything alone because I had no support for 4 years nor am I an artist/mapper nor am I a fan of debris - favoring experience more - that must mean you can dismiss everything I did.

Okay, your work of 5 years. Compare that to http://www.moddb.com/mods/the-dawn-of-the-tiberium-age/tutorials/credits - 38 people have contributed to DTA in some way. Bittah has worked on the mod since 2006, LKO since.. I don't know, I joined the staff in 2010 (although I've worked on things since 2008), and we 3 alone have each spent an enormous amount of time on the mod. There's also mappers like ChronoSeth, Drive and Stormrider who've each spent hundreds of hours on creating their maps. Then there's the rest over 30 people who've made all sorts of contributions, both big and small. I don't really like bragging about it, but it's rather clear that we're comparing projects of a different scale here.

Graion Dilach wrote:

I can actually help, but your demand list only came after you directly dismissed the skeleton mod.

I only stated that it might not be a good idea to try and port everything already before most of the things we need have been added already so that there's less chance that work that has been done will become obsolete (and thus become a waste of time).

In other words, porting DTA to OpenRA right now would be a very risky move from us. If the ORA staff suddenly decided that they're not gonna add the needed TS features or even basics like the game speed slider and right-click scrolling, we'd have done a lot of work for nothing. We'd rather wait until the necessary TS features have been implemented (provided that the OpenRA team continue work on the TS mod) and try porting afterwards. Another point is that OpenRA is a moving target - if we implemented something now, there's no guarantee that the feature won't be broken at some point in the future, generating us extra work.

Graion Dilach wrote:

You also shown no signs that you actually looked beyond that TS list. The fact is that you didn't even took a glampse and that shows. Everything beyond that are just excuses.

I expected the dev-made list to be up-to-date. Viewing it alone made it quite clear that there's a long road ahead for porting DTA to OpenRA. The specifics didn't (and don't) really matter that much, I was focusing on the big picture. The specifics are only important when actually creating / enhancing those features, since even partially implemented features like trains and jumpjets need to be implemented fully in any case.

Graion Dilach wrote:

Ah - and why shouldn't I be cynical? This is PPM afterall, the place where stupidity is welcome - and indeed, I was the stupid for actually thinking that the spotlighted mod is led by people who actually read beyond what they find.

I guess your presence here indeed proves your point about PPM To be more serious, there's stupidity in every community, even in the OpenRA community. Your choices are either ignoring it or trying to educate people. I tend to do both, although more of the first. Project Perfect Mod generally has a nice forum, especially since most flamers and trolls quit or got banned within the last half a decade.

Graion Dilach

Posted: Tue Sep 22, 2015 4:10 pm Post subject:

^Rampastein wrote:

For example, like jumpjets and train logic are taken from there, yet you're saying that they're already in. I wonder which is correct, you or the list compiled by other OpenRA devs.

And oh please. I've also put thousands of hours into AS in the last 5 years as well - how else could I achieve all that vivid colors I was famous for? Oh I did everything alone because I had no support for 4 years nor am I an artist/mapper nor am I a fan of debris - favoring experience more - that must mean you can dismiss everything I did.

The water is still a visual workaround - but I think that can be solved relatively easy tbh. All it needs is to unhardcode tileset palette - which sounded easy and actually Mig already asked for it and I wanted to do it for him anyway -, then DTA can use a second copy of the terrain palette (or one which has only coast/water colors) on water tiles alone which can rotate between the colors without affecting everything else. That can be batched even better if we say those tiles will be SHP - convert all tiles to 24-bit PNG, throw every tile into a single image in GIMP (Photoshop won't do, because it flattens the image during indexing), tell it to create a 256-colored image to it, reorder palette in GIMP, save result as PCX, copy out pal with Mixer, convert all old tiles to SHP with new pal, PROFIT - and issue solved.

I can actually help, but your demand list only came after you directly dismissed the skeleton mod. You also shown no signs that you actually looked beyond that TS list. The fact is that you didn't even took a glampse and that shows. Everything beyond that are just excuses.

Q-Move can be replaced with A-Move.

But alright, I consider this as the proof that you're only interested if such magic button gets made. Because pretty sure map scripting is a blocker.

Ah - and why shouldn't I be cynical? This is PPM afterall, the place where stupidity is welcome - and indeed, I was the stupid for actually thinking that the spotlighted mod is led by people who actually read beyond what they find.

^Rampastein

Posted: Tue Sep 22, 2015 1:11 pm Post subject:

Interesting. You're saying that many things in that list are already possible, while I took most items on that list from OpenRA's own "things to do for TS support" list available on Github. For example, like jumpjets and train logic are taken from there, yet you're saying that they're already in. I wonder which is correct, you or the list compiled by other OpenRA devs.

Other than that, LKO and Bittah have pretty much answered everything. DTA is far bigger than any of the mods that you're comparing it to. There's thousands of work spent on terrain, maps, the client, the AI, everything. Of course it's easy to port projects that have mostly got rules changes and some multiplayer maps, but DTA is not comparable to them at all. Just re-scripting all of our almost 40 missions and doing the required QA work to make sure they work as intended would take a lot of work, several dozen hours at the least. Of course I understand the benefit of LUA scripting over the trigger system, but it's not worth it if we have to essentially remake our mod's single player part.

It's also not worth it if our gameplay turned worse or significantly different from classic C&C because of the conversion. Q-Move for example is simply an essential part of micromanagement in RA1 and DTA, all the pro players (including us staff) are so used to it that it simply wouldn't be the same game without a similar option to control your units' movement and firing at the same time.

The list in this topic was created for transparency. Matthias M is or at least was clearly interested in assisting with a DTA port of OpenRA. To make it clearer what we'd need, I figured out that a list like this would be useful. If OpenRA gets capable enough, we will attempt a port and we're willing to put some serious effort into it, and also help the OpenRA devs in improving their engine. If OpenRA doesn't meet our requirements, then we will simply stick with TS. There's no need for any drama or hostility here.

I also agree with LKO. If you can't be polite and have to respond to everything in a cynical way, then please just ztype off. Your attitude isn't helping us, nor is it helping OpenRA.

Bittah Commander

Posted: Tue Sep 22, 2015 12:39 pm Post subject:

Graion Dilach wrote:

What I omitted is pretty much legit - which isn't much anyway. However some of these are so laughable that it makes me wonder if you're willing to adopt at all. Because I don't really think so. Infact, I imagine that devtalk as a "hurry, let's find obstacles to shut up OpenRA".

Exactly which of these are "laughable"? We'd gladly move to OpenRA, provided that for starters the gameplay experience won't become worse after the move (since that would defeat the whole purpose of moving engines in the first place) and second, we won't lose most of the work we've done already.
DTA already has a large number of multiplayer maps and also a good number of singleplayer maps that we obviously don't want to lose when we move to OpenRA. Also, a lot of DTA's maps make use of these "cnp'd fragmented tiles" you mentioned to create more detailed looking scenery.

Graion Dilach wrote:

For the record, Bittah's "pretty sure OpenRA will reach the demands of DTA earlier than other TS mods" statement is busted, CD and AS are pretty happy with the tradeoff. CD infact doesn't have any demands at all right now even - okay, maybe Bouncy alone - AS does, but most of them would be out of scope YR things which can be worked around or I consider minor nitpick anyway.

Unlike DTA, AS and CD aren't public mods that have been in development since 2006 with over a thousand hours of work put into them.

Graion Dilach wrote:

Look, I see you're not even remotely willing to adopt - Bittah's earlier "there's no point in learning OpenRA right now if it can't give us everything" answer along with this list where even your visual workarounds are listed to be ported back speaks for itself. On the other hand I'm pretty sure neither one of you actually looked into OpenRA features to think about the benefits of porting... but tbh I expected this and even foretold this weeks ago.

I never said that. I only stated that it might not be a good idea to try and port everything already before most of the things we need have been added already so that there's less chance that work that has been done will become obsolete (and thus become a waste of time). That doesn't mean we won't experiment with adding a few structures, units and weapons already, but we're not going to invest hundreds of hours of work in porting DTA to OpenRA before we know that it'll be worth it (especially when we still have plenty of work to do on DTA as it is right now).
Also, wat visual workarounds are you talking about?

Graion Dilach wrote:

You demand for a magic button to convert DTA, not a tradeoff. But then stand up and spit it out and you will be left for good.

When I said we'd be interested in moving to OpenRA once it has all necessary features, I said this knowing that we'd have to spend a lot of work to make this happen. Re-coding all units, structures and weapons would be acceptable, fixing up minor glitches made by the map converter would be acceptable, but expecting us to for example just ditch over 100 multiplayer maps, entirely re-script 30+ singleplayer and co-op missions or edit 800 tiles to make water animations work without cell anims is just unrealistic.

Lin Kuei Ominae

Posted: Tue Sep 22, 2015 11:39 am Post subject:

Graion Dilach wrote:

DTA having 31 active coders

fixed
Rampa: almost client programming work only and some mapping
Bittah: ini coding and all other stuff
Me: just some help/advice here and there.
see DTA's readme.rtf Credits shown on each Update/Bugfix line to get an impression what each one of us is doing.

And honestly, I considered any of you three enough competent to do it in the same timeframe if interested. Okay, I read fast, so make it half a day.

It might not have occurred to you, but - I'm doing AS alone (compared to DTA having 3 active coders), I have a bigger mod (6 sides compared to DTA's 4) - I didn't demanded more from DTA compared to what I'm doing. Hell, if you wouldn't be such a smartass and more open, I probably woulda jump onboard to help you catch that aforementioned skeleton mod Mailaender offered up to the TS mod's status.

If any of you three aren't interested just to take a quick glampse, then excuse me for actually bashing you after you reject a skeleton mod and only come up with a demand list.

Lin Kuei Ominae

Posted: Tue Sep 22, 2015 10:53 am Post subject:

Your post was almost very helpful, until the quote ended. Unfortunately you then had to ruin it by your typical bashing.

It might not have occurred to you, but it's not always for everyone possible to invest hours/days in a new project to find out all the possibilities.
A simple answer from a Dev with deeper knowledge about what's possible and what not, would have been enough. Even just striking through the done/wrong points in Rampa's list.

If you can't answer in a polite way anymore, then i would suggest you simply shut the up at all.

Graion Dilach wrote:

^Rampastein wrote:

Q-Move wasn't that an exploit to begin with?

It was/is a nice feature to give the player better control over his units. Especially since it's not only useful for attacking while moving, but also for setting a quick waypoint path (sending scouts at the start along a path across the map).

Graion Dilach

Posted: Tue Sep 22, 2015 10:35 am Post subject:

^Rampastein wrote:

Automatic map conversion works 90% of the time, I have a feeling maps having cnp'd fragmented (single tile pasted from a multitiled tmp) tiles makes it crash

More control over some AI aspects (squad composition, probability of squad type, etc.). Automatic converter for AI(E).ini wouldn't hurt either OpenRA AI ain't even remotely similar to TS AI, this is likely not gonna happen

Trees catching fire: https://github.com/OpenRA/OpenRA/issues/6403That's a misleading issue. The shipped mods use invulnerable "buildings" as trees, so slapping health, armor to them and done. Burning can be simulated by giving them a burning animation and a negative selfhealing upgrade which is granted by the warheads "litting them up". This upgrade could even grant a closerange weapon for trees to attack other trees, simulating spread

Jumpjets (might be doable with existing logic) OpenRA jumpjet logic >>>>> YR jumpjet logic already, thankyou, it can do everything YR did, except without relying on OmniFire all the time

Q-Move wasn't that an exploit to begin with?

Potentially essential:

Train logic: https://github.com/OpenRA/OpenRA/issues/2652That's not your train logic. TS trains are already possible with the same limitations like in TS (spawn them via Lua, they are independent etc) . That issue means ZH trains.

If the current client is ditched, then we need to improve the current OpenRA menus to be more similar to the nice DTA menus only the contents of the UI are hardcoded - as in, it must have all the buttons and options somewhere, the visuals are completely customizable

Not that essential, but would be nice to have:

Small visceroids fusing to a single large one can be done: small viscs can be crushed by each other, crushing a small visc grants an upgrade to crusher, smallviscs use this upgrade to change art to large visc, boost weapon, damage resistance etc, I did ZH Salvage this way with unit husks

What I omitted is pretty much legit - which isn't much anyway. However some of these are so laughable that it makes me wonder if you're willing to adopt at all. Because I don't really think so. Infact, I imagine that devtalk as a "hurry, let's find obstacles to shut up OpenRA".

For the record, Bittah's "pretty sure OpenRA will reach the demands of DTA earlier than other TS mods" statement is busted, CD and AS are pretty happy with the tradeoff. CD infact doesn't have any demands at all right now even - okay, maybe Bouncy alone - AS does, but most of them would be out of scope YR things which can be worked around or I consider minor nitpick anyway.

Look, I see you're not even remotely willing to adopt - Bittah's earlier "there's no point in learning OpenRA right now if it can't give us everything" answer along with this list where even your visual workarounds are listed to be ported back speaks for itself. On the other hand I'm pretty sure neither one of you actually looked into OpenRA features to think about the benefits of porting... but tbh I expected this and even foretold this weeks ago.

You demand for a magic button to convert DTA, not a tradeoff. But then stand up and spit it out and you will be left for good.

^Rampastein

Posted: Mon Sep 21, 2015 9:47 pm Post subject:

After discussing this with the rest of the staff, we decided to list things what we'd need from OpenRA for a conversion to be viable. This might very well not be a complete list, since I'm not that familiar with OpenRA and it might be missing several logics that I'm forgetting about.

Essential:

Trigger system and/or automatic conversion for map triggers (need to investigate how to OpenRA map scripting is done to determine if needed)

How does ore and tiberium currently work in OpenRA then, if it's not overlay?

^Rampastein

Posted: Sun Sep 13, 2015 10:14 am Post subject:

That looks very nice. Not only my map, but the automated conversion too

Global lighting ( [Lighting] ) doesn't seem to be converted btw.

I'm becoming more interested in checking out the modding capabilities and code of OpenRA, although I'll still wait for the game speed slider to make its appearance.

Matthias M.

Posted: Sun Sep 13, 2015 10:08 am Post subject:

I created a simple Art.ini and Rules.ini importer which generates some OpenRA MiniYaml rules that mostly work out of the box. This is really useful for mods with lot's of assets.

It even makes some correct guesses about which palette to use. Might do building overlay auto conversion next.

Lin Kuei Ominae

Posted: Sun Sep 13, 2015 9:02 am Post subject:

Wow, this looks very promising.
Thank you for your initiative Matthias

I can't wait to create a triple turret cruiser which can use all 3 turrets even when moving (DTA's has to deploy)
If i'm not mistaken, even a cruiser with 3 triple barrel turrets and 6 independent twin flak turrets would be possible in OpenRA.

Matthias M.

Posted: Sun Sep 13, 2015 8:00 am Post subject:

The indices are freely configurable since https://github.com/OpenRA/OpenRA/pull/9103 so you are not limited to the "RA palette scrolling method" but I agree that doing those probably takes a lot of skill and time.

Oh no... Water colors... It is a pain to too keep them from being mixed up when doing new theaters for RA1 but doing water color from scrach wow that is NOPE.

Bittah Commander

Posted: Sun Sep 06, 2015 3:54 am Post subject:

I already assumed that'd be possible, but because of how the process of making or editing terrain for TS works (which is by creating or editing the tile in an image editor and then pasting it into the the TMP editor), DTA's tiles with water don't use proper color indexes that'd allow this palette animation.
The problem is that the TD and RA palettes have 2 pairs of identical colors among the water colors and while DTA's terrain palettes initially had the 2 identical pairs of blues among the water colors as well (they don't anymore), the secondary colors from those identical pairs ended up being entirely unused while creating the terrain because the TMP editor automatically always only assigns the first color on the palette that matches when you paste a tile into it.

So what this actually means is that water animations will then end up looking similar to this:
or at best like this That's my first and second attempt at making water animations for DTA in case you were wondering (although the second was edited in several ways and animates fewer colors, meaning that the result in OpenRA would look far worse than that), which I did by exactly simulating TD and RA's "palette scrolling" method.
So as you can see, instead of making water look like a constant stream, it makes it look like it's constantly blinking on and off.

While in theory it might be possible to edit all tiles and replace the colors in order to get a decent looking water animation via the palette animation after all, DTA's palettes first of all now lack 2 necessary colors for this (the secondary ones of the identical pairs I mentioned) and even if they did have these colors, DTA currently has exactly 796 water animation files, which would mean I'd have to edit exactly that amount of TMP files one by one to get this done. So as you can surely understand, it'd be an impossible job.

Maybe if the palette animation could somehow be modified for DTA so that the 2 water colors that originally had an identical secondary version on the palette would somehow be interpreted to be the first or secondary one for every other pixel and the colors all properly alternate while following that logic, there's a chance that a palette animation could look good (but even then I'm not entirely certain).

pchote

Posted: Sun Sep 06, 2015 12:42 am Post subject:

Bittah Commander wrote:

Do the animations that are attached to most tiles with water also work?

I can't check this (the DTA wrapper appears to have issues under Wine), but if you're using overlays to emulate the original water effect then that is not necessary in OpenRA. You can use a proper palette animation instead.

Bittah Commander

Posted: Sat Sep 05, 2015 9:21 pm Post subject:

Don't expect a public version before at least all features in DTA's current public version are possible however and I expect that'll still take a good while.

Darkstorm

Posted: Sat Sep 05, 2015 8:45 pm Post subject:

If this mod gets ported to OpenRA, I can only imagine the crazy things that could be added.

Bittah Commander

Posted: Sat Sep 05, 2015 12:43 pm Post subject:

Experimenting with it for a bit to get a hang of how the coding works could be interesting, although I expect that the actual coding would have to be revised several times because of changes in the engine before everything the mod requires from the engine has actually been implemented.
So with that in mind it's probably not a good idea to spend a lot of time on the things I implement already (and implement full factions and with weapons and everything) before I can be sure that they won't need to be revised later on.

Matthias M.

Posted: Sat Sep 05, 2015 12:07 pm Post subject:

Nevermind, it was just me not paying attention. Everything works as it should once I fixed the tileset importer:

Are you interested in this? I could setup a stub mod with actor and resource rendering working as well to get you started.

Bittah Commander wrote:

Do the animations that are attached to most tiles with water also work?

We haven't implemented TS terrain animation overlays yet.

Bittah Commander

Posted: Sat Sep 05, 2015 11:43 am Post subject:

That was quick. I didn't expect it to be doable this quick (considering there's quite a lot of terrain in DTA and I expected the conversion to be somewhat complicated).
Do the animations that are attached to most tiles with water also work?

The palettes are in Cache.mix. I attached a zip file with all palettes you should need below.

Matthias M.

Posted: Sat Sep 05, 2015 11:31 am Post subject:
OpenRA dta mod

I made a quick terrain import test:

which looked very promising.

Just having some trouble finding the correct palette for the isometric desert terrain.