These would be of great help to CZTA (and probably AATA and WD) if implemented. Mostly to do with transports
1. Whilst Mass is a pretty good way of limiting what transports can carry, it would also be nice if you could specifiy which types of units it can carry (use the unit categories, like VTOL etc). This would come in very useful for CZTA, which uses transports as reloaders (ammo system is basically static-vars that get increased every time a unit is loaded, with a max limit of course) and, of course, transporters. It makes sense that a troop carrier shouldn't carry a tank. Whilst that seems like it could be implemented via mass and that, tank transporters would be able to carry infantry, and I don't want that happen
2. A OnLoaded(unitname) and OnUnloaded(unitname) where unitname is the name of the transporting unit (ie PSY_INFTRAN - the Psychasi infantry transporter) would be necessary for distinguishing between transporters and reloader transports
3. The ability for units to detect what they're loading would be nice.
4. I recall reading somewhere that weapons with the interceptor=1; tag has to be stockpiled. I'm not sure if this has been done already, but can it be made so that it doesn't need to be stockpiled?
5. A lot of the features of CZTA rely heavily on static-vars (the ammo and morale systems for starters). Could there be a way to show what static-vars are being changed? (send them to a static-var log or the error log or something)
Wishlist / Ideas List
Moderator: Moderators
?)
With hover and ship transport script, I can manage to know what kind of unit is loaded, and to refuse to load certain units.
Basically, the engine passes the ID of the loaded unit to the script. From that I use get UNIT_HEIGHT(unit_ID), which gives me the height of the 3do of the unit that is loaded (disregarding any piece movement, just the height of the plain, unchanged, 3do). By comparing the height to known unit heights, I can then know what kind of unit is being loaded.
However, tradionnal transport planes use a different loading method, that leave me with no control over what/how/when/whether it loads.
I wonder if Spring support using hover/ship transport script on planes. Would be interesting.
I could script something that, when setSFXoccupy is called with a null value (which, in TA at least, signals that the unit is being loaded), check for transport around to see which one loaded the unit, but that would more hacky, because the closest transport may not be the one who loaded it, and because it requires a fixed unitlimit to be able to "look around for units".
Swewas:
isairbase=1; in the transport FBI allows units to fire from within transport.
Oh, and I request a way for a script:
- To know what is the range of valid ID.
- To know if a unit belong to the same player. (In TA, there was always enough room for 10 players, and ID of the same player would be next to each other, while spring use a common ID pool for all player, which mean that in TA I could deduce the team appartnance with if ((other_unit_ID - 1)/units_per_players==(self_ID - 1)/units_per_players) whilst in Spring I can't.)
A great lot of my nifty scripts would need that!
Basically, the engine passes the ID of the loaded unit to the script. From that I use get UNIT_HEIGHT(unit_ID), which gives me the height of the 3do of the unit that is loaded (disregarding any piece movement, just the height of the plain, unchanged, 3do). By comparing the height to known unit heights, I can then know what kind of unit is being loaded.
However, tradionnal transport planes use a different loading method, that leave me with no control over what/how/when/whether it loads.
I wonder if Spring support using hover/ship transport script on planes. Would be interesting.
I could script something that, when setSFXoccupy is called with a null value (which, in TA at least, signals that the unit is being loaded), check for transport around to see which one loaded the unit, but that would more hacky, because the closest transport may not be the one who loaded it, and because it requires a fixed unitlimit to be able to "look around for units".
Swewas:
isairbase=1; in the transport FBI allows units to fire from within transport.
Oh, and I request a way for a script:
- To know what is the range of valid ID.
- To know if a unit belong to the same player. (In TA, there was always enough room for 10 players, and ID of the same player would be next to each other, while spring use a common ID pool for all player, which mean that in TA I could deduce the team appartnance with if ((other_unit_ID - 1)/units_per_players==(self_ID - 1)/units_per_players) whilst in Spring I can't.)
A great lot of my nifty scripts would need that!
this feature is needed for what i'm planning but I think it could be usefull for other mods (like WH40k, AATA and WD)
if you put 2 different units in the same slot of the same build menu, you could get a random unit instead of a conflict; each time you press on the buildpic you get a random unit and the picture switch to the one being built
ex. in SWTA you could build a Jedi and get a single saber or dual saber or double saber jedi.
note that i don't mean different model but totally different unit and in this way you could able to mix different unit classes (troopers with vehicles).
also, there should be a tag in the fbi to unlock the unit only if a specific map is detected (by the map name from a set of map) and a "priority" tag to override low priority units
another ex. for SWTA, in a casual map you have the basic stormtrooper randomized between stormtroopers with different equipment (blaster rifle, repeater rifle, flamer, e-web), but in a desert map (ex. "painted desert" is detected) you get sandtroopers (with different weaponry) instead and the Dewback rider became avaiable (or unlocked). same for an ice map where basic stormtroopers, sandtroopers and Dewback are locked and Taun Taun and snowtroopers are unlocked (the basic trooper is not avaiable for the priority tag)
if you put 2 different units in the same slot of the same build menu, you could get a random unit instead of a conflict; each time you press on the buildpic you get a random unit and the picture switch to the one being built
ex. in SWTA you could build a Jedi and get a single saber or dual saber or double saber jedi.
note that i don't mean different model but totally different unit and in this way you could able to mix different unit classes (troopers with vehicles).
also, there should be a tag in the fbi to unlock the unit only if a specific map is detected (by the map name from a set of map) and a "priority" tag to override low priority units
another ex. for SWTA, in a casual map you have the basic stormtrooper randomized between stormtroopers with different equipment (blaster rifle, repeater rifle, flamer, e-web), but in a desert map (ex. "painted desert" is detected) you get sandtroopers (with different weaponry) instead and the Dewback rider became avaiable (or unlocked). same for an ice map where basic stormtroopers, sandtroopers and Dewback are locked and Taun Taun and snowtroopers are unlocked (the basic trooper is not avaiable for the priority tag)
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
-
Sean Mirrsen
- Posts: 578
- Joined: 19 Aug 2004, 17:38
Yeah, something like MapCategory tags. However, I think that this would need to be more of a download TDF issue than a unit issue. In a sense that in the TDF, a certain line would say which map type is this menu item active in, and another would say which map type is the item inactive in. By default, the latter is nil, and the former is also nil, which the engine detects to be "any map". The "no" filter has precedence over the "yes" filter when there are conficts, but it's kinda stupid to write both at the same time - usually you either don't want a unit to appear on certain maps, or want it to only appear on certain maps.
Yeah, I really wish someone would do that code for us. It could really be useful!Guessmyname wrote:Except that would require an update for every map. A better way would be, instead of map names, map types are used. A new value is added to the .smd that tells the engine what type of map it is, ie Urban, Snow, Jungle etc.
That would be far easier to use
They refused to put it in then and they probably will again. And when I made it, the new map format was still unreleased or fairly fresh, so if it had been included then all the maps wouldn't have needed remade to have the tags...
Oh well.
if you have to modify the map file then you have to update all the old maps, so I think it's better to use the map name. as you update your mod, you update the map list. also, a Mos Eisly SW map is either a desert map, a urban map and possibly a different type of map, it could change for every mod. you can have a map with water, sand, rocks and other things so only the mod designer has the right to choose the which fit with which map.
ex. in a map with a big lake in the middle, you won't have your basic stormtroopers replaced by scuba trooper, you'll need a hover transport
ex. in a map with a big lake in the middle, you won't have your basic stormtroopers replaced by scuba trooper, you'll need a hover transport
