Spring RTS Engine

KaiserJ wrote:the one thing that kind of bugs me about typemaps... there needs to be some sort of balance to how they are applied; adding a typemap for vehicles to move faster makes them OP on that specific map unless there is also a an area of typemap to make them slow down...

DsD might make a little more sense if vehicles got a movement penalty on the north area...

am i completely wrong in this? just seems to me there are ways to add a typemap without completely borking balance.

oh and units will always take the "road" if its completely flat and have to travel a fair distance along otherwise uneven terrain; i was pleasantly surprised when i discovered this.

Theres other stuff in mapping that affects balance between unit types besides typemaps so no, you dont have to balance typemaps like that. For example if you made a version of ccr where kbots/infantry get 10% speed boost would they be op?
Are hovers op on geyser plains with their 50% speed boost, or tanks useless on brazilian battlefield, or ground units op on ffa maps with roads, or tanks op on folsomdamfinal? Also pls dont say OP, its just annoying & naive imo, just say more powerful or less powerful. :D

And if I want to do a ccr-like map with 2x speed for tanks for more madness, whats wrong with that? Thats not imbalanced in any way its just different gameplay.


And tanks do move slower on most of top part of dsd. ^^

correct. The unit type should be controlled by the mod. IE if I want gundam hovers to not be included in the "hovers" category for typemap reasons, why not allow me to designate them as "ghover"?

In their movetype, don't use the word, "hover", and they won't be.

If canhover=true doesn't then result in the right behavior with that movetype, then that's a bug and we probably need a feature request to fix that- there's probably a variable we're supposed to set in the movetypeDef.

Personally, though, I think it's stupid to let hidden typemaps perform most of these things. If you just want tanks to move faster on low-slope areas, give them a slope tolerance that inhibits them moving fast on high-slope zones and speed them up. There's nothing wrong with a typemap slowing everybody but hovers down for a swamp, but it's really something where if it's not obvious to the players what's happening, it may be a problem. One thought there is that an addition to healthbar code that showed a symbol for slowed movement ala DoW would be a good indicator for players.

Argh wrote:

correct. The unit type should be controlled by the mod. IE if I want gundam hovers to not be included in the "hovers" category for typemap reasons, why not allow me to designate them as "ghover"?

In their movetype, don't use the word, "hover", and they won't be.

lol...

TradeMark wrote:make them airplanes instead...? learn to fucking lua your fucking units already... use lua! lua lua lua!!!!

I do use luadefs, I was the second person here to do that (CA was the first) thanks to lurker, and I've been using luadefs ever sense. Luadefs have NOTHING to do with movetypes.

@Argh, it's a spring thing. In movedefs you HAVE to use hover, tank, kbot, etc because otherwise your unit won't move at all (or it will default or just crash spring altogether). Your naming scheme HAS to include the unittype, otherwise, it simply doesn't work. I found that out the hard way.

I used to use DefaultMoveType2X2, etc., and everything worked fine. I think it's the TEDClass that makes that problem occur.

Argh wrote:I used to use DefaultMoveType2X2, etc., and everything worked fine. I think it's the TEDClass that makes that problem occur.

I'm afraid Forb is (mostly) right:

http://github.com/spring/spring/blob/ma ... veInfo.cpp

c.f. lines 102, 103 (ship/boat hardcoding) and 110 in particular for hover. 123 to 126 for tank / kbot. A movetype that doesn't specify SHIP, BOAT, HOVER or TANK will default to KBOT - so if you're missing a keyword in the name it should not crash and in fact the unit should still move around just fine, on land at least.

Grepping through the code, TEDClass appears to only be used to distinguish factories (PLANT) vs builders.(c.f. UnitDefHandler.cpp lines 499 & 606)

Yeah, I see what you're saying there. So basically everything in P.U.R.E. was getting lumped into KBOT or HOVER, it was just non-obvious

All the more reason for games to write control routines to fix any map using typemaps at gamestart to better fit their design requirements, imo.

Boo map is too hard to crater. Please dont do this.

If you want the centre not to deform since its concrete and that looks weird, use typemaps with different hardness for earth and concrete (the only good use of typemaps).

dont use typemaps for different hardnesses pls. that is fail with current spring/mapformat.

use only 1 hardness, then we wont see ugly terrain deformation by combombs etc... spring is buggy yeah.

"the only good use of typemaps" you fail man, its the worst use.

GloryHoleDam

600 too hard?

i was going to suggest 1000

and why look at SMD files if you can look at here:
http://mapinfo.adune.nl/?map=FolsomDamSpecial

TradeMark wrote:dont use typemaps for different hardnesses pls. that is fail with current spring/mapformat.

use only 1 hardness, then we wont see ugly terrain deformation by combombs etc... spring is buggy yeah.

"the only good use of typemaps" you fail man, its the worst use.

Let me make this perfectly clear, the large spikes on dsd caused by selfds etc are a bug in the map itself, because the typemap is aliased and thus undefined in areas, defaulting to a low hardness, where all others use large multipliers. There is NOTHING wrong with having multiple hardnesses, and yes, there can be some height differences in between them, but that is the only bug, and it can easily be mitigated by making transitional typemaps with multiple hardness levels.

Edit: trade that stuff on mapinfo lies, since it doesnt take into account the multiplier. Hardness on folsomspecial is 36000.

learn... pls... have you ever played altored divide?

now you know what i mean.

"and it can easily be mitigated by making transitional typemaps with multiple hardness levels."
yes this could be possible, but still you would see steps between different hardness levels. we need engine change that interpolates them smoothly.

Edit: trade that stuff on mapinfo lies, since it doesnt take into account the multiplier. Hardness on folsomspecial is 36000.

what the fucking multiplier, oh wait... typemap multiplier. yes i cant show 50000 billion hardness levels in one page... it doesnt lie you moron, THE MAP LIES TO YOU. just like DSD special... you think its normal, but then its not.

seriously, 1000 hardness is enough... you can see combombs in the ground and the ground wont stretch too much either.

It seems you didnt read my post, or just didnt comprehend it. Neither of which surprise me..

Edit: ah nice ninja edit, now your post makes a tiny bit more sense.

Edit2: moving all this to typemap rant thread. And also, dsd special specifically states that its not normal, as does this map

yeah so you agree typemaps arent good for hardness levels?

Typemaps are great for hardness levels and for speed modifiers, you just have to know how to use them. Having a no more than 2x difference between hardness transitions will still play fine. A hammer in the hand of a fool doesnt end well, but give a smith a hammer...

Yes BEHERITH you MORON you CLEARLY dont know ANYTHING about MAPS!!!ONE!!</irony>

Trademark, Folsom uses concrete and earth. If you look at Castles, the typemap changes in hardness look perfect there. It makes sense: The concrete doesnt move but the sand is easily displaced. The concrete is also square, so any square edges on your typemap will fit in perfectly.

Altored looks retarded because there are these huge areas around the edges of the hills that are in a different typemap, rather than the typemap perfectly fitting against the cliffface, where the difference would just seem to be an extension of the vertical cliff itself.

Yeah it can be dumb, but in this case, its perfectly suited.

it wont work if you want undeformable ground vs deformable

not enough interpolation points

This looks GOOD:



In fact, anything else would look really wrong. Imagine if the brick deformed like the sand did!

This trick in castles is one of my favourites, even among vastly superior maps. Having the messed up sand next to the unmoved brick always looks cool and gives you a tactile sense of the different types of terrain that texture alone cannot convey.

okay so sirArtturi was noob then.