:: Home :: Get Hosted :: PPM FAQ :: Forum FAQ :: Privacy Policy :: Search :: Memberlist :: Usergroups :: Register :: Profile :: Log in to check your private messages :: Log in ::
Do you want to advertise at Project Perfect Mod. Find out how to do it HERE.

The time now is Thu Mar 21, 2019 7:59 am
All times are UTC + 0
 Forum index » Modding Central » OpenRA Editing Forums
OpenRA Dev Blog
Post a reply
Username
Subject
Subject description
Message icons
No icon
Message body

Emoticons
Very Happy Smile Sad Surprised
Shocked Confused Cool Laughing
Mad #Mad Razz Embarassed
Crying or Very sad #evil Twisted Evil Rolling Eyes
Wink Exclamation Question Idea
View more Emoticons
 Font colour:  Font size: Close Tags
Key Words
Options
HTML is OFF
BBCode is ON
Smilies are ON
Disable BBCode in this post
Disable Smilies in this post
If you are visually impaired or cannot otherwise answer the challenges below please contact the Administrator for help.


Write only one of the following words: Brotherhood, unity, peace! 

 
 Forum index » Modding Central » OpenRA Editing Forums
Jump to:  
Topic review


Graion Dilach
PostPosted: 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..
Reaperrr
PostPosted: 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.

next release will finally support this Smile
pchote
PostPosted: Wed Apr 04, 2018 7:44 pm    Post subject:

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.
EVA-251
PostPosted: Mon Apr 02, 2018 2:51 pm    Post subject:

I see the defaults can also be assigned by the modder. That's pretty nice.
pchote
PostPosted: Sat Mar 31, 2018 1:30 pm    Post subject:

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.
pchote
PostPosted: Wed Mar 21, 2018 9:26 pm    Post subject:

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.
Nolt
PostPosted: Wed Mar 21, 2018 12:09 pm    Post subject:

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 fact that it points at each individual line is gold, nice work.
pchote
PostPosted: Wed Mar 21, 2018 3:24 am    Post subject:

#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:

Code:
$ ./utility.sh --update-mod
--update-mod SOURCE [--detailed] [--apply] [--skip-maps]
Valid sources are:
   Update Paths:
      release-20180218
      release-20180307
   Individual Rules:
      SplitTurretAimAnimation
      RenameWormSpawner
      RemoveWithReloadingSpriteTurret
      RemoveWeaponScanRadius
      DefineSoundDefaults
      RemoveTerrainTypeIsWaterFlag


Code:
$ ./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

RemoveWeaponScanRadius: Remove Weapon ScanRadius parameters
   Updating mod... COMPLETE
   Updating system maps... COMPLETE

