Lua constants defined after defs are processed?

[smoth]

I need this for a pretty big planned feature, I need to be able to grab the map name. Unfortunately when I try to call Game.mapName in unitdefs_post I have no such luck as it tells me Game is undefined.

Is there something I am missing here?

[jK]

Why do all ppl try to use unitdef_post.lua for dynamic unitdefs?

The best is to create ALL unitdefs INDEPENDENT of the game state (players, map, ...), because the user may use an tool to see/investigate/analyze all the unitdefs (e.g. a GUI to browse them).

PS: KingRaptor had a similar problem these days and IMO he tried to solve it the totally wrong way, that's why I am so emotional

[smoth]

Because I would have to have 100s of them? because I cannot alter the unit defs post unit def for global shit like weather conditions and world climates?

*edits* Rather than berating me give me this correct alternative and I will do it but honestly, you are just shooting me down and telling me I am doing it wrong when i was told this is the way it HAS to be done.

[jK]

Because I would have to have 100s of them?

Why not?

If you want to change the models/textures depending on the climate zone this can partly done at runtime.

[smoth]

I will be very clear here on what I am trying to do. Because people just like to assume things and jump on me.

I have in the gundam maps 3 current temperature conditions(Hot maps)(cold maps)(normal). I want the environment to effect unit performance, any stat should be up for grabs even using an alternate skin.

I also have different environments(snow, urban, woodland and desert) I want the cegs to reflect the environments. Which means using alternative cegs.

The argument of a gui browsable unit information is bad please do not make that argument as I DO plan on a ui based solution for browsing units.

I am not going to create 100s upon 100s of alternate unit definitions because it is a nightmare to update each unit. Just so "the user may use an tool to see/investigate/analyze all the unitdefs." I want this to be covered in game not trusting in some 3rd party tool. There is no reason they need to browse all alternate weather conditions. This is something unique to gundam stop treating gundam like it is just another ba clone or *I* will get emotional JK.

Please do not get upset with me for seeing to climatic and weather conditions for my project. S44 has skeleton defs for units yet you choose this thread to fuss at me because of something unrelated kr did. PLEASE don't do that. Talk to me in private or something.

[FLOZi]

+1 to OP request

[Pxtl]

Well, it's always tricky to determine processing order. If you process unitdefs_post after the maps, then some clever mapper who has Gaia that is spawned according to the stats of the units in-game is going to rage that he's not getting the post-post values.

Who gets to go last? Can unitdefs_post affect pathing? If so, it seems obvious that it would have to happen before the map.

[smoth]

is this about processing maps? I am asking for the lua constants to be acessible before the defs processing. This is not maphelper stuff it is the actual game information.

I didn't see anything in the code about the map.

then some clever mapper who has Gaia that is spawned according to the stats of the units in-game is going to rage that he's not getting the post-post values.

*edit* correct I get what you are saying. So you feel mappers should be given priority?

[Google_Frog]

then some clever mapper who has Gaia that is spawned according to the stats of the units in-game is going to rage that he's not getting the post-post values.

I don't think this is a relevant point as the unitdefs alone tell the mapper absolutely nothing definitive about the game. Every single useful thing that a mapper could gleam from unitdefs can be overridden by gadgets as the game runs. For example movement data can be adjusted or ignore with movectrl, damage and health is completely changable with gadgets, the game might not even use Spring's resource system so searching the unitdefs for decent reclaim or mex values is useless.

Games can be so diverse that maps cannot learn anything from unitdefs that will make them work well with all games. On the other hand games can have maps made for them specifically so it makes sense that a game would be able to access the name of a map.

In short maps cannot hope to work with all games but maps can be made for a specific game. So it makes sense that games have more information available while loading.

[SpliFF]

Have you tried just editing the UnitDefs table directly in PreGame or something? I was under the impression unitdefs are not entirely read-only. Correct me if I'm wrong, I've never tried it.

[smoth]

I need this for a pretty big planned feature, I need to be able to grab the map name. Unfortunately when I try to call Game.mapName in unitdefs_post I have no such luck as it tells me Game is undefined.

is the pregame unitdefs stuff. the issue is the lua constants that I cannot access.

[SpliFF]

I don't quite follow your last comment/question but by "PreGame" I actually meant gadget:GamePreload() or gadget:GameStart(). The Spring and Game constants are available in these callins but I don't know if you can modify UnitDefs at this point.

[SeanHeron]

I could dig out the quote, but my info was that "yes you can change unitdefs in game - but it's an unstable feature, meant only for devving..." (and at least GameStart is certainly already "ingame" in that all the unitdefs have already been loaded - dunno about GamePreload).

I just stumbled over this gadget by Kloot (while digging through some old widgets and gadgets I'd saved cause I thought they might turn out to be interesting some time). Thought it might be interesting, at least for some of the stuff you meant to do:
http://pastebin.com/19fqxeYY. I don't know if it (still) works though ... you'd have to try for yourself.

And of course, still not as convenient as simply changing the unitdefs with knowledge of the map your on! (I'm afraid I disagree with your opinion here jK - this seems by far the easiest/smoothest solution to the problem to me as well).

[smoth]

that is not editing a unitdef.

Spliff:
You are saying before gameframe but after def processing. I have been told I cannot do that.

[FLOZi]

I don't quite follow your last comment/question but by "PreGame" I actually meant gadget:GamePreload() or gadget:GameStart(). The Spring and Game constants are available in these callins but I don't know if you can modify UnitDefs at this point.

Short answer; no.

[Regret]

As far as I know, you can include files in unitdefs_post.lua. Knowing this you can put a file into each of your maps (map/modhijack style) that would indicate any climate/other modifiers, or just the actual mapname inside the file if you're feeling redundant. You would include said file in your unitdefs_post and check whatever you want.

The obvious downside is that you would have to re-release every map where you want such behavior.

The benefit of this however is that people/you wouldn't have to rely upon you listing their/your map names inside your unitdefs_post.

[smoth]

or I could just have a map option that defaults to the desired climate and then read that.

but the problem is I do not want to re-release old maps as I find them below quality. I merely want to cover them in case someone does play them.

[Regret]

or I could just have a map option that defaults to the desired climate and then read that.

but the problem is I do not want to re-release old maps as I find them below quality. I merely want to cover them in case someone does play them.

You could make the climate/other modifiers be a modoption. That way players can play whichever map they want on whatever climate setting, map would just recommend "this default setting is how it was intended".

Maps that do have such definitions of climate would simply default to their settings. Maps without would not be left out for those wanting to play such below quality maps.

A bit offtopic: personally I consider options altering actual gameplay/stats to be modoptions. Mapoptions I consider to be things altering visual appeal or map layout.