Engine Testing - 29. May 2012 (88.0.1-264-g89ee3b2)

[Deadnight Warrior]

More specifically, SET MAX_SPEED from cob side only takes effect for one frame. After that they're free to move again. To see: grab spring1944.net/files/Build/S44v159_PreMorgenroteTRI.sdz and any map, plug it into 88+. /cheat /give germg42 /give 10 gerhqengineer.

From my experience it takes effect for one move order. I had to hack around that by setting MAX_SPEED on every StartMoving() in COB, seems to work then, at least for XTA.

And now some bugs (or tweaks needed)

• Occasional terrain rips/cracks after constructing a building with terrain autolevel, could be a ROAM bug
• Construction aircraft spin randomly over the unit they're constructing and don't hover around it in circles as before
• line AA of range circles on minimap is in lower quality when the unit is selected than when you hold shift and hover mouse over the same unit (has been like that for a long time, or maybe the lines have different thickness)
• Shadows are barely visible while in F2 and F4 overlay mode, for F1 it's ok (related to next issue)
• Fully passable terrain in F2 mode is too bright (radioactive puke green, kills shadows), while terrain in F4 mode is too dark (but it depends on the map lighting or sun direction)
• All overlay modes appear to be in lower quality than they where in 88.0 (I'd say one mip level less, most noticeable in F1 mode)
• If radar/sonar range is modified from unit's script (COB, didn't test from LUS), hovering mouse over unit while pressing shift will show wrong range, on minimap radar/sonar ranges are shown correctly when unit is selected, but will show a secondary range circles when holding shift with incorrect ranges (it's a rather old bug)

EDIT:
Forgot to add the ancient bug of radar jammer jammin your own radar. When I last spoke about it with Kloot he mentioned that the engine makes radar and jammer coverage arrays for each team, but reads global jammer coverage instead. Dunno if he ever taken a deeper look as it was late that night.

[Beherith]

Info textures are way too bright. With LOS mode on one should see terrain like it is normally when it is in los and under radar cover.

Thanks for all the hard work, devs, and thanks for giving us ssmf+shadows when drawMode!=drawNormal

[PepeAmpere]

.. ah one more question (maybe silly) to that still changing pathing:

I think theres no way how to change the parameters of the pathing (mentioned in changlog, MAX_TEAM_SEARCHES for example) and make the default setup customized to game needs.. OR? If Im wrong, rest of the question doesnt matter.

If its not possible to change the parameters, i wonder spring provide only one(two) type(s) of pathing to such different games/mods with such different scales/numbers of units. And it still changes!

There are some aspects that create the game and make the biggest part of the feeling from playing - one is unit look, visual identity, that is mostly in hands of creators and second - the behavior of units completing players commands. All other aspects can be changed, but doesnt affect the feeling from playing so much. Some changes of the second king (changed behavior - comming with every new Spring) can be fixed by rebalancing all unit definitions or making own lua, but doing it after every new spring release only becouse some game/mod_creator + engine developer prefere moving of less units looks like quite wasted work for me.

Do you plan to access the pathing parameters (some others) for mod/game creators? If it is accessed, where i can do that (i found only this page but it allows to change the parameters of nodes only - http://springrts.com/wiki/Lua_PathFinder)?

[Beherith]

Forgot to add the ancient bug of radar jammer jammin your own radar. When I last spoke about it with Kloot he mentioned that the engine makes radar and jammer coverage arrays for each team, but reads global jammer coverage instead. Dunno if he ever taken a deeper look as it was late that night.

I actually dont think of this as a bug, I kinda like the fact that jammers jam for everyone. Special tactics.

[Forboding Angel]

I actually dont think of this as a bug, I kinda like the fact that jammers jam for everyone. Special tactics.

It should be configurable to be either way. While it may be good for BA/R, it may not be good for other games.

Also, in the real world radar jamming doesn't really work that way: http://en.wikipedia.org/wiki/Radar_jamm ... _deception

[BaNa]

I actually dont think of this as a bug, I kinda like the fact that jammers jam for everyone. Special tactics.

It should be configurable to be either way. While it may be good for BA/R, it may not be good for other games.

Also, in the real world radar jamming doesn't really work that way: http://en.wikipedia.org/wiki/Radar_jamm ... _deception

wat.

In some cases, jamming of either type may be caused by friendly sources. Inadvertent mechanical jamming is fairly common because it is indiscriminate and will affect any nearby radars, hostile or not. Electronic jamming can also be inadvertently caused by friendly sources, usually powerful EW platforms operating within range of the affected radar. Unintentional electronic jamming is most easily prevented by good planning and common sense, though sometimes it is unavoidable.

[zerver]

Units are sometimes firing in a direction before the turret has turned in that direction. Give a couple of ground attack orders to e.g. laser and it will happen pretty soon. This is an old bug, but does anyone know if it is engine or unit script related?

[FLOZi]

Units are sometimes firing in a direction before the turret has turned in that direction. Give a couple of ground attack orders to e.g. laser and it will happen pretty soon. This is an old bug, but does anyone know if it is engine or unit script related?

Sounds script related (lacking WaitForTurn in AimWeapon, or even excessively large tolerance on a weapondef can do this), what game?

[KingRaptor]

I'd thought that was an effect of AimWeapon now running at a fixed frequency of once every 15 frames.

[Forboding Angel]

@bana, read what you copy and pasted:

In some cases, jamming of either type may be caused by friendly sources. Inadvertent mechanical jamming is fairly common because it is indiscriminate and will affect any nearby radars, hostile or not. Electronic jamming can also be inadvertently caused by friendly sources, usually powerful EW platforms operating within range of the affected radar. Unintentional electronic jamming is most easily prevented by good planning and common sense, though sometimes it is unavoidable.

That is obviously the exception, not the rule.

I'm pretty sure that in the years of total annihilation, they've figured out that jamming on their own radar frequencies is a stupid idea.

The entire concept of jamming your own radar is ridiculous in TA/BA. You have 2 armies, both of which are VERY structured, yet they suffer from jamming their own radar frequencies because they don't know how not to jam on the frequencies that they use?

That argument is ludicrous.

[Forboding Angel]

Units are sometimes firing in a direction before the turret has turned in that direction. Give a couple of ground attack orders to e.g. laser and it will happen pretty soon. This is an old bug, but does anyone know if it is engine or unit script related?

Sounds script related (lacking WaitForTurn in AimWeapon, or even excessively large tolerance on a weapondef can do this), what game?

Yeah this is how you fix that, but I have noticed even in evo where I have wait for turns listed, sometimes it happens. I hadn't considered tolerance though so that is possible.

It's worth noting that on beam weapons, when the target is destroyed, the turret moves and the beam comes out at a 90 degree angle because for some silly reason, the beam isn't attached to the firing piece.

[Google_Frog]

Is there anything wrong with testing 88.0.1-288-ge6ccde3 instead?

[Beherith]

Code: Select all

weapondefs = {
			core_canlaser = {
				areaofeffect = 8,
...
				targetmoveerror = 0.20000000298023,
				thickness = 3,
				tolerance = 1,
				turret = true,
				weapontype = "BeamLaser",
...
			},

Code: Select all

AimPrimary(heading, pitch)
{
	signal SIG_AIM;
	set-signal-mask SIG_AIM;
	turn turret to y-axis heading speed <270.000000>;
	turn head to x-axis <0.000000> - pitch speed <170.000000>;
	wait-for-turn head around y-axis;
	wait-for-turn turret around x-axis;
	start-script RestoreAfterDelay();
	return (1);
}

What am I doing wrong? (This is not a new thing, but in 88)

[Forboding Angel]

You aren't doing anything wrong, that's just the way beamlasers work and they need to be fixed.

[Google_Frog]

You're using COB. What is broken about beamlasers?

[Forboding Angel]

Everything.

[luckywaldo7]

You're using COB. What is broken about beamlasers?

Doesn't this use a Lua unit script?



Made by spamming attack commands and occasionally it goes goofy like this.

In this case, the grizzly is pointing at the old attack location, while the beam is attacking the new attack location. The attack command changed just as it was about to fire. So its like the new attack command updated for the actual attack, but the re-aim animation didn't respond.

This is also repoducable on other weapon types though, like the warrior emg.

[FLOZi]

Protip: It's an ancient issue with all weapons with salvosize > 1, used to result in S44 tank MG's firing all over the place (still does, only now they are invisible)

[Google_Frog]

I thought there was something more than that old issue.

[Deadnight Warrior]

Dunno if someone mantised it, but QTPFS still fails at units getting stuck in factory. It happens only when unit's footprint is equal (I assume and larger than, but couldn't test it due to game design) to factory construction lane size and more often if the factory was built on rough terrain (that had to be autoleveled) or rotated to any direction than south.