SplitTurretAimAnimation: Introduce WithTurretAimAnimation trait
   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
      
    * The default value for Building.BuildSounds has been removed.
      You may wish to explicitly define `BuildSounds: placbldg.aud, build5.aud` at the following locations
      if the sound has not already been inherited from a parent definition.
       * rules/misc.yaml:272
       * rules/misc.yaml:293
       * rules/misc.yaml:315
       * rules/misc.yaml:331
       * rules/misc.yaml:349
       * rules/misc.yaml:506
       * rules/defaults.yaml:468
       * rules/defaults.yaml:707
       * rules/defaults.yaml:746
       * rules/defaults.yaml:841
       * rules/defaults.yaml:863
       * rules/husks.yaml:212
       * rules/husks.yaml:222
       * rules/husks.yaml:232
       * rules/husks.yaml:242
       * rules/husks.yaml:252
       * rules/husks.yaml:262
       * rules/husks.yaml:272
       * rules/husks.yaml:282
       * rules/husks.yaml:295
       * rules/husks.yaml:305
       * rules/husks.yaml:315
       * rules/husks.yaml:325
       * rules/husks.yaml:335
       * rules/husks.yaml:345
       * rules/husks.yaml:355
       * rules/husks.yaml:365
       * rules/husks.yaml:375
       * rules/husks.yaml:385
       * rules/husks.yaml:395
       * rules/husks.yaml:405
       * rules/husks.yaml:415
       * rules/structures.yaml:15
       * rules/structures.yaml:107
       * rules/structures.yaml:189
       * rules/structures.yaml:271
       * rules/structures.yaml:319
       * rules/structures.yaml:446
       * rules/structures.yaml:473
       * rules/structures.yaml:510
       * rules/structures.yaml:555
       * rules/structures.yaml:592
       * rules/structures.yaml:632
       * rules/structures.yaml:674
       * rules/structures.yaml:712
       * rules/structures.yaml:762
       * rules/structures.yaml:824
       * rules/structures.yaml:923
       * rules/structures.yaml:989
       * rules/structures.yaml:1084
       * rules/structures.yaml:1117
       * rules/structures.yaml:1154
       * rules/structures.yaml:1184
       * rules/structures.yaml:1287
       * rules/structures.yaml:1344
       * rules/structures.yaml:1473
       * rules/structures.yaml:1491
       * rules/civilian.yaml:64
       * rules/civilian.yaml:90
       * rules/civilian.yaml:109
       * rules/civilian.yaml:129
       * rules/civilian.yaml:145
       * rules/civilian.yaml:161
       * rules/civilian.yaml:178
       * rules/civilian.yaml:189
       * rules/civilian.yaml:200
       * rules/civilian.yaml:363
       * rules/civilian.yaml:385
       * rules/civilian.yaml:412
       * rules/civilian.yaml:476
       * rules/civilian.yaml:496
       * rules/civilian.yaml:516
       * rules/civilian.yaml:536
       * rules/civilian.yaml:578
       * rules/civilian.yaml:592
       * rules/civilian.yaml:606
       * rules/civilian.yaml:620
       * rules/civilian.yaml:640
       * rules/civilian.yaml:651
       * rules/civilian.yaml:665
       * rules/civilian.yaml:684
       * rules/civilian.yaml:702
       * rules/civilian.yaml:711
       * rules/civilian.yaml:720
       * rules/civilian.yaml:729
       * rules/civilian.yaml:746
       * rules/civilian.yaml:767
       * rules/civilian.yaml:784
       * rules/civilian.yaml:802
       * rules/civilian.yaml:818
       * rules/decoration.yaml:3
       * rules/decoration.yaml:15
       * rules/decoration.yaml:27
       * rules/decoration.yaml:39
       * rules/decoration.yaml:51
       * rules/decoration.yaml:63
       * rules/decoration.yaml:75
       * rules/decoration.yaml:87
       * rules/decoration.yaml:104
       * rules/decoration.yaml:116
       * rules/decoration.yaml:128
       * rules/decoration.yaml:140
       * rules/decoration.yaml:152
       * rules/decoration.yaml:164
       * rules/decoration.yaml:176
       * rules/decoration.yaml:188
       * rules/decoration.yaml:200
       * rules/decoration.yaml:212
       * rules/decoration.yaml:224
       * rules/decoration.yaml:236
       * rules/decoration.yaml:248
       * rules/decoration.yaml:332
       * rules/decoration.yaml:345
       * rules/decoration.yaml:358
       * rules/decoration.yaml:387
       * rules/decoration.yaml:395
       * rules/decoration.yaml:403
       * rules/decoration.yaml:411
       * rules/decoration.yaml:419
       * rules/decoration.yaml:427
       * rules/decoration.yaml:435
       * rules/decoration.yaml:459
       * rules/decoration.yaml:472
       * rules/fakes.yaml:17
       * rules/fakes.yaml:54
       * rules/fakes.yaml:89
       * rules/fakes.yaml:117
       * rules/fakes.yaml:138
      
    * The default value for Building.UndeploySounds has been removed.
      You may wish to explicitly define `UndeploySounds: cashturn.aud` at the following locations
      if the sound has not already been inherited from a parent definition.
       * rules/misc.yaml:272
       * rules/misc.yaml:293
       * rules/misc.yaml:315
       * rules/misc.yaml:331
       * rules/misc.yaml:349
       * rules/misc.yaml:506
       * rules/defaults.yaml:468
       * rules/defaults.yaml:534
       * rules/defaults.yaml:583
       * rules/defaults.yaml:707
       * rules/defaults.yaml:746
       * rules/defaults.yaml:841
       * rules/defaults.yaml:863
       * rules/husks.yaml:212
       * rules/husks.yaml:222
       * rules/husks.yaml:232
       * rules/husks.yaml:242
       * rules/husks.yaml:252
       * rules/husks.yaml:262
       * rules/husks.yaml:272
       * rules/husks.yaml:282
       * rules/husks.yaml:295
       * rules/husks.yaml:305
       * rules/husks.yaml:315
       * rules/husks.yaml:325
       * rules/husks.yaml:335
       * rules/husks.yaml:345
       * rules/husks.yaml:355
       * rules/husks.yaml:365
       * rules/husks.yaml:375
       * rules/husks.yaml:385
       * rules/husks.yaml:395
       * rules/husks.yaml:405
       * rules/husks.yaml:415
       * rules/structures.yaml:15
       * rules/structures.yaml:107
       * rules/structures.yaml:189
       * rules/structures.yaml:271
       * rules/structures.yaml:319
       * rules/structures.yaml:446
       * rules/structures.yaml:473
       * rules/structures.yaml:510
       * rules/structures.yaml:555
       * rules/structures.yaml:592
       * rules/structures.yaml:632
       * rules/structures.yaml:674
       * rules/structures.yaml:712
       * rules/structures.yaml:762
       * rules/structures.yaml:824
       * rules/structures.yaml:923
       * rules/structures.yaml:989
       * rules/structures.yaml:1084
       * rules/structures.yaml:1117
       * rules/structures.yaml:1154
       * rules/structures.yaml:1184
       * rules/structures.yaml:1287
       * rules/structures.yaml:1344
       * rules/structures.yaml:1473
       * rules/structures.yaml:1491
       * rules/civilian.yaml:64
       * rules/civilian.yaml:90
       * rules/civilian.yaml:109
       * rules/civilian.yaml:129
       * rules/civilian.yaml:145
       * rules/civilian.yaml:161
       * rules/civilian.yaml:178
       * rules/civilian.yaml:189
       * rules/civilian.yaml:200
       * rules/civilian.yaml:363
       * rules/civilian.yaml:385
       * rules/civilian.yaml:412
       * rules/civilian.yaml:476
       * rules/civilian.yaml:496
       * rules/civilian.yaml:516
       * rules/civilian.yaml:536
       * rules/civilian.yaml:578
       * rules/civilian.yaml:592
       * rules/civilian.yaml:606
       * rules/civilian.yaml:620
       * rules/civilian.yaml:640
       * rules/civilian.yaml:651
       * rules/civilian.yaml:665
       * rules/civilian.yaml:684
       * rules/civilian.yaml:702
       * rules/civilian.yaml:711
       * rules/civilian.yaml:720
       * rules/civilian.yaml:729
       * rules/civilian.yaml:746
       * rules/civilian.yaml:767
       * rules/civilian.yaml:784
       * rules/civilian.yaml:802
       * rules/civilian.yaml:818
       * rules/decoration.yaml:3
       * rules/decoration.yaml:15
       * rules/decoration.yaml:27
       * rules/decoration.yaml:39
       * rules/decoration.yaml:51
       * rules/decoration.yaml:63
       * rules/decoration.yaml:75
       * rules/decoration.yaml:87
       * rules/decoration.yaml:104
       * rules/decoration.yaml:116
       * rules/decoration.yaml:128
       * rules/decoration.yaml:140
       * rules/decoration.yaml:152
       * rules/decoration.yaml:164
       * rules/decoration.yaml:176
       * rules/decoration.yaml:188
       * rules/decoration.yaml:200
       * rules/decoration.yaml:212
       * rules/decoration.yaml:224
       * rules/decoration.yaml:236
       * rules/decoration.yaml:248
       * rules/decoration.yaml:332
       * rules/decoration.yaml:345
       * rules/decoration.yaml:358
       * rules/decoration.yaml:387
       * rules/decoration.yaml:395
       * rules/decoration.yaml:403
       * rules/decoration.yaml:411
       * rules/decoration.yaml:419
       * rules/decoration.yaml:427
       * rules/decoration.yaml:435
       * rules/decoration.yaml:459
       * rules/decoration.yaml:472
       * rules/fakes.yaml:17
       * rules/fakes.yaml:54
       * rules/fakes.yaml:89
       * rules/fakes.yaml:117
       * rules/fakes.yaml:138
      

