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.
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. _________________ QUICK_EDIT
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. _________________ QUICK_EDIT
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. QUICK_EDIT
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). _________________ QUICK_EDIT
Joined: 13 Feb 2007 Location: C:\Westwood\ TechLevel=12
Posted: Sun Sep 06, 2015 5:22 am Post subject:
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. _________________
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.
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. _________________ SHP Artist of Twisted Insurrection: Nod buildings
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. QUICK_EDIT
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)
Carryalls (could potentially be rendered obsolete by working vehicle transports and infantry transport helicopters, but would still be nice to have): https://github.com/OpenRA/OpenRA/issues/8954
Particle effect system (damage/wielding sparks, railgun, gas clouds, smoke)
If not the above, then the current client will be used and spawner support is needed
If the current client is ditched, then we need to improve the current OpenRA menus to be more similar to the nice DTA menus
CnCNet tunnel support (OpenRA's P2P might make it impossible to play / host games for some people behind unconfigurable routers, like me in my studying apartment)
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
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
Trigger system and/or automatic conversion for map triggers OpenRA uses Lua for map scripting. If you cannot understand the benefits of that, let's stop here. All map objects - including waypoints - are converted already though.
Laser Fence Logic. This one might not be that important if walls can be cloaked properly in OpenRA. They can be cloaked, yes. Also https://github.com/OpenRA/OpenRA/pull/9270 will make that old PR redundant
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
Significantly improved Pathfinding performance (DTA unit counts are often higher than OpenRA unit counts) that's done already
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
Hospital (hurt inf goes in, exits healed) see https://github.com/OpenRA/OpenRA/pull/2230 for a way, although IMO this was useless, shipped mod hospitals work like in YR instead
Tiberium fiends logic (run to Tiberium and lay down to heal) running part isn't done, PoisonedByTiberium can have negative damage
Ion Storm disabling actors: https://github.com/OpenRA/OpenRA/issues/7874Ion Storm requires map Lua imo and that can grant/revoke mapwide disabling upgrade, what ion storms, meteors need is pretty much a Lua function "fire weapon randomly around map with this intensity" pretty much
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. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
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 ztype 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). _________________ SHP Artist of Twisted Insurrection: Nod buildings
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. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
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. _________________ SHP Artist of Twisted Insurrection: Nod buildings
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. _________________ QUICK_EDIT
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.
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
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. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
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.
We haven't "dismissed" it. Bittah already answered that point quite well:
Bittah Commander wrote:
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. _________________ CnCNet Client | CnCNet TS patches | More Quality-of-Life Improvements for RA Remastered
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. QUICK_EDIT
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.
Matthias M. wrote:
I noticed some visual mostly Z offset problems when watching DTA gameplay videos on YouTube.
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. _________________ CnCNet Client | CnCNet TS patches | More Quality-of-Life Improvements for RA Remastered
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Tue Sep 22, 2015 9:24 pm Post subject:
The UI is entirely mod code. Which means if you don't like the limits of the current widgets you're free to write your own and ship it in a custom mod dll. However the shellmap must stay - https://github.com/OpenRA/OpenRA/wiki/Traits-%28playtest%29#loadwidgetatgamestart tells why. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Ion Storm disabling actors: https://github.com/OpenRA/OpenRA/issues/7874Ion Storm requires map Lua imo and that can grant/revoke mapwide disabling upgrade, what ion storms, meteors need is pretty much a Lua function "fire weapon randomly around map with this intensity" pretty much
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. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
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. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
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. QUICK_EDIT
All maps and all the new terrain graphics would need to be made from scratch again.
That would be too much work. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
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. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
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. _________________ CnCNet Client | CnCNet TS patches | More Quality-of-Life Improvements for RA Remastered
learned about dta today (through PCGamer) and was instantly interested. Reading about a possible "merge" with OpenRA would be a huge thing, since I love it. We still have regular small sized LAN parties and OpenRA is a usual game played by most of us. Would be great to have it as a mod option, too
While this topic got back up, any news from the experienced OpenRA people about the current status?
I've seen huge improvements from the few OpenRA news posts that i've checked.
I have the feeling that a move to OpenRA now, would already mean a lot more to gain for DTA than to lose (unlike 2 years ago when this topic started).
Which crucial key logics are still missing for a conversion? _________________ SHP Artist of Twisted Insurrection: Nod buildings
I don't know what DTA's actually using so I'm gonna list generic stuff which I believe you guys would depend on. Just the tip of my head.
Code existing in thirdparty codebases but not in main OpenRA:
cluster/shrapnel weapons (take note that OpenRA doesn't have animation debris, you need to use chained weapons instead)
particles (I have a crude code for smoke but it can't be triggered by warheads at this point, only on actors and lack ambientdamage, also I have code for SHP railgun, also I'm using shrapnel weapons to simulate damagesparks)
meteors/ionstorms
allowing AI to build specific actor clones (preloaded transports basically)
Stuff missing without thirdparty solutions
destructible high bridges - high bridges are tunnels in the sky atm
railgun delivering both damage and ambientdamage at the same time
veins as alternative resources
sensor arrays
a worthwhile AI
resizing playable area of map on the fly (that map script which enables a mission to expand the map) QUICK_EDIT
If I remember correctly, pchote recommended that we should wait until the TS mod is finished before attempt porting DTA to OpenRA, which does seem like the best plan if we don't want to have to constantly keep fixing and rewriting code whenever features get changed or added.
Splitting missiles are currently mostly used for work-arounds to make units fire multiple projectiles at the same time, so assuming that OpenRA makes that directly possible by the time the TS mod is finished (if it's not possible already), we at least won't have to wait for a Firestorm mod to also implement splitting missiles (although I would like to see an lobbed/arcing missile that's able to split at the end of its arc, but that unfortunately isn't possible with the TS engine either). _________________ QUICK_EDIT
hi, like the eyecandy smoke coming out of the stacks at ra pp and ref, would like to port them over to OpenRA if its possible. maybe you can provide a few pointers as on if its currently possible to do and if so on how to do it. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Feb 16, 2019 8:39 pm Post subject:
Bump, because I'm bored enough.
^Rampastein wrote:
Essential:
Trigger system and/or automatic conversion for map triggers (need to investigate how to OpenRA map scripting is done to determine if needed) Still Lua, still no automatic converter.
Carryalls (could potentially be rendered obsolete by working vehicle transports and infantry transport helicopters, but would still be nice to have): https://github.com/OpenRA/OpenRA/issues/8954In.
Particle effect system (damage/wielding sparks, railgun, gas clouds, smoke) My AS fork got this one covered - although I use sprites for the 1x1 sparks too and see no need for actual spark effects. Regardless, AS still allows every particle modding trick recreated.
Improved Laser effects: https://github.com/OpenRA/OpenRA/issues/8009AS got the KKND lasers which covers this if default ORA lasers ain't good enough - combining the former with AS AthenaProjectile can even be used to remake the TS ion bolts 1:1.
More control over some AI aspects (squad composition, probability of squad type, etc.). Automatic converter for AI(E).ini wouldn't hurt either Modular AI is a leap forward, but it's still a bit far from TS scriptable AI.
Significantly improved Pathfinding performance (DTA unit counts are often higher than OpenRA unit counts) Bearable.
Terrain animations: https://github.com/OpenRA/OpenRA/issues/6433Doable with dummy actors at worst. Palette cycling on particular terrain tiles would still be better. ORA supports per-tmp palettes now.
Q-Move A-move's in, notsure what's the difference.
Automatic, configurable updater for mods Not even doable due to Linux AppImages. Use the ingame newscaster to announce new versions instead.
If not the above, then the current client will be used and spawner support is needed Or you start supporting Linux instead.
If the current client is ditched, then we need to improve the current OpenRA menus to be more similar to the nice DTA menus Doable. Custom checkboxes became a thing since 2018.
CnCNet tunnel support (OpenRA's P2P might make it impossible to play / host games for some people behind unconfigurable routers, like me in my studying apartment) Out of scope, I think.
Not that essential, but would be nice to have:
Multiplayer saves Missing.
Small visceroids fusing to a single large one Doable.
Veinhole logic (veins retract when veinhole is killed etc.) Missing.
Component Towers/Gates can be placed on walls, replacing them Included.
Bouncy bullets (disc thrower) Included.
Hospital (hurt inf goes in, exits healed) Missing. Would be easy to do, though. If you express serious interest, I'm willing to code that. You need to show actual work towards ORA as such interest though.
Tiberium fiends logic (run to Tiberium and lay down to heal) Automatically aiming towards tibfields is missing and requires custom code. Although that sounds like an easy task, so hospital case applies. Healing is doable.
Configurable tilt/roll/pitch angle for voxel aircraft Missing.
Ion Storm disabling actors: https://github.com/OpenRA/OpenRA/issues/7874Missing, although I guess adding this to the AS "IonStorm" trait would make sense, since it would also cover map lighting along.
_________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Let's face it - it takes levels of boredom to throw a bone to you when even in this thread your dared bragging about your own achievements, ignoring what I was doing meanwhile. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
CnCNet tunnel support (OpenRA's P2P might make it impossible to play / host games for some people behind unconfigurable routers, like me in my studying apartment) Out of scope, I think.
OpenRA is not P2P, and while you can indeed host your own server inside the game, this has never been a requirement.
The overwhelming majority of MP games are played on community-hosted dedicated servers, so normal players don't care about tunnels or routers (provided they aren't on an IPv6-only connection, which is still rare). QUICK_EDIT
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum