Reprogrammed Launchers: experiment in typGetXML + typCreate

A place to discuss mods in development and concepts for new mods.
relanat
Militia Captain
Militia Captain
Posts: 941
Joined: Tue Nov 05, 2013 9:56 am

Works beautifully. Definitely ready for xelerus IMO. That way you might get feedback on whether you need too many or too few missiles to upgrade the launcher. I was using GodMOD to create missiles again so can't comment on actual gameplay. The only suggestion I have is to mention on xelerus that you need to use missiles one level higher to upgrade the launcher. This may not be obvious to someone trying the mod.
gunship256 wrote:Is there an advantage to using a virtual ship as opposed to a virtual station?
Absolutely no idea. I used marsrocks' example (see TargetLock mod). Note that they weren't virtual ships, they were one pixel ships. I've since seen an example of a ship with 'virtual="true"' in it's xml. This would be a true virtual ship. Whether they are virtual or one pixel ships could affect what you can and can't do in the <Events> area and may have other effects too. Others will know more.
You could also, depending on what you are trying to do, try virtual items. But it would seem that lambdas are the better method unless something can't be done with them. Thanks for the link, its a good one. I might give them a go now.

Also of note are the functions sysAscendObject and sysDescendObject. I think they're used in the game to move Volkov, etc between systems without losing any of the stored info that he might need. The only example I've found is in RPGCharacters.xml in Transcendence_Source. These might be of use to you if you are trying to preserve data through different star systems.
Stupid code. Do what I want, not what I typed in!
gunship256
Militia Commander
Militia Commander
Posts: 451
Joined: Sat Jul 25, 2015 11:41 pm
Location: repairing armor

OK - here's a new alpha!
d064_ReprogrammedLaunchers 0.15 alpha.zip
(39.22 KiB) Downloaded 331 times
CHANGES

Added support for Corporate Command missiles: Thera ammo, Orkan missiles, and chimeric plasma missiles. The missiles are overwritten in a separate mod file that must be selected in order to make the missiles usable. The file cannot be selected if Corporate Command is not enabled.

Added repeating="2" to Dragonfly cartridges, since the cartridges are supposed to fire 3 missiles per shot. This change does not affect the vanilla Dragonfly missile system; see comments in my code for more details.

Added the "military" tag to typCreated launchers that are level 7 and higher.

Descriptive text in the launcher upgrade dockscreen now indicates what level of missiles are necessary to upgrade the launcher, just in case it isn't immediately clear that missiles one level higher than the current launcher level are necessary.
relanat wrote:Works beautifully. Definitely ready for xelerus IMO. That way you might get feedback on whether you need too many or too few missiles to upgrade the launcher. I was using GodMOD to create missiles again so can't comment on actual gameplay. The only suggestion I have is to mention on xelerus that you need to use missiles one level higher to upgrade the launcher. This may not be obvious to someone trying the mod.
Thanks for the feedback! I plan to put the mod on Xelerus this month.

I made a chance to the upgrade dockscreen's description so it's clear what level of missiles are necessary to upgrade the launcher. Your suggestion makes sense; if someone is playing and doesn't have the right level of missiles necessary to do the upgrade, he might think that the mod is broken.

BTW, since I added the CC missile overwrite, I got to try Thera ammo for the first time. It's very powerful, especially when the launcher is set to swivel. If only the shells were easier to get...
NMS
Militia Captain
Militia Captain
Posts: 569
Joined: Tue Mar 05, 2013 8:26 am

I downloaded this mostly to see an example of XML manipulation functions in action. Writing XML in tLISP strings is gross, but it's cool that it works.

I did have an idea about balancing fire rates. Set the fire rate to 1, keep a counter variable on the item, create a recurring timer in every system (or maybe just use one msnAddRecurringTimerEvent?) that reduces the counter by 1 if it's above 0 every tick, and use an <onFireWeapon> event to suppress firing if the counter is not 0 and increment it by a variable amount depending on the selected ammo when it does fire. You could also replace some or all of the normal shots with sysCreateWeaponFire.
gunship256
Militia Commander
Militia Commander
Posts: 451
Joined: Sat Jul 25, 2015 11:41 pm
Location: repairing armor

NMS wrote:I did have an idea about balancing fire rates. Set the fire rate to 1, keep a counter variable on the item, create a recurring timer in every system (or maybe just use one msnAddRecurringTimerEvent?) that reduces the counter by 1 if it's above 0 every tick, and use an <onFireWeapon> event to suppress firing if the counter is not 0 and increment it by a variable amount depending on the selected ammo when it does fire. You could also replace some or all of the normal shots with sysCreateWeaponFire.
That's an interesting idea. It sounds like I could search for weapons and launchers that fire that missile and take a geometric average of their fire rates in order to determine how fast each missile should be fired.

Is there a way in tLisp to access a list of weapons that can fire a particular missile? Does tLisp also include a way to grab that weapon's fire rate?

Also, where do you suggest that I store the fire rate for each missile once it's calculated? Is that what typSetData is for?
NMS
Militia Captain
Militia Captain
Posts: 569
Joined: Tue Mar 05, 2013 8:26 am

API 29 added the 'fireDelay property. I'm not aware of a tLisp function to check compatibility for weapons and ammo though. I guess you'd have to iterate through all the weapons in the game using XML functions to see what ammo they use. You could make a list sorted by ammo type, so you'd only have to do it once. Using typSetData on the launcher type is probably the logical way to store the data.
User avatar
pip
Militia Lieutenant
Militia Lieutenant
Posts: 114
Joined: Fri Jul 13, 2012 6:31 am

I've played more than a dozen games with this now, and I'm fairly confident in saying that even "as is" this is one of my favourite mods.

The feed-to-advance mechanic feels completely unobtrusive, and acts as a pretty good ratchet for progression.
It also acts as a moderate incentive to actually use looted ammo instead of ignoring/ditching/selling it.
This incentive is further enhanced by the ability to have the launcher set to omni fire. Even with the fire rate malus it makes unguided munitions usable.
Spoiler: Note
The biggest draw though, is the ability to use virtually anything without having to change your ship config.
This is a big deal, big enough to be a significant "put off" for a whole host of weapons which would otherwise be a huge hassle to use.
Eg; I had no idea how brutal Nandao bolts were if you could aim them properly, because I never saw the point of installing the gun and struggling trying to hit anything with it.

This is a good mod.
User avatar
digdug
Fleet Admiral
Fleet Admiral
Posts: 2620
Joined: Mon Oct 29, 2007 9:23 pm
Location: Decoding hieroglyphics on Tan-Ru-Dorem

NMS wrote:API 29 added the 'fireDelay property. I'm not aware of a tLisp function to check compatibility for weapons and ammo though. I guess you'd have to iterate through all the weapons in the game using XML functions to see what ammo they use. You could make a list sorted by ammo type, so you'd only have to do it once. Using typSetData on the launcher type is probably the logical way to store the data.
it's possible to do that without XML functions, typgetdatafield can retrieve the number of missiles used by a launcher and their UNIDs.

Code: Select all

(typgetdatafield 16400 "variantCount") -> 7

; The above returns the number of missiles that are
; compatible with the NAMI launcher

(typgetdatafield 16400 "speed:1") -> 45

; This returns the speed of the first missile compatible with the NAMI

(typgetdatafield 16400 "speed:3") -> 40

; This returns the speed of the 3rd missile (which happens to be the Stiletto).
; The order is the same as that in which the missiles are listed in
; the launcher XML.

(typgetdatafield 16400 "ammoType:3") -> 16405

; This returns the UNID of the 3rd missile.

(itmGetProperty item|type 'fireDelay) -> value

; this is the number of ticks elapsed between shots, adjusted for enhancements.

(setq firerate (divide 1000 (typGetDataField UNID "firerate")))

;returns a firerate of a weapon (XML number)
NMS
Militia Captain
Militia Captain
Posts: 569
Joined: Tue Mar 05, 2013 8:26 am

Good to know. But how do you find out what values are valid for typGetDataField? Source diving?
User avatar
AssumedPseudonym
Fleet Officer
Fleet Officer
Posts: 1190
Joined: Thu Aug 29, 2013 5:18 am
Location: On the other side of the screen.

 Actually, typGetProperty is preferred over typGetDataField. It can access everything that typGetDataField can, and (fncHelp typGetProperty) will return the valid properties and/or data fields that can be accessed. (With one known exception if you’re running from TransData instead of Transcendence itself, anyway. I ticketed that this morning.)
Image

Mod prefixes: 0xA010 (registered) and 0xDCC8 (miscellaneous)

My mods on Xelerus: Click here!

Of all the things I’ve lost in life, I miss my mind the least. (I’m having a lot more fun without it!)
NMS
Militia Captain
Militia Captain
Posts: 569
Joined: Tue Mar 05, 2013 8:26 am

digdug wrote:

Code: Select all

(typgetdatafield 16400 "speed:1") -> 45

; This returns the speed of the first missile compatible with the NAMI

(typgetdatafield 16400 "speed:3") -> 40

; This returns the speed of the 3rd missile (which happens to be the Stiletto).
; The order is the same as that in which the missiles are listed in
; the launcher XML.
This is almost right, but the index is 0-based, so 1 is the second one and so on. If you call an index that's out of range, you get the result for the first one (index 0). So if you iterate from 1 to variantCount, instead of 0 to variantCount - 1, you'll get all the variants, but the first one will be last.

AssumedPseudonym wrote: Actually, typGetProperty is preferred over typGetDataField. It can access everything that typGetDataField can, and (fncHelp typGetProperty) will return the valid properties and/or data fields that can be accessed. (With one known exception if you’re running from TransData instead of Transcendence itself, anyway. I ticketed that this morning.)
It does appear that typGetProperty works for all the same inputs as typGetDataField, but this is not documented in the help for any function. The use of typGetDataField is documented only on this page, as far as I can tell:
http://wiki.kronosaur.com/modding/funct ... tdatafield
User avatar
digdug
Fleet Admiral
Fleet Admiral
Posts: 2620
Joined: Mon Oct 29, 2007 9:23 pm
Location: Decoding hieroglyphics on Tan-Ru-Dorem

typGetProperty has actually many more valid properties than what is returned by fncHelp:

I tried to assemble a list with all the properties I could find:
http://etherpad.kronosaur.com/p/itmgetproperty#
Post Reply