RenameWormSpawner: WormSpawner renamed and generalized to ActorSpawner
   Updating mod... COMPLETE
   Updating system maps... COMPLETE

RemoveWithReloadingSpriteTurret: Remove WithReloadingSpriteTurret trait
   Updating mod... COMPLETE
   Updating system maps... COMPLETE

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.
Reaperrr
PostPosted: 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.
Lin Kuei Ominae
PostPosted: Sat Mar 10, 2018 3:47 pm    Post subject:

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.
Reaperrr
PostPosted: 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.
cxtian39
PostPosted: Tue Sep 12, 2017 11:23 pm    Post subject:

Wink In Ra3 you deploy/unload by pressing F
Matthias M.
PostPosted: Sun Sep 10, 2017 6:45 pm    Post subject:

and now that I implemented it https://github.com/OpenRA/OpenRA/pull/13885 nobody wants it.  Crying or Very sad
Matthias M.
PostPosted: Sat Jul 22, 2017 8:36 am    Post subject:

Lin Kuei Ominae wrote:
F was introduced in RA1 as the formation move. Does something similar exist in OpenRA?

No, not yet, but it was wished a lot before https://github.com/OpenRA/OpenRA/issues/3880
Iran
PostPosted: Thu Jul 20, 2017 4:21 pm    Post subject:

