This all sounds awesome.
The only little issue i've found is, that the deploying key is F and not D. I think ever since TD the default key to deploy units was d and it should be this way in OpenRA too imo.
F was introduced in RA1 as the formation move. Does something similar exist in OpenRA? _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 26 Apr 2003 Location: Somewhere in Germany
Posted: Fri Mar 09, 2018 11:43 pm Post subject:
Small update:
The next release will support, amongst other things:
- Polygon HitShapes (allows you to define an arbitrary hitzone)
- GIMP/JASC 8-bit palettes, including per-color alpha support (like those saved by OS Palette Editor, for example)
Both of which I consider potentially quite useful. QUICK_EDIT
Polygon HitShapes: This rotates with the unit, right? What's the default direction on which you would define the hitzone?
Is this a step towards multiple hitzones like front/back and side armor?
JASC sounds very useful, considering the 6Bit color limitation of the C&C pal format. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 26 Apr 2003 Location: Somewhere in Germany
Posted: Sun Mar 11, 2018 12:13 am Post subject:
Lin Kuei Ominae wrote:
Polygon HitShapes: This rotates with the unit, right? What's the default direction on which you would define the hitzone?
Yes, it does. Not entirely sure what you mean with default direction, but in this case the X value stands for left(negative)/right(positive), while the Y value currently stands for front(negative, and yes I'm aware that's a bit unintuitive)/back(positive).
Lin Kuei Ominae wrote:
Is this a step towards multiple hitzones like front/back and side armor?
Not really, though it indirectly helps, of course (being able to set up arbitrary hitzone shapes, I mean).
We still need to make some changes to the way warheads work before we can finally implement per-hitzone-armor. It's on my agenda, but no ETA. QUICK_EDIT
#14964 finally implements the long-delayed (I first outlined this plan more than two years ago) mod update infrastructure. The idea behind this new system is to provide modders with much more detailed information about what has changed, even if they don't want to automate the changes. The new rules are much more robust to errors, and easier to write.
Here is a demonstration updating the RA Classic mod from release-20180218 to the current bleed version:
$ ./utility.sh --update-mod release-20180218 --detailed
Found 6 API changes:
* RemoveTerrainTypeIsWaterFlag: Remove TerrainType IsWater flag
The IsWater flag on terrain type definitions has been unused for some time.
This flag has now been removed from the tileset yaml.
* RemoveWeaponScanRadius: Remove Weapon ScanRadius parameters
The *ScanRadius parameters have been removed from weapon projectiles and warheads.
These values are now automatically determined by the engine.
CreateEffect.ImpactActors: False has been added to replace VictimScanRadius: 0
* SplitTurretAimAnimation: Introduce WithTurretAimAnimation trait
WithSpriteTurret.AimSequence and WithTurretAttackAnimation.AimSequence
have been split into a new WithTurretAimAnimation trait.
* DefineSoundDefaults: Move mod-specific sound defaults to yaml
Mod-specific default sound values have been removed from several traits.
The original values are added back via yaml.
* RenameWormSpawner: WormSpawner renamed and generalized to ActorSpawner
The D2k-specific WormSpawner trait was renamed to ActorSpawner,
generalized, and moved into the common mod code.
* RemoveWithReloadingSpriteTurret: Remove WithReloadingSpriteTurret trait
WithReloadingSpriteTurret has been superseded by conditions.
The trait is switched for with WithSpriteTurret.
Run this command with the --apply flag to apply the update rules.
Code:
$ ./utility.sh --update-mod release-20180218 --apply
WARNING: This command will automatically rewrite your mod rules.
Side effects of this command may include changing the whitespace to
match the default conventions, and any yaml comments will be removed.
We strongly recommend that you have a backup of your mod rules, and
for best results, to use a Git client to review the line-by-line
changes and discard any unwanted side effects.
Press y to continue, or any other key to cancel: y
RemoveTerrainTypeIsWaterFlag: Remove TerrainType IsWater flag
Updating mod... COMPLETE
Updating system maps... COMPLETE
DefineSoundDefaults: Move mod-specific sound defaults to yaml
Updating mod... COMPLETE
Updating system maps... COMPLETE
Manual changes are required to complete this update:
* The default value for ParaDrop.ChuteSound has been removed.
You may wish to explicitly define `ChuteSound: chute1.aud` at the following locations
if the sound has not already been inherited from a parent definition.
* rules/aircraft.yaml:3
Semi-automated update complete.
Please review the messages above for any manual actions that must be applied.
The current PR only supports updating from the current release to the next release, but I would like to think that we can work backwards in the not-too-distant future and port the old rules from release-20171014 to release-20180218 to provide a supported update path for people using the Mod SDK. QUICK_EDIT
And the script alone does all those descriptions? cool, this could potentially remove the barrier of entry that is git (because users have to use that to check all the differences between the old version and new)
The split of automated vs manual changes is up to the person writing the update rule, but the standard that I will be pushing for is to automate the things that we know for sure are safe (e.g. renames or removals) and to report instructions and line numbers for anything else. Having to babysit and undo unwanted changes made by the updater sucks for everyone. QUICK_EDIT
We have two cool new features to look forward to in the next release thanks to new first-time contributors.
@drogoganor added support for saving player colors in #14853, alongside preset color choices based on research from @piggy and others in #11248:
@joealam added support for mouse/keyboard selection in text fields in #14980:
These go to show that you do not need to be an experienced OpenRA developer to make meaningful improvements to the game. Nowadays most of the interesting new features added to the engine come from people like these. QUICK_EDIT
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Mon Apr 02, 2018 2:51 pm Post subject:
I see the defaults can also be assigned by the modder. That's pretty nice. _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) QUICK_EDIT
The poor support for updating mods was one out of two major issues that I had with OpenRA's modding capabilities.
The other was the lack of Linux packaging support in the Mod SDK, which I fixed over the long weekend with OpenRAModSDK#71.
This means that SDK-based mods can now automatically generate installers for Windows (both proper NSIS and "portable" bundles), macOS, and most modern Linux distros using the GitHub web interface and the magic of cloud computing. QUICK_EDIT
Joined: 26 Apr 2003 Location: Somewhere in Germany
Posted: Fri Jan 04, 2019 11:23 am Post subject:
Small teaser on the upcoming release:
Amongst many other nice improvements, we've finally broken the monolithic, true-to-its-name "HackyAI" bot into several modules, which are easier to read, debug, improve, disable or replace.
Next release won't have much in the way of actual improvements yet (though there are a few small ones), but now the plumbing is there for modders with coding ability - like the KKND guys - to improve or rewrite parts to meet their requirements, and of course OpenRA's upstream code will see some major improvements in the following releases, too.
Watch this space.
Also,
Reaperrr wrote:
Lin Kuei Ominae wrote:
Is this a step towards multiple hitzones like front/back and side armor?
Not really, though it indirectly helps, of course (being able to set up arbitrary hitzone shapes, I mean).
We still need to make some changes to the way warheads work before we can finally implement per-hitzone-armor. It's on my agenda, but no ETA.
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri Jan 04, 2019 9:34 pm Post subject:
Indeed, that AI improvement is good, I've already wrote a new support power targeting module to fix the issues with targeting on gen2. So yeah, that's probably the best thing added in the last half year. Good job on that one.. _________________ "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
It was considered, but no. It has its own hotkey while the placement mode is active.
Mods may wish to use the feature for non-directional things, for example a component tower where you can pick the turret on top, or different styles/shapes that aren't related to direction. QUICK_EDIT
this is really cool. For a TS mod the 2 gates would only need a single icon in the sidemenu.
pchote wrote:
Mods may wish to use the feature for non-directional things, for example a component tower where you can pick the turret on top, or different styles/shapes that aren't related to direction.
that sounds interesting. Not sure how different turrets with different prices would work this way though.
Right now it sounds like they all need the same price.
*thinking aloud*
I wonder if this could be used to create directional walls, with one weaker side facing inwards towards your base and one stronger side facing outwards. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri Jun 07, 2019 1:57 pm Post subject:
Lin Kuei Ominae wrote:
this is really cool. For a TS mod the 2 gates would only need a single icon in the sidemenu.
That was their main usecase.
Lin Kuei Ominae wrote:
that sounds interesting. Not sure how different turrets with different prices would work this way though.
Right now it sounds like they all need the same price.
The hotkey and the feature is applied during placement. So yes.
Lin Kuei Ominae wrote:
I wonder if this could be used to create directional walls, with one weaker side facing inwards towards your base and one stronger side facing outwards.
It can be used somewhat, since hitshapes got own their armors last year. Notsure if it can be paired up with the linebuild and autocornergenerators though. _________________ "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
Lovely, but please fix that player-color black from 0 brightness to 16, 20 or something. That picture is an eye-sore as-is. Last edited by TAK02 on Sun Mar 29, 2020 6:11 am; edited 1 time in total QUICK_EDIT
As CCHyper mentioned the bars need more pop, one thing you could do is specify a secondary colour for the negative value, so rather than dots disappearing into the gray frame, they are replaced with something else. Thus the modder could experiment with strong contrast like red dots for the lost health bar, or can go subtle like dark green. _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
if it follows the usage of a pips.shp as in TS, then you have
frame 1 of an empty box, (which you could color red for the high contrast)
frame 2 for green health
3 for yellow
4 white (no clue for what this is used)
5 red
6 blue (no clue for what this is used either)
So all the contrasting and graphic changing wouldn't be a programmers job, but someone editing the SHPs
@Matthias M.
what are the 3 bars for on the RA2 conyard? Health, construction progress bar, power? _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Thu Apr 02, 2020 11:59 am Post subject:
The health bar (along with any other effects which would use bars, say Iron Curtain duration) and the selection box lines are generated by the engine and not using SHP artwork. Their properties are hardcoded, but overridable in code for downstream projects.
The RA2 image is actually from Romanov's Vengeance. The two bars are construction progress and support power chargeups. _________________ "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 terrain lighting is now fully implemented and PRed as #18310.
I have also shared a statement about the remaster assets, and will likely follow this up with a more detailed news post on the website in the next week or two. QUICK_EDIT
the terrain lighting looks extremely similar to TS, in that it also has these tiled steps in it. Was the code disassembled and 1:1 ported over?
Anyway, very nice job on all this. The video also shows another cool feature that's broken in TS, shakescreen.
Could you estimate how much is missing to support a DTA to OpenRA port?
Or how much is missing for a full TS port? _________________ SHP Artist of Twisted Insurrection: Nod buildings
OpenRA's internals are quite different to the original games (as we can now see with the RA/TD source release), so it wouldn't be feasible to do a 1:1 port. The lighting system in the original TS is actually really simple, so with the help of the rules.ini comments, modenc, general intuition about how game rendering works, and a couple of hours testing different extreme lighting values in the original game it was fairly clear how to accurately reproduce it in OpenRA.
The tiled lighting steps were a consequence of evaluating the lighting once in the middle of the cell - the final PR version instead evaluates it in the four corners to make the gradients much smoother (click to embiggen).
I'm still focusing on the low-level engine features, so it is still going to be a while until all the unit-level behaviours needed for proper TS or DTA gameplay are done. There are some fairly obvious things, like missing superweapons and units not knowing to move when their shots are being blocked by cliffs, but i'm sure also 100 important details that I have no idea even exist (such as using the EMP cannon to force subterranean units to surface, which I only learned about less than a year ago). QUICK_EDIT
units not knowing to move when their shots are being blocked by cliffs
neither TS nor RA2 units do this as well. It would be a great additional feature but not necessary for a direct port. _________________ SHP Artist of Twisted Insurrection: Nod buildings
units not knowing to move when their shots are being blocked by cliffs
neither TS nor RA2 units do this as well. It would be a great additional feature but not necessary for a direct port.
RA2 has a weapon flag SubjectToCliffs, which prevents the weapon from being fired over a cliff, thus the unit will go around it. _________________ QUICK_EDIT
neither TS nor RA2 units do this as well. It would be a great additional feature but not necessary for a direct port.
Ah, well this just proves my point that i'm not very good at estimating how much is missing
Crimsonum wrote:
RA2 has a weapon flag SubjectToCliffs, which prevents the weapon from being fired over a cliff, thus the unit will go around it.
Good to know! I have mentioned this in our issue tracking the feature.
Gangster wrote:
are land units also tilting on ramps now?
We're making progress on this, but it is not yet finished. This will hopefully be the next big TS thing to be finished.
Gangster wrote:
EDIT: ....but not tiberium?
Tinting can be disabled for specific palettes, and I set the default TS rules to do this for tiberium to better match the original (it otherwise looks weirdly dark on dark maps). Mods or maps can easily turn this back on if they want. QUICK_EDIT
Well, hello OpenRa devs. I have finaly manage to compile build to see aircraft update with my own eyes. As beeng a moder, after some playtests I have moved to yaml to fix some visual flaws. Like orca transport pitching or orca fighter not hover-bobling when idle. And there I have found this amazing feature like conditions.
If there any list of all possible ones? did you ever thought on expanding this?
I mean all this Pitch, Roll, Hover bobing, Voxel replacing etc should be moved somethere else and be named Physic.
And with adding enough conditions like: accelerate/deaccelerate, moving uphill/downhill, rotates clockwise\counter, diging\surfacing - pretty neat physic behavior can be emulated.
Most obvious are voxel tilting on ramp or subterranian units.
But this can be extrapolated to other units like:
small pitching for hover units on start\stop
small roll on bike when it turns
voxel replacing on some conditions can be used for wheel rotating effect or vtols with tilting jets like osprey _________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
I don't think conditions are quite what you think. They are just variables that the user creates (with traits to supply those variables based on certain activities of the actor), and traits can use those variables to decide whether the trait should be active or not.
I don't think conditions are quite what you think. They are just variables that the user creates (with traits to supply those variables based on certain activities of the actor), and traits can use those variables to decide whether the trait should be active or not.
Voxels tilting on ramps isn't particularly difficult (click for animation*), and isn't the limiting factor there.
The reason we don't yet support it for vehicles is because the current code that calculates turret/muzzle positions and angles only works when units are flat, and needs to be rewritten using more complicated maths that properly accounts for the 3d rotations. This is almost done, but it takes time to get all the pieces reviewed and merged into the main code.
* It would be nice if PPM could support embedding non-youtube videos! QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Thu Jul 16, 2020 7:31 pm Post subject:
Yeah, conditions are what trait upgrade levels were when you last took your time with ORA. Except that condition statements allow using binary operators so you're no longer limited to explicit levels. This adds an incredible depth to the modding potential if one learns it properly to use it as bread and butter if you ask me. _________________ "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
Yeah, conditions are what trait upgrade levels were when you last took your time with ORA. Except that condition statements allow using binary operators so you're no longer limited to explicit levels. This adds an incredible depth to the modding potential if one learns it properly to use it as bread and butter if you ask me.
Yeah, I have misunderstood the way it works. I've thought the condition comes first, and I could put Traits I want inside "IF-THEN"s, thus achieve unusual visual effects. So I have imagined things...
But it seems it works quite the opposite - first goes Trait and then it's condition. Don't get me worng, it still VERY promising feature.
pchote wrote:
(click for animation*)
Noice _________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
Is it possible for fast vehicles to "fly" when going downhill or when going uphill for an extended period? Kinda like the Bikes from Generals (but not necessarily "jumping down" cliffs). QUICK_EDIT
Sorry for bumping topic again. About my yesterday's idea on physics - I have just found what I was looking for.
Seems like GrantConditionOnMovement is already implemented. I did a quick test
And now my Hover MRLS lands when idle and doing a big leap when turns.
So my questions now are:
Is it possible to expand ValidMovementTypes with more movement types? Uphill\Downhill\Turn-Clockwise\Turn-Counterclockwise\etc?
Is it possible to add Pitch\Roll to Mobile: as well?
_________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
Support for vehicles rolling/pitching on slopes, and for hover units pitching/rolling while moving (like aircraft have now) will come after the turret issue I mention above has been fixed. 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
In Ra3 you deploy/unload by pressing F
