This is a simple and isolated interpolation problem. The code for moving units through cells lerps the position and facing between their initial and final values on entering/leaving the cell. This is wrong, and gives the behaviour we see where the unit slides in a different direction to its facing.
The fix is to make UpdateCenterLocation use a higher order interpolation that curves through the cell and sets the facing to the tangent of the path. I imagine that the original games used a look up table, but we could do it more easily using splines. QUICK_EDIT
I don't see why some facing increment isn't updated in parallel to the rendering, afterall if it can display the facing, it should be aware of the facing no?
Many of the movement issues between cells would be fixed if the ROT was linked to speed, and the direction of travel was linked to ROT (facing) wouldn't they? I don't see any spline calculations being necessary, that presupposes knowing the entire trajectory regardless of acceleration or other factors, which seems like the wrong approach.
I'd argue the WW engine actually does a little preplanning for aircraft, and doesn't take into account facing at a granular level which causes aircraft in some cases (when the engine is busy or the aircraft is too fast) to turn backwards instead of a banking forward turn. If the movement was always relative to the previous movement, any lag would just make the turning more jerky as precision is lost, nothing major. _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
That might be easy from a technical standpoint. Our "global chat" also uses IRC and joining servers works with openra:// links. Loading the server list is a matter of parsing a .yaml or .json file. http://www.openra.net/games/ QUICK_EDIT
The per-pixel depth calculations that I showed off back on page 3 of this thread (nearly a year ago now) are finally finished, and i'm going to strongly enourage our other devs to get the final PRs reviewed and merged before our next release.
While it may not seem like a big deal if you don't understand how our rendering works, this was actually our single biggest blocker for releasing the gen2 (isometric/heightmapped) mods. There's still a lot more work to go around the edges, but our fundamental engine design now finally supports proper isometric rendering. Like you might expect, we've gone further than TS's limited global buildngz.shp and support per-sequence depth data: this means that you can have pixel-perfect intersections, just like real 3d models, if you configure your artwork pipeline to render out depth sprites along with your normal shps.
The most obvious results are that units/weapons/etc now disappear behind cliffs, and don't disappear behind flat things like gates or building bibs.
I never checked out buildngz.shp. Can you describe shortly where this is used and how it works? So far, i only used the ZAdjust keys to hide objects behind the building or ActiveAnim.
Do you plan to incorporate such height infos into projectile hit calculations? Allowing high flying projectiles to fly over low building parts and hit high building parts. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Basically it defines a per-pixel z-offset that is applied to buildings so that the "x is in front of y" lines run diagonally, parallel to the cell edges, instead of horizontally across the sprite.
Why is this needed? Consider a building is that is much longer than it is wide, like the gate (lets call it G) in the screenshot above. An actor A that is to the NW of the bottom cell should obviously be rendered behind the gate (A < G), and an actor B that is to the SE of the top cell should obviously be drawn in front of the gate (G < B). But this is logically impossible if you use the simple rule for "things closer to the bottom of the screen are drawn in front" (which is the best you can do if you have flat sprites with no extra info), because B < A but A < G < B implies B > A. If you render the world as a bunch of flat planes then you are forced to draw one actor behind another that it should visually appear in front of. This produces bugs like ra2#147 - notice that the tesla trooper is indeed "behind" the center of the telsa reactor's footprint.
The original TS has hardcoded rules for aligning the pixel offsets stored in buildngz.shp to the footprint (this will be one of the reasons why TS/RA2 didn't let you define arbitrary footprints) and other hardcoded rules for things like bib sprites that don't use it. I've set it up in OpenRA so that everything can be defined per-sequence, so you can use depth maps that correspond to the actual sprite instead of just a generic rectangular box.
There's no plans to let these affect projectile hit calculations (we have a hard rule that gameplay simulation state can't depend on artwork or render state), but our collision logic is already much more flexible than the original games. It wouldn't be a huge effort to define a rough 3d collision shape (made out of boxes or spheres) in mod code that does the same thing. QUICK_EDIT
Working on these features sometimes gives some fun insights into the original game's development process.
A side-effect of the depth-correct rendering is that the near-ground-level laser turret beams clip through walls in a rather ugly way
So, how did WW avoid this? They cheat, of course!
Notice that the central core of the beam clips through the wall in almost exactly the same way. They then hide this by rendering a second (wider, more translucent) beam over the top with a large enough positive Z-offset to cover up the clipping.
We can measure the z-offset between the 'real' and 'z-fudged' beams by shooting through a larger structure and counting the pixel offset between the two cutoff points
This works out as 12px, or half a cell, which makes sense.
At some point I'll add the option to render the second z-fudged beam to our OpenRA lasers so that we can emulate this behaviour. QUICK_EDIT
the main beam should also get a z-fudge fix.
No reason to repeat WW mistakes or bad solutions.
It might be also nice if such a laser beam can be blocked by walls (though only if a certain key is set, like AffectedByWalls: true).
Would the current system respect the lasers start and end point height and render it correct above walls if for example the start point on the turret is 48 pixel higher?
In other words, does the laser effect have only 1 z-value for the entire line or different z-values along the line?
Is the main laser lines thickness adjustable via the weapons yaml? Could be a bit thinner to look more like TS _________________ SHP Artist of Twisted Insurrection: Nod buildings
The z-fudge isn't a fix, doing it to the main beam would just move the rendering glitches to other cases (e.g. low-flying aircraft going over the turret but under the beam). The z-values vary along the line.
Blocking height and classes are already completely customizable... some discussion of that happened back on page 3. QUICK_EDIT
any progress is good progress, no matter how slow it is.
Higher object postion towards lower target providing bigger sight and weapon range would be indeed a very nice feature.
TS has this implemented in a broken way (LeptonsPerSightIncrease / LeptonsPerFireIncrease), why it was never enabled (keys using very high values in rules.ini).
Because here it was an absolute factor. Every map height level giving a unit a certain bonus to sight and weapon range, regardless of the targets height position.
So if a flat map was entirely on height 12, all units would have a higher sight/range than on a flat map that is on height 0. _________________ SHP Artist of Twisted Insurrection: Nod buildings
The logic exists in TS, but it's not very well implemented. IIRC, units on high ground have overall longer sight and weapon range than units on lower ground. Obviously a more realistic way would be to have the range increase only in relation to lower ground (i.e. when the unit is standing near the edge of a cliff/slope).
EDIT: LKO beat me to it. AFAIK the logic was enabled in TS, at least LeptonsPerSightIncrease and LeptonsPerFireIncrease had achievable values (2000 leptons for both, meaning approximately 8 height levels).
I also remember testing it and IIRC I found that artilery on map Height level 4 could fire a cell farther than artillery on Height 0, and on Height 8 they could fire two cells farther than Height 0, respectively. The range increase could've been explained by the ballistic nature of their projectile, though, as the target was located at Height 0 in all cases. _________________ QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri Nov 18, 2016 3:17 pm Post subject:
What OpenRA got is basically a hard-check against a defined-on-the-sight-trait value, heightlevels above that value stay unrevealed. This defaults to -1 (>0 values mean disabled) and is set to 3 on the screenshot. _________________ "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
Like Graion said, this currently only supports a cutoff for cells above the actor. It would be easy to add height bonuses if someone defined a set of parameters and filter criteria that maps a height delta to a sight range. I won't be doing that myself though. QUICK_EDIT
Some more progress towards TS-style terrain: #12371 and #12430 implement ground-level bridges, and #12431 fixes the issue where units travel too far behind cliffs.
#12396 fixes the graphical glitches with carryalls and deployer units, and is just a small part of the upgrades system overhaul that will make it much more powerful and modder friendly. QUICK_EDIT
We have some more great TS progress in the review queue with #12571 implementing the bouncing disc logic, #12557 emulating the classic reveal-on-fire logic, and #12577 adding subterranean and jumpjet units plus tunnels and (indestructable but usable placeholders for) elevated bridges. QUICK_EDIT
it would be great if you added the explosion-effects of buildings and vehicles of Tiberian Sun Dusk .. ..they look really great.. ..look: .. https://vimeo.com/1156606 ..greetings.. QUICK_EDIT
MustaphaTR set up the tech level options (#12984).
MustaphaTR polished the order of our sidebar cameos (#13053).
reaperrr worked on a bunch of balance and gameplay fixes (#12921, #12606, #13164).
Me and (mainly) reaperrr worked on a bunch more graphical fixes (#12993, #13048, #13080, #13210).
Me and reaperrr fixed most of the remaining issues with Jumpjets, subterranean units, and tunnels (#12924, #13149, #13159, #13160, #13162, #13217). These now feel well integrated with the game.
atlimit8 has been working on replacing the remaining uses of actor-level disabling with trait-level conditions (#12955, #12996), which will fix several issues with the EMP cannon and stealth generators.
reaperrr has been working on Juggernauts (#13041), which has been easier said than done.
I finally got around to fixing our unintuitive range parsing in the isometric mods (#13253).
The mod support changes mentioned in our last news post are now also complete, and the new mod template has reached feature parity with the old modding setup. This has been a major task that will make life significantly better for modders, once they get over the initial learning curve. 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
of 
.