pchote wrote:
Here's an advance preview of what we are planning to release this weekend OpenRA/OpenRAWeb#349.

Looks very cool.
Lin Kuei Ominae
PostPosted: Thu Jul 20, 2017 7:01 am    Post subject:

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?
pchote
PostPosted: Wed Jul 19, 2017 10:26 pm    Post subject:

Here's an advance preview of what we are planning to release this weekend OpenRA/OpenRAWeb#349.
pchote
PostPosted: Thu Jun 29, 2017 6:10 pm    Post subject:

Gangster wrote:
Can it (stances) be set on factories types, so all newly built unit could have a appropriate default stance?
IIRC C&C3 supported this, and it makes sense to add to OpenRA.  This won't be done for the first release with the commandbar, but if somebody wanted to adopt the feature then I see no reason why we couldn't include it in a future release.

Gangster wrote:
Okay, and can I set Hold Fire on base defenses?
Yes, you can.
Gangster
PostPosted: Thu Jun 29, 2017 3:30 pm    Post subject:

Graion Dilach wrote:
No..


Okay, and can I set Hold Fire on base defenses? (For a reason I don't know yet..)


Lin Kuei Ominae wrote:
Nice you see you again Gangster.


I have missed you to
<3

Very Happy
Graion Dilach
PostPosted: Thu Jun 29, 2017 3:20 pm    Post subject:

Gangster wrote:
I like! Can it (stances) be set on factories types, so all newly built unit could have a appropriate default stance?


No, but you can define default stances on the actors' AutoTarget trait themselves (although it's best to leave AI ones on AttackAnything).

pchote wrote:
Reaperrr wrote:
But for the sake of modder-friendlyness, I'll see if I can fix the 'ApplyToAllTargetablePositions' instead of removing it, although that probably means I'll change it to 'ApplyToAllOccupiedCells', to untie it from targetable offsets.
Please lets not.  That will just encourage poor-performance practices if it doesn't bitrot, and like you said doing it properly is only barely more effort.


RenderSprites->Scale is still in, has been bitrot ages ago and nothing happens with that one. I find your argument invalid.
Lin Kuei Ominae
PostPosted: Thu Jun 29, 2017 2:44 pm    Post subject:

He's back. Nice you see you again Gangster. Smile
Gangster
PostPosted: Thu Jun 29, 2017 2:37 pm    Post subject:

Hi!

I like! Can it (stances) be set on factories types, so all newly built unit could have a appropriate default stance?
pchote
PostPosted: Wed Jun 28, 2017 8:57 pm    Post subject:

