Hardcoded kludges list (needs fixing)

[Forboding Angel]

Sounds
beep4.wav
beep6.wav
button9.wav

All are hardcoded. All are ambiguous. All need to be un-hardcoded (or at lease hardcoded with names that make sense).

-Can be changed in sounds.lua

Damage of falling debris
If you have parts pop off when a unit dies, those parts will do a hardcoded amount of damage that cannot be changed. This should not be hardcoded. It should not be worked around with lua. It should be un-hardcoded.

Edit: Lua workaround (for the sake of reference)

Code: Select all

function gadget:UnitPreDamaged(unitID, unitDefID, unitTeam, damage, paralyzer, weaponDefID, attackerID, attackerDefID, attackerTeam)
		if weaponDefID == -1 then
			return 0
		end
		return damage
	end

activatewhenbuilt defaults to false
Not much to say about this one. It just causes problems.

Lua Workaround:

Code: Select all

for name, ud in pairs(UnitDefs) do
	ud.activateWhenBuilt  = true 
end

Controlling Explosions Groundscars (From Knorke)
http://springrts.com/phpbb/viewtopic.php?f=14&t=28546

It seems there is not much controll about the groundscar texture that projectiles leave on impact?

Basically atm:
1) texture is randomly chosen
2) size is based on "default" damage
3) all weapons must use same textures

At least it seems so to me from eg
https://github.com/spring/spring/blob/d ... r.cpp#L940
but maybe I am missing something.
Is there more to control 1,2,3?

Would be nice to if something like this was possible in weapondef:

Code: Select all

groundscars = {
[1] = {texture="crater1.png", size=25},
[2] = {texture="crater2.png", size=60},
[3] = {texture="crater1.png", size=25},
}

(maybe also lifetime and some others if you want to get really fancy)

Similiar thread from 2007:
http://springrts.com/phpbb/viewtopic.ph ... rs&start=0

Dedicated transportee tags
http://springrts.com/mantis/view.php?id=3068

Checks against transportiees are done against tags with serve other purposes. I would like the unrelated purposes of these tags split such that transport behaviour can be controlled without affecting anything else.

transportSize, minTransportSize and transportCapacity and checked against unit footprintX. transportMass and minTransportMass are checked against mass. So tags transportieeSize and transportieeMass would be added.

Configurable minimap team colours
http://springrts.com/mantis/view.php?id=3067

I would like full control over a player's team colour for the purposes of the minimap display. I know Spring.SetTeamColor can change team colour for minimap and main map at the same time. I also know that "/minimap simplecolors 1" will enable simple team colours for the minimap but it appears to use hardcoded colours.

Gunship strafe distance
http://springrts.com/mantis/view.php?id=2955

Currently gunships seem to strafe at a distance dependant on the range of their longest weapon. It would be good if this hardcoded detection could be overridden with a unit tag to specify strafe range.

Shield penetration
http://springrts.com/mantis/view.php?id=2946

Currently beamlaser penetrates a shield if the shield charge is lower than their default damage. This works poorly for long beamtime weapons because while they have high damage over their beam duration they deal damage at a low rate. I would like to configure the level of charge which lets a beamlaser penetrate a shield with a tag. This tag would just control the shield charge required to penetrate, the damage dealt to the shield would be unchanged.

Configurable EMP decline
http://springrts.com/mantis/view.php?id=2684

A variable in modrules that controls the decay rate of EMP damage. Currently it is hardcoded to 100% -> 0% in 40 seconds.

Specifically for the version I looked at in https://github.com/spring/spring/blob/d ... s/Unit.cpp [^]

"float CUnit::empDecline = 2.0f * (float)UNIT_SLOWUPDATE_RATE / (float)GAME_SPEED / 40.0f;"

The magic number "40.0f" means 40 seconds. This would need replacing with a value from modrules.

Decloak behaviour
http://springrts.com/mantis/view.php?id=2683

