View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005809 | Spring engine | General | public | 2017-10-16 15:32 | 2017-10-17 20:07 |
| Reporter | Doo | Assigned To | hokomoko | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 104.0 | ||||
| Summary | 0005809: Engine wont load more than 32 weapons for a unit in version 104 | ||||
| Description | I am working on an evolving commander which will have access to different weapons as it progresses and gains xp. For that purpose, i'm splitting all the weapons into 11 levels each + the dgun that will remain the same. That's a total of 34 weapons. I defined all that in a way that was convenient for me to edit later, and when loading, although there was absolutely no error, it seemed only 32 weapons were loaded. I added a copy of the armcom.lua defs i tried. To avoid any weirdness in the defs i used, i did try with: for i = 1, 55 do tablearmcom.weapons[i] ={ def = "DISINTEGRATOR", onlytargetcategory = "NOTSUB", } end At the end of the defs file, before returning the table, where tablearmcom is the unitdef table and {armcom = tablearmcom} will be returned. The same issue happened and the echoes only returned 32 weapons. | ||||
| Steps To Reproduce | Set more than 32 weapons for a single unit and echo all the weapons of that unit ingame. It will stop at the 32th | ||||
| Additional Information | Tested on latest ba:test and spring 104 | ||||
| Tags | 104.0 | ||||
| Attached Files | |||||
| Checked infolog.txt for Errors | |||||
|
|
https://github.com/spring/spring/blob/develop/rts/Sim/Misc/GlobalConstants.h#L111 |
|
|
This is more a feature request than a bug report. I don't know the reason for the limitation but I can give some advice for working around it. Here are three methods: * Weapon modification. * Unit replacement * Projectile replacement. The properties of weapons can be modified on the fly on a per-unit basis. This may be used to reduce the number of duplicate weaponDefs required to implement an upgrade system. I am certain that reload time, damage, burst rate and range can be modified with this method (range changes can require some fiddling to make unit AI notice). The wiki claims that many other properties can be changed as well and it is probably telling the truth. Unit replacement destroys the old unit and creates an upgraded one whenever an upgrade occurs. This can be done by many of the morph gadgets found in various games. The projectile replacement method has the commander fire a generic projectile (for each physics type) which is then replaced with the projectile appropriate to the upgrade system. I have not attempted projectile replacement but I think all the lua exists to make it work, except in the case of beams. |
|
|
in general we wouldn't want to increase the limit when in every single moment you don't actually have >32 active weapons. As GF said, many properties can be changed. And things that are currently impossible to change on the fly may be made possible if there's a need. |
|
|
* Weapon modification: I'm indeed using that in the unit script thanks to LUS. Previously setting all weapons were more convenient and also allowed access to more properties in case they were needed (such as projectile model changes, color changes and other stuff that actually arent made possible ingame with LUA. * Unit replacement: On a previous version, this is what i used, but it caused the new unit to: 1) Not keep the previous queue 2) Lose track of their stats (experience, hp, maxhp, even though i did go around that with some more lua works) and groups 3) Unselect in a momentum (because it was likely that the commander would level up in the middle of a fight, rather then when idling somewhere on the map) 4) * Projectile replacement: I have only been using that once, and while it is lovely to be able to create lots of different weapons behaviours, especially for missiles, it didnt occur to me to use it in that case because of the performance cost probably being alot higher than the other 2 solutions. Also, the reason of this report is because i have been explained, and shown through the source data that the number of weapons was unlimited, and that it should have worked. I actually find a way around that issue for myself, but still reported in case it was indeed the case. |
|
|
Edit: 4) Because it doesnt spawn the new unit in the same position/situation than the previous one (ie: in its default position when it was actually walking, or with a different value of some variable in the script) Looks like I had dropped that one while typing. Thanks for your concern! |
|
|
"i have been explained, and shown through the source data" who explained this to you, and what source data were you shown? unless the information about a piece of source code comes from an engine developer, do not rely on it. |
|
|
https://github.com/spring/spring/blob/41f8be868ee4941cc2bb9c3711e38b8117704986/rts/Sim/Weapons/WeaponLoader.cpp#L42 Was in #moddev yesterday, don't remember for sure who was it that explained me it should have, but I think it was picasso? I'm not confident that I do understand the full content of that part of code, but it did seem to me that as long as there was a weapon that could be loaded in the next step, it would load it. (which is consistant with the fact that if I set no 2nd weapon, weapon 3 won't be loaded). |
|
|
"picasso" never *EVER* believe anything said by picasso. that WeaponLoader code turns weapon definitions (unitDef->weapons, parsed in UnitDef::ParseWeaponsTable) into weapon instances. the number of *definitions* is never more than MAX_WEAPONS_PER_UNIT. |
|
|
In this case there is no reason for this bug report to exist. I guess it can be closed/resolved. :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-10-16 15:32 | Doo | New Issue | |
| 2017-10-16 15:32 | Doo | File Added: armcom.lua | |
| 2017-10-16 15:32 | Doo | Tag Attached: 104.0 | |
| 2017-10-16 15:44 | Kloot | Note Added: 0018518 | |
| 2017-10-17 10:53 | Google_Frog | Note Added: 0018522 | |
| 2017-10-17 14:13 | hokomoko | Note Added: 0018523 | |
| 2017-10-17 19:30 | Doo | Note Added: 0018525 | |
| 2017-10-17 19:34 | Doo | Note Added: 0018526 | |
| 2017-10-17 19:44 | Kloot | Note Added: 0018528 | |
| 2017-10-17 19:47 | Kloot | Note Edited: 0018528 | |
| 2017-10-17 19:49 | Doo | Note Added: 0018529 | |
| 2017-10-17 20:00 | Kloot | Note Added: 0018530 | |
| 2017-10-17 20:03 | Doo | Note Added: 0018531 | |
| 2017-10-17 20:07 | hokomoko | Assigned To | => hokomoko |
| 2017-10-17 20:07 | hokomoko | Status | new => closed |
| 2017-10-17 20:07 | hokomoko | Resolution | open => no change required |