Our command bar make it easy to discover and use the various unit commands and stances (which have existed for years on keyboard shortcuts):





Reaperrr
PostPosted: Mon Jun 05, 2017 9:36 pm    Post subject:

pchote wrote:
Reaperrr wrote:
But for the sake of modder-friendlyness, I'll see if I can fix the 'ApplyToAllTargetablePositions' instead of removing it, although that probably means I'll change it to 'ApplyToAllOccupiedCells', to untie it from targetable offsets.
Please lets not.  That will just encourage poor-performance practices if it doesn't bitrot, and like you said doing it properly is only barely more effort.

Out of sheer curiosity I made a quick attempt locally, only to realize it wouldn't even be that easy to fix anyway. So yeah, not worth the effort & downsides.
pchote
PostPosted: Mon Jun 05, 2017 8:55 pm    Post subject:

Reaperrr wrote:
But for the sake of modder-friendlyness, I'll see if I can fix the 'ApplyToAllTargetablePositions' instead of removing it, although that probably means I'll change it to 'ApplyToAllOccupiedCells', to untie it from targetable offsets.
Please lets not.  That will just encourage poor-performance practices if it doesn't bitrot, and like you said doing it properly is only barely more effort.
Reaperrr
PostPosted: Mon Jun 05, 2017 8:31 pm    Post subject:

Graion Dilach wrote:
Not in the current shape, no. Probably possible at a later point

Yeah, it's on my TO-DO list since I need it myself for my MechCommander mod.

Graion Dilach wrote:
at the moment, this is unfinished and breaks the balanced-cellspread model (which was called as a hack but... bleh). Note that this requires that every building must have a manually set up hitbox.

Well, it is a hack. It only works for rectangle shapes, and was always meant as interim solution.
For all the more common rectangular shapes, you can simply define a default (^2x2shape etc.) once in defaults.yaml and then inherit the matching shape for each building. And you'll be able to copy most of these default shapes from our TS mod.

But for the sake of modder-friendlyness, I'll see if I can fix the 'ApplyToAllTargetablePositions' instead of removing it, although that probably means I'll change it to 'ApplyToAllOccupiedCells', to untie it from targetable offsets.
Graion Dilach
PostPosted: Mon Jun 05, 2017 10:21 am    Post subject:

Not in the current shape, no. Probably possible at a later point, at the moment, this is unfinished and breaks the balanced-cellspread model (which was called as a hack but... bleh). Note that this requires that every building must have a manually set up hitbox.
Mig Eater
PostPosted: Mon Jun 05, 2017 9:59 am    Post subject:

Can this be used to create different armour strengths at different locations on units, so if you shot a unit in the rear it will take more damage etc?
Crimsonum
PostPosted: Mon Jun 05, 2017 6:45 am    Post subject:

Quote:
Additionally, you can now define custom targetable positions freely via offsets (relative to actor center). On top of that, we're about to fix our code so that these will not only be used for certain targeting and range calculations, but actually really for everything, so frontal attackers, turrets and weapons will really aim and shoot at the closest targetable position, instead of the target's center.

And while it might not be used by our TS mod, those customizable offsets work on the Z-axis as well, meaning you'll be able to make weapons shoot at the body of mechs, rather than their feet, make aircraft fire at the top of buildings, and so on.


Very nice, I was always bothered of how this worked in the original games, and how it wasn't corrected until TW Neutral
Reaperrr
PostPosted: Sun Jun 04, 2017 9:44 pm    Post subject:

Matthias M. wrote:
It is rectangular and round bar shaped hitboxes that you see in a developer overlay there. It also displays damage taken in the small numbers. What looks like a red lighting effect around the explosion is actually a visualisation of the damage fallout. Should assist in balancing the weaponry.


For various reasons it took much longer than I had originally hoped, but we're finally getting there.
For improved flexibility, hitboxes were moved from Health to a dedicated, conditional HitShape trait. This means that actors can have multiple hit-shapes at once, and that they can be turned on and off via conditions on the fly.
Additionally, you can now define custom targetable positions freely via offsets (relative to actor center). On top of that, we're about to fix our code so that these will not only be used for certain targeting and range calculations, but actually really for everything, so frontal attackers, turrets and weapons will really aim and shoot at the closest targetable position, instead of the target's center.