I would like control over how effective a unit is at detecting cloaked units. Currently it is hardcoded to modelRadius. In general algorithm for decloaking is shown below for the current system:

If (distanceBetween(me, enemy) < enemy.modelRadius + me.minCloakDistance)
decloak

enemy.modelRadius should be replaced with a new unitdef tag called something like 'cloakDetectionRadius'. This value would default to modelRadius for backwards compatibility.

The tag should be able to take negative values because a unit could be really bad at detection or even completely unable to detect cloaked units.

Ignore terrain vs being able to shoot through terrain.
http://springrts.com/mantis/view.php?id=2521

From this thread http://springrts.com/phpbb/viewtopic.php?f=21&t=25731. [^] I'm making a report here as it is probably a better idea to put specific feature requests in the ticket system.

Basically the tag would skip terrain based checks for aiming and firing the weapon.

Bombers that fly straight for a while.
http://springrts.com/mantis/view.php?id=2693

After taking off bombers are unable to turn for a few seconds, this is a hardcoded duration that should be turned into a unitdef tag.

Radar Autotargeting
At the moment it is impossible to tell your units not to fire at radar dots. "Targeting Facility" only controls the accuracy of those radar dots, not the underlying behavior.

FPS Mode aiming snaps to the ground
http://springrts.com/phpbb/viewtopic.php?f=14&t=29675

Since some versions, Spring forces all aiming done in FPS mode to snap to ground or valid targets, which makes the mode pretty useless - even while conceivably nerfing a large range of exploits.



**************************************************
Anyone have any more hardcoded nonsense that they can think of?

[FLOZi]

Those sounds are not hardcoded, look in sounds.lua

Debris damage can be changed via gadget:UnitPreDamaged, iirc a weaponDefID of -1 is debris.

There's loads of junk in WeaponDefHandler.cpp but even that is mainly just strange defaults that can be overwritten.

[knorke]

If you have parts pop off when a unit dies, those parts will do a hardcoded amount of damage that cannot be changed.

http://springrts.com/phpbb/viewtopic.php?f=14&t=28455

Anyone have any more hardcoded nonsense that they can think of?

https://github.com/spring/spring
click file, see a number, make thread. yolo.

[Forboding Angel]

Knorke, jsut because a hardcoded thing can be bypassed with lua, doesn't mean that it should.

Also, the original thread name sucked. I have updated it.

[knorke]

why else would there be this parameter, if not to make a wupget

[Forboding Angel]

Maybe you want to do special things with collision damage, or debris hits, etc.

Maybe you have a kamikaze healer unit that when it dies it heals units around it (oh wait, evo cons already do that without the need of this silly junk).

For completeness? Because it might be necessary? Just because a workaround can be done with lua, doesn't mean it should be.

[knorke]

Maybe you want to do special things with collision damage, or debris hits, etc.

the nice thing, is you can do that.
or you can do simple things like always return 0 to disable debris damage.
both is possible.

Also, how would you like to have it "un-hardoded"?
A debrisDamage tag in modrules.lua?
Acuelly is moar hardcoded now, more stuff in engine then with the UnitPreDamaged.
And it allows nothing new.

Better is imo to remove hardcoded numbers from engine and make more luas so more wupgets can be made!
For example if the UnitPreDamaged did not exist, debris damage could also be a third parameter added to
Spring.UnitScript.Explode ( piece, flags, damage )
(Also add vector,speed, weapon & cegTag kkthlolthx)

---

Features must be reclaimed before construction can be started

That is imo a highly mod specific thing, it is not even a workaround: It is new gameplay logic and has no place in engine, should be wupget.
original thread: http://springrts.com/phpbb/viewtopic.ph ... le&start=0

Ok, a couple hours later, we have a perfectly functioning gadget

indeed.
If the functions of that gagdet were in engine there would be a dozen new unitdef/feature tags. And nobody would know their names or function.

[Forboding Angel]

Well, wrt tags, flozi has more or less reached god status with documenting tags in the wiki, but I see your point.

