depthmod feature request and specific reasoning.
Moderator: Moderators
depthmod feature request and specific reasoning.
depthmod currently allows for a unit to receive no penalty for movement in water.
However, for the use of aphibs I want them to like the water. Not so much run to it but realize that hey, I can go a bit faster in the water...
now I can give him depthmod and a speedboost but I have no way of telling said unit, hey the water is fine.
any way I could maybe get the ability to either apply a - val to dephmod making the unit prefer water and move faster... or just say a tag to say how much he will love the water. because it is to my understanding that we have no way to manipulate pathing in lua or cob.
However, for the use of aphibs I want them to like the water. Not so much run to it but realize that hey, I can go a bit faster in the water...
now I can give him depthmod and a speedboost but I have no way of telling said unit, hey the water is fine.
any way I could maybe get the ability to either apply a - val to dephmod making the unit prefer water and move faster... or just say a tag to say how much he will love the water. because it is to my understanding that we have no way to manipulate pathing in lua or cob.
Re: depthmod feature request and specific reasoning.
I'm pretty sure you're aware (perhaps it's of use for others though), but on your own maps, you could of course use speed modifying ground - works a charm with the pathfinding (I can remember units zoom along a "quick" mapedge in Kernel Panic). But of course that only works on those maps then... (and not very modable at that).
Re: depthmod feature request and specific reasoning.
that modified speed on the ground effects all units including units without amphib but the ability to cross into water.
Re: depthmod feature request and specific reasoning.
Hmm, I was convinced you could either set it to for a number of different movement classes, or it was hardcoded to a limited set of distinctions (eg Kbot, Tank, Hover - no idea where'd they'd be gotten from though).
The later might fail, of course, so you might be right. I'll look into it in a mo.
The later might fail, of course, so you might be right. I'll look into it in a mo.
Re: depthmod feature request and specific reasoning.
In any case, as I'm sure you both know, setting up movement modifiers for amphib units in areas that are supposed to be covered with water is not only unrealistic (as someone would have to release special versions of any maps that are to be played with Gundam) but would not work correctly once the ground started getting deformed.
Meanwhile, I bet you could do it with LUA.
Meanwhile, I bet you could do it with LUA.
Re: depthmod feature request and specific reasoning.
correctSinbadEV wrote:In any case, as I'm sure you both know, setting up movement modifiers for amphib units in areas that are supposed to be covered with water is not only unrealistic (as someone would have to release special versions of any maps that are to be played with Gundam) but would not work correctly once the ground started getting deformed.
meaning a unit that can wade but not submerse would see the water as a cheaper route. which is not acceptable.smoth wrote:that modified speed on the ground effects all units including units without amphib but the ability to cross into water.
The amphibs with speed boost in water have actual underwater propulsion methods that exceed their walking speed. They turn the full power of their fusion reactor towards their propellers. Which is why they get a speed boost.
EASILY DONE IN SPRING. Can do it in a cob.
PATHING however will tell the unit that water is not only slowing it but it needs to go way out of it's way to land. On a unit that gets a speed boost in water, treating water neutral while keeping the unit from being "afraid" of water does not tell the unit that it is the fastest route . So the player has added micro, not the desired effect.
If I could effect pathing values on individual units I would have don it. I cannot, pathing is engine side.SinbadEV wrote:Meanwhile, I bet you could do it with LUA.
Re: depthmod feature request and specific reasoning.
Ah, I was mistaken, they are hardcoded (I'm guessing Kbots are Upright = true, etc.). That makes it pretty difficult, I agree. Sorry to have detracted from your request - guess it's quite valid.
Re: depthmod feature request and specific reasoning.
There are 4 hardcoded classes - TANK, KBOT, HOVER and BOAT (ship). Units are mapped to one of those based on the name of movement class defined for that unit. For ex. in S44 the moveclasses are named like KBOT_Infantry, TANK_Truck, TANK_Light, BOAT_River, etc. AFAIK giving movement classes names without at least one of those predefined substrings causes problems.SeanHeron wrote:Ah, I was mistaken, they are hardcoded (I'm guessing Kbots are Upright = true, etc.).
Re: depthmod feature request and specific reasoning.
I thought you could intercept and redefine paths using lua now?
Re: depthmod feature request and specific reasoning.
Thanks for the info Yurich! Are those classes used for anything else but the map movement speed info ? If not, then Smoth, in principle you could adapt them to your purposes. (Edit: that is, unless you're making use of those four movementclasses on your maps already, and don't want to lose that).
The bigger problem, as I expected, would then be that you'd need special versions of maps for Gundam...
The bigger problem, as I expected, would then be that you'd need special versions of maps for Gundam...
Re: depthmod feature request and specific reasoning.
Sean, I tried to be nice, I don't think you understand the issue due to lack of experience working with the engine. Please just stop.
in fact I am going to outright say it.
you have not played gundam. if you had you would know better than to continue to suggest this "solution." It is not going to work. Please stop.
in fact I am going to outright say it.
you have not played gundam. if you had you would know better than to continue to suggest this "solution." It is not going to work. Please stop.
Re: depthmod feature request and specific reasoning.
Smoth, the problem with your request is right here:
Now, do you want them to seek water, or just not avoid it? These are two entirely different things. It sounds like you want them to just not avoid it. That should be pretty simple, I think that canHover Units already behave that way.
But if you want hovercraft with a weighting for more speed in water to not seek nearby water, if that results in the shortest path, you need to handle this with Lua.
If you just want the Units to ignore water, you can force a Unit to use a path it would normally reject, with Lua. And it doesn't require reading a typemap, either.
Just do the trig for a series of point-intercepts and give it multiple move orders between the user's points, forcing it to path exactly where you told it to, short of running into something (or having "heat" issues, per imbaczec's new code, which I haven't had a chance to play with yet).
Should be pretty easy. Only real cleanup issue is disabling this fix if none of the point-intercept points X,Y water, letting it path normally in that case.
At any rate, I would support a generic "ignore water when pathfinding" tag.
Pathfinders don't work like that. They're going to seek the optimal path, however "optimal" is defined.Not so much run to it but realize that hey, I can go a bit faster in the water...
Now, do you want them to seek water, or just not avoid it? These are two entirely different things. It sounds like you want them to just not avoid it. That should be pretty simple, I think that canHover Units already behave that way.
But if you want hovercraft with a weighting for more speed in water to not seek nearby water, if that results in the shortest path, you need to handle this with Lua.
If you just want the Units to ignore water, you can force a Unit to use a path it would normally reject, with Lua. And it doesn't require reading a typemap, either.
Just do the trig for a series of point-intercepts and give it multiple move orders between the user's points, forcing it to path exactly where you told it to, short of running into something (or having "heat" issues, per imbaczec's new code, which I haven't had a chance to play with yet).
Should be pretty easy. Only real cleanup issue is disabling this fix if none of the point-intercept points X,Y water, letting it path normally in that case.
At any rate, I would support a generic "ignore water when pathfinding" tag.
Last edited by Argh on 21 Aug 2009, 21:24, edited 1 time in total.
Re: depthmod feature request and specific reasoning.
There is no problem with the request. The pathfinder seeks the optimal path using what it knows. The units can go faster in water, and smoth wants a way to tell the pathfinder.
Re: depthmod feature request and specific reasoning.
my head asplode. once again I am reminded why I never ask for shit on this forum.. I mean we can never stay on top....oh hey look a fart joke let's talk about those...
Re: depthmod feature request and specific reasoning.
I just supported what I thought you were asking for, and provided a way to do the alternative behavior, if my assumption about your precise meaning was incorrect.
No need for head explosions
No need for head explosions

Re: depthmod feature request and specific reasoning.

anytime I go to make another request, I am going to askmyself, do I wantthis?
Re: depthmod feature request and specific reasoning.
<shrugs>
If you get butthurt when people try to help solve your problems and ask for some clarification, then you should quit making feature requests, yes. Nobody here was trying to get you riled up, Smoth.
This is a place where we're looking for solutions. Sometimes it can only be done through an engine change. Sometimes you just haven't come up with a solution and maybe somebody else has a better idea. It's just how it is. IDK why you think you're supposed to just put up a request and it'll just get taken care of- the Devs aren't our slaves, and it's up to us to show that we can't get the engine to do what we need it to do, and propose the logic that will solve it. In this case, I found your wording unclear, and so I gave you support for case A, and a code idea for case B. Neither should have caused any offense, frankly- I was trying to be supportive and constructive here.
If you get butthurt when people try to help solve your problems and ask for some clarification, then you should quit making feature requests, yes. Nobody here was trying to get you riled up, Smoth.
This is a place where we're looking for solutions. Sometimes it can only be done through an engine change. Sometimes you just haven't come up with a solution and maybe somebody else has a better idea. It's just how it is. IDK why you think you're supposed to just put up a request and it'll just get taken care of- the Devs aren't our slaves, and it's up to us to show that we can't get the engine to do what we need it to do, and propose the logic that will solve it. In this case, I found your wording unclear, and so I gave you support for case A, and a code idea for case B. Neither should have caused any offense, frankly- I was trying to be supportive and constructive here.
Re: depthmod feature request and specific reasoning.
Funny that you are the one who says that...Argh wrote:If you get butthurt when people try to help solve your problems and ask for some clarification, then you should quit making feature requests, yes. Nobody here was trying to get you riled up, Smoth.
Which is what I was asking for because there isn't another option, I talked it over already with someone else who isn't a luaknucklehead like me.Argh wrote:This is a place where we're looking for solutions. Sometimes it can only be done through an engine change.
yes because turning a thread about scaling loading pictures turning into a feature request for svg is a better idea. Or the countless other threads that others including you have derailed with side discussion completely robbing the idea of any chance of consideration. Not saying you did that here you didn't but you also didn't really read the thread. we cannot access pathing values in lua.Argh wrote:Sometimes you just haven't come up with a solution and maybe somebody else has a better idea. It's just how it is.
I welcome better ideas, that is why I am not too specific. I loathe when people completely disreguard what I am saying and try to take the thread a different direct. You have personaly done this several times to my requests. In fact when I post requests I think 3 things:
PLEASE ARGH DON'T SAY LUA OR WORLDBUILDER,
WARLORD I DON'T CARE WHAT YOU THINK MAKE YOUR OWN THREAD
FUCK THIS ISN'T TA!
It is a request which is just an open idea. Not an imperative, don't try and say anything like that about me. To even suggest that I post these as a demand is insulting!Argh wrote:IDK why you think you're supposed to just put up a request and it'll just get taken care of- the Devs aren't our slaves, and it's up to us to show that we can't get the engine to do what we need it to do, and propose the logic that will solve it.
I understand, maybe I am just a little riled due to our past history. Maybe I am pissed because I bumped two threads hoping the people who derailed them before would stay the fuck out and then even after I asked one of them POLITELY he turned it into a feature request for something else when he had the power to ACTUALLY SPLIT THE DISCUSSION!Argh wrote:In this case, I found your wording unclear, and so I gave you support for case A, and a code idea for case B. Neither should have caused any offense, frankly- I was trying to be supportive and constructive here.
I dunno man, like I said, I feel generally violated any time I suggest something. If it isn't for people just glancing over the request and making a statement(you have done this on many occasions so I didn't realize you misread as it was common practice) based on such a cursory glance. Othertimes someone takes one small piece and derails it(SVG) or decides to make the request altogether some other thing(MAPEDGES I AM LOOKING AT you WARLORD).
I dunno, just pissed because I cannot even suggest something and it get a real discussion. It is handled like a medicine ball in the hands of a drunk. Not actually passed around for discussion.
Re: depthmod feature request and specific reasoning.
we cannot access pathing values in lua
Code: Select all
PathFinding
Spring.GetUnitEstimatedPath
( number unitID ) -> nil | {
[1] = { x,y,z }, ...
},{
[1] = startIdxOfDetailedPath,
[2] = startIdxOfDetailedEstimatedPath1,
[3] = startIdxOfDetailedEstimatedPath2,
}
GetUnitEstimatedPath() returns 2 tables:
1 table the waypoints and 1 table with indices (in the waypoint table)
when a new (more lazy) pathfinding algorithm begins.
So the waypoint table contains 3 different levels of details.
Or just get the Unit's position, get some point intercepts along that line to the desired movement point, check for water at the intercepts with Spring.GetGroundInfo.
I'm not bothering to comment on the rest of that... except to say that the real question is whether the pathfinder has a weighting in favor of water movement, for Units whose moveType makes water faster, or whether it treats water as ground, and adjusts the pathfinder accordingly.
That, and I'll admit, for the record that I have been guilty of skimming your requests at least once.
Meh, I'm only human. If it doesn't have a fricking picture or very, very clear English, I may get it wrong. Problem is, the devs are also humans... so write more clearly, or make a quickie illustration to show what you actually want.
In this case, as I said... you either get Units that prefer water when that's the fastest path, or you get Units that act like water's flat ground. Which do you actually want?
Last edited by Argh on 21 Aug 2009, 22:44, edited 1 time in total.
Re: depthmod feature request and specific reasoning.
There is not water is faster for me movetype setting. The only one is depthmod which says water does not slow me.
hence the request.
hence the request.