And while it might not be used by our TS mod, those customizable offsets work on the Z-axis as well, meaning you'll be able to make weapons shoot at the body of mechs, rather than their feet, make aircraft fire at the top of buildings, and so on.
Matthias M.
PostPosted: Sun Sep 25, 2016 1:26 pm    Post subject:

I present to you:



Low bridges are currently static actors. Unlike the old Westwood games we use the layer approach only to change the terrain, but everything else will be able to interact with the existing traits and script interfaces for more flexibility.

In the future these will become destructible and repairable. What you see is a screenshot from the in-game map editor with the dead bridges drawn with transparency. The legacy map converter will automatically import these correctly now.

While this doesn't add much for new gameplay as you could already just paint road tiles over the water, this is another step towards Tiberian Sun's main feature. http://www.lofibucket.com/articles/tibsun_bridges.html =)
pchote
PostPosted: Sun Mar 06, 2016 2:23 pm    Post subject:

Adding options for those would be quite straightforward.
Graion Dilach
PostPosted: Sun Mar 06, 2016 1:27 pm    Post subject:

Turn-on-the-move and fire-on-the-move (at turrets) have no controls atm, they are permanently enabled.
G-E
PostPosted: Sat Mar 05, 2016 6:00 pm    Post subject:

Weird, I notice units turn casually relative to their direction of travel, unlike RA2 where units have to explicitly turn first. Clearly I don't know the mechanics at play and this is good for something omnidirectional like a helicopter, this behaviour needs some ability to customize I think?

Is it based on ROT and speed or are there explicit controls (even if fuzzy) to decide how things happen?
pchote
PostPosted: Thu Mar 03, 2016 1:01 pm    Post subject:

tmsbrg has published a blog post introducing his final year university project to build a random map generator in OpenRA.

Earlier student projects have included developing a framework to easily port the original TD missions to OpenRA, and more recently Yellow/TheRaffy's work on weather particle effects.
Banshee
PostPosted: Mon Feb 29, 2016 12:05 am    Post subject:

That's excellent. The easier it is for the user to install and create mods, the better.
pchote
PostPosted: Sun Feb 28, 2016 10:05 pm    Post subject:

#10841 adds support for oramod packages, which let you ship and install mods as a single file in the OpenRA support directory (similar to manual map installation).  We eventually plan on adding mod support to the resource center, which will make mod discovery and installation as simple as selecting a server in the multiplayer lobby and pressing "install mod".
pchote
PostPosted: Fri Jan 29, 2016 11:21 pm    Post subject:

teees has been making good progress on the manual carryall logic: https://streamable.com/jknr

...but there's still a few kinks to work out before we can merge them: https://streamable.com/9kze
Matthias M.
PostPosted: Sun Jan 17, 2016 6:35 pm    Post subject:

The latest unreleased development version now allows you to install mods into the user folder. The long neglected Red Alert 2 mod is the first one to make use of it https://github.com/OpenRA/ra2/wiki#installation
penev
PostPosted: Fri Jan 01, 2016 8:07 pm    Post subject:

The "one step further" has already been requested - https://github.com/OpenRA/OpenRA/issues/9268    Wink
Lin Kuei Ominae
PostPosted: Fri Jan 01, 2016 1:43 pm    Post subject:

Excellent idea and implementation.
Gameplay and modding wise this a very useful feature. thank you

I wonder if you could even go one step further and have a front,left,right,rear and top hit zone for units.
So you could create tanks which have significant more armor on the front than on their rear.

Would be great for certain assault units (strong front armor, but weak rear), which are very weak when retreating.
Or big ships which take more damage when a bomb hits the center on top than the side.
Matthias M.
PostPosted: Fri Jan 01, 2016 8:27 am    Post subject:

It is rectangular and round bar shaped hitboxes that you see in a developer overlay there. It also displays damage taken in the small numbers. What looks like a red lighting effect around the explosion is actually a visualisation of the damage fallout. Should assist in balancing the weaponry.
PillBox20
PostPosted: Fri Jan 01, 2016 8:24 am    Post subject:

