weapondefs_post.lua and map gravity

[yuritch]

I'm trying to do some adjustments to ballistic weapons based on map gravity, and I've run into a problem. Basically, it seems that when weapondefs_post.lua runs, Game object is not yet there. Ie Game.gravity is not defined. Is there a way to get map gravity value at this stage (short of parsing the smd of course)?
I know about myGravity tag for weapons, but I'd rather want to use the value from the map if possible.

[imbaczek]

IIRC the engine loads the mod first, then the map, so gravity being undefined makes sense. you have to parse the map yourself.

[FLOZi]

Or write a gadget to edit all the weapon defs after the map is loaded.

[yuritch]

I tried making that a gadget, WeaponDefs table doesn't seem to be writable ingame however (unlike weapondefs_post stage). Or maybe you meant something else by 'edit all the weapon defs'?

[Pendrokar]

I tried making that a gadget, WeaponDefs table doesn't seem to be writable ingame

Trepan made something that should have worked but doesn't. - viewtopic.php?f=23&t=9337

I have already PM'ed him but he hasn't answered after two months even though he does still show up here!

[Pendrokar]

Is there a search function for the subversion repository?

[lurker]

There are a few commands that require cheat mode; I'm thinking about letting modrules use them. As far as editdefs, trepan and jK said there was a risk of desyncing. I may have misunderstood and they just meant the cached and calculated that wouldn't update properly, which is a risk in itself but one that I think should be bypassable.

[Peet]

Is there a search function for the subversion repository?

Google search of the site, or checkout and use windows search or whatever you want locally.

[Pendrokar]

Strange I tried with google once but it didn't go into files!

Thanks!

[Argh]

There are a few commands that require cheat mode; I'm thinking about letting modrules use them. As far as editdefs, trepan and jK said there was a risk of desyncing. I may have misunderstood and they just meant the cached and calculated that wouldn't update properly, which is a risk in itself but one that I think should be bypassable.

Just having editdefs available would be awesome, I've had a few things come to naught because of that lack.

[lurker]

Just having editdefs available would be awesome, I've had a few things come to naught because of that lack.

Give me some cases and I can tell you if they would work or not.

[Argh]

Well, for example, I wanted to edit the output of mexes, for dynamic-balancing purposes...

[yuritch]

Dynamic mex output was done in S'44 some time ago (maybe SWIW got it first, and we got it from them - can't remember exactly). Basically it worked as this: the longer you own the flag (mex), the more it produces (up to a certain limit). That worked w/o any engine changes, so I think whatever is needed for that is in already.

[Argh]

Hmm. I was thinking that the only way to do it would be to give a fiat output to the unit, which I was trying to avoid (for reasons that seem arcane at this point even to me). At any rate, yeah, having access to the UnitDefs would be very, very useful. More useful would be to be able to assign a Unit a new UnitDef on the fly. That would be extremely handy- no more limited transformation stuff, where I have to lock the Unit down, I could just say, "finish your animation, run this Lua, you're now this UnitDef", which would get rid of a lot of sucky hacks in P.U.R.E.

[lurker]

You still have to reload the unit; what are you forced to do that's very hacky?

[Argh]

I'm forced to put it at 0 height, and make it face one of the 4 valid BuildHeadings, because CreateUnit always puts Units on the ground, and must be passed values 0-3 for heading.

Ideally, I'd create the unit at the height of the Unit and be able to pass it the orientation of my choice- then it's just minor issues of making the animation states match.

Note: I would not be in favor of changing the current CreateUnit, as that would hose a lot of people. I'd rather have another callout, specifically for doing stuff like mid-air transformations, etc., so that I can do stuff like helicopters that have a "hover" mode with different flight behavior, aircraft with a "afterburner" mode where they can't shoot, but go really fast, boats that do an animation that makes them look like they're a rocket taking off... then replacing them with the rocket, etc., etc., etc.

And yes, I've tried creating the Unit, then immediately MoveCtrl'ing it... it just doesn't work well at all, when tested, you always see a flash of movement first, and it's ugly.

[hoijui]

whatever you do.. keep in mind, that all current AIs assume that a unit, once created, does not change its UnitDef until it dies, and it is also assumed, that UnitDefs never change during a running game.
of course, we can not let game/mod designs be limited by this, but.. just keep it in mind, and when developping a solution for this, make sure AIs have at least a change to cope with it.
as you somehow pointed out, Argh, we could probalby have an other call, in addition to UnitCreated, we would probably need UnitDefChanged(int unitDefId), UnitsUnitDefChanged(int unitId, int oldUnitDefId, int newUnitDefId). we could even try to make the old AIs support this, by making the LegacyCppLayer send out a UnitDied followed by a UnitCreated, instead of the unitDefChanged. Though, there is no way ot make them support dynamic UnitDefs without major changes, i think.
this behaviour would be usefull for AIs when morphing units already, i guess.

... what would happen during the transformation? as.. like in morphing, the unit is in a comparable state like paralyzed, as the AI can not do anything with it (i think, AIs do not even know about paralyzed units so far). Maybe we would need a UnitUnusable() event?
What about thigs that transform while in action? Eg a plane that enlarges its wings, which takes some frames, but the plane is still moving and may be given orders during that time. hmm.. should not be a problem i guess.. just change the unitDefId at the start of the transformation.

[Argh]

The main problem is that I can't do the creation with decent flexibility. I don't really need to change UnitDefs, and I can see how that's a problem.

If I can instantly replace one Unit with another on the fly and have the orientation, heading, velocity and height all be correct (sorry, I forgot velocity, that's rather important). Right now, I have to do various animations, Units must come to a complete halt, etc., which is annoying and complicated. It'd be much cooler, if I could just do a quick animation and voila, I'm transformed.

[Nemo]

For dynamic metal extraction:

Spring.SetUnitMetalExtraction (number unitID, number depth [,number range]) -> nil

[lurker]

So the unit rendering position is possibly being delayed a frame? You say that you set it all at once in the same microsecond as creating the unit?