Wrt, your first paragraph, yes, I would like it to be settable via modrules. Or, for more granular control, perhaps unitdef tag.

Removed the bit about constructions squares.

[Google_Frog]

If you're making a list I have a few things to add so you don't duplicate. I like knorke's damage parameter for piece explosions idea.

Dediated transportiee tags
Configurable minimap team colours
Gunship strafe distance
Shield penetration
Configurable EMP decline
Decloak behaviour
Ignore terrain vs being able to shoot through terrain.
Bombers that fly straight for a while.

[Forboding Angel]

added

[FLOZi]

Some of my old favourites;

http://springrts.com/mantis/view.php?id=118
http://springrts.com/mantis/view.php?id=239
http://springrts.com/mantis/view.php?id=944
http://springrts.com/mantis/view.php?id=1326
http://springrts.com/mantis/view.php?id=1880 (Weapon / Projectile stuff generally remains pretty bad e.g. https://github.com/spring/spring/blob/8 ... r.cpp#L311, https://github.com/spring/spring/blob/8 ... r.cpp#L334 to 373 - one default across all weapontypes plox)


Some Big Stuff™ (That I appreciate is likely never to be addressed):

• 2 Resources (there are of course lua implementations of multiple resources, but e.g. having engine support for multiple resource maps would be nice)
• Sensor system (los, airlos, radar, sonar, seismic - again i'd like to see generalisation and abstraction)

[Forboding Angel]

Flozi, some of these are feature requests (some of google's are borderline). This list isn't really about feature requests as it is abstracting hardcoded values in the engine.

[FLOZi]

Flozi, some of these are feature requests (some of google's are borderline). This list isn't really about feature requests as it is abstracting hardcoded values in the engine.

Given the quality of the OP, I don't think we need to worry too much about what this thread is.

[mod] That's not really encouraging the kind of atmosphere we want here. [/mod]

[Forboding Angel]

So because I was wrong about those sounds being hardcoded the entire thread and it's premise is null and void. Nice logic.

[FLOZi]

Far from it - only that the definition of 'hardcoded kludges' extends to behaviours, as well as magic numbers.

If things are so black and white, please point out which of those mantis tickets is which.

(and oversensitive mod is oversensitive) <--- backseat moderation violation? please spank me.

[PicassoCT]

This is getting constructive.

Question is actually, which of those cant be dirty workaround? and how much time does it cost to work around? Does it actually amount to a full hour devtime?

Upspring is annoying, but i still adapt to it. Demanding a rewrite of upspring i will do on every ocassion, but would it make actually sense? Nope.

So i would prefer it rather more, if the devs would introduce something new. Something that puts us ahead of other rts-games out there.

[velteyn]

So i would prefer it rather more, if the devs would introduce something new. Something that puts us ahead of other rts-games out there.

Yes , for example my StoryTelling Engine on which Im working right now !!

[Jools]

Can weapon sounds be changed at runtime? Because I would like to have sounds that occur far from base (outside LOS) be turned off or at least more silent. Are these sounds hardcoded:

Code: Select all

 WeaponDefs[3]["hitSound"] = {
     [1] = {
       ["id"] = 9,
       ["name"] = "xplodep2.wav",
       ["volume"] = 28.982753753662,
     }
   }

I mean, can I change the volume when game is running?

[Jools]

Some of my old favourites;

Some Big Stuff™ (That I appreciate is likely never to be addressed):

• Sensor system (los, airlos, radar, sonar, seismic - again i'd like to see generalisation and abstraction)

Sonar system is very stiff: if I understood it correctly, it just acts like a switch for converting normal LOS into underwater one. There is no way an unit can be within sonar but outside underwater LOS. Sonar should be like radar, only underwater.

Edit: to be more specific, it seems there is no underwater LOS. Underwater LOS = normal LOS + check if within sonar. Unit's should be able to have differing LOS distances over- and underwater.

[Forboding Angel]

Yeah, sonar is pretty lackluster. Is it even possible to have underwater radar dots?