Not sure, if I will explain it right, but...
unit select boxes - units take more than one cell or somethung?
HG_SCIPCION
PostPosted: Thu Dec 31, 2015 3:36 pm    Post subject:

World x2? .-.
Bittah Commander
PostPosted: Thu Dec 31, 2015 3:18 pm    Post subject:

Hitboxes?
Reaperrr
PostPosted: Thu Dec 31, 2015 3:14 pm    Post subject:

What upcoming feature might I be demonstrating here?
Reaperrr
PostPosted: Mon Oct 05, 2015 5:01 pm    Post subject: Another update

While the latest release has only been out for two weeks, the release branch has been in feature-freeze since early August, so there's already a pile of new things added to the development branch to look forward to. The following list is by no means exhaustive, these are just among the more notable improvements over release 20150919.

FEATURES:
-------------
1) Gamespeed control
Often requested, this has finally become affordable in terms of performance. It cannot be changed mid-game (yet), but at least you're not forced to play at OpenRA's default 25 ticks/second anymore.

2) More traits upgradable
Several actor traits are now upgradable, and support multiple traits of their kind on a single actor.
- all (sprite and voxel) body, turret and barrel traits, which means you can change the visuals of an actor through upgrades, including switching between sprite and voxel.
- the Armor trait. That's right, you can now have more than one armor type on any actor. You can enable or disable them via upgrades, and if there's more than one armor type enabled, their effects stack.
- the Targetable trait. You can now create situations where an actor becomes targetable only by specific weapons. This is already used for differentiation between landed and airborne aircraft.
- the BlocksProjectiles trait. This can be useful for cases like laser fences.

These are just the ones I could remember, there are (or will be) a few more.

PERFORMANCE:
------------------
1) Massively reduced performance impact of giving orders to larger numbers of units
Previously the engine would perform a synchronization op for every order to every unit. This was actually a larger performance issue than pathfinding and the main reason why the game would become very laggy when ordering larger armies around.
Orders are now no longer sync'ed, so the overhead has gone away completely.

2) Improved pathfinding performance
It's not a major breakthrough yet (it's still too slow for our in-development TS mod), but pathfinding now takes only about ~60% of the CPU time it took before and has become acceptable in terms of performance (at least compared to what we had before).

3) Fixed AI base-builder performance issue
We've identified and fixed another major AI performance issue in the base building placement code that occasionally caused huge lag spikes.



Oh, and the next release will be what the first non-beta release of TDX will be based on.  Wink
Dutchygamer
PostPosted: Mon Aug 03, 2015 5:07 pm    Post subject: Re: #2 Weapons

Reaperrr wrote:
Another thing I've wanted to point out for quite some time (because OpenRA has had these features for quite a while):

You can have nearly unlimited weapons and unlimited turrets on any actor, and give some of these weapons their own pool of limited ammo.
You could make a battleship with two cannon turrets, a missile launcher, a half dozen smaller gun turrets at the sides, a depth charge launcher and a tesla coil, and assign multiple weapons to each turret, and let the main cannons run out of ammo after ~100 shots requiring the player to manually resupply them at a ship yard.
And yes, you can give each turret its own art, too. Turrets are upgradable as well, as are armaments, so you can turn a medium tank into a fully-fledged heavy tank via upgrades / veterancy, for example.

While we won't make it for the upcoming release, for the release after that we plan to have all actor body, turret and barrel render traits upgradable, so you'll be able to do some crazy stuff, if you want to (a TD T-Rex turning into a voxel mammoth tank after eating enough infantry while retaining veterancy? Will be possible).

Inb4 someone makes a Baneblade for OpenRA #Tongue
pchote
PostPosted: Mon Aug 03, 2015 9:41 am    Post subject:

The code is set up in a way that supports turrets on turrets, but the configuration to define that isn't exposed to the yaml.  If you had a serious use case for it somebody could add it.
Page 1 of 1 [1 Post]  


Powered by phpBB © phpBB Group

Wildcard SSL Certificates
[ Time: 0.1581s ][ Queries: 10 (0.0043s) ][ Debug on ]