Have a look at pyramid's UnitConverter it's a good start but he did pick an ambiguous name.It uses tinkler for the GUI a switch to Qt or wxwidgets might be a better though.safemode wrote:I think the only way this csv issue is going to be resolved properly is by creating a python tool that can translate to and from csv. give the modder a decent interface, not some stupid spreadsheet. Then we can optimize the file layout without worrying about affecting modders.
Meh, in-house tools are buggy, poorly maintained and lack important features. Just look at UnitConverter.klauss wrote: In any case, sure, if we had such a tool, it would be far preferable.
Well I can see how it would make it easier to add a new column. But that's about the only widespread change you ever actually make in practice. Most changes have to be more precise than that, being made on a per unit.The rationale for csv was that, when balancing, one has to have the stats of all units at hand, to be able to compare, and to effect widespread changes easily. And I think that makes sense.
By what release could this change be accomplished do you think?The problem right now isn't having the stats in the CSV, it's the fact that the CSV has to contain all the other stuff about units that CSV isn't suitable for, like cargo imports, mount and exhaust, all that stuff that really shouldn't be part of a CSV.
LOL - you made me laugh. No... not the same thing. Nope. Not...Deus Siddis wrote:But as far as comparisons go, if having everything in one file makes them easier, why not apply that same strategy to c++ source files? Everyone knows you want to have all your code in one giant .c++ so that you can easily compare the class that starts on line 25331 with the one on line 307593.
0.5.2 optimistically, 0.5.3 more like it. It's not a big or difficult change, IMHO. The most difficult thing is figuring out where to put stuff, and of course translating current data to those new formats and locations. But the coding itself I don't expect to be very difficult.Deus Siddis wrote:By what release could this change be accomplished do you think?The problem right now isn't having the stats in the CSV, it's the fact that the CSV has to contain all the other stuff about units that CSV isn't suitable for, like cargo imports, mount and exhaust, all that stuff that really shouldn't be part of a CSV.
I'm aware of that. I intend to do the required merging, because what I'm fixing I don't think has been addressed on the py3 branch (I've been following the commits, sorta), and it's only some CMakeLists.txt stuff that ought to be easily mergeable.safemode wrote:Don't push fixes to trunk that deal with py3 branch. When it gets merged all these pushes to trunk will only complicate the merge. Py3 branch has ALOT to merge into trunk. Instead push to py3 branch.
It's not hard. The tools should not be part of the main package though. Mod tools should be a separate download. I still hope to finish my tools... just need to go back and get my auto-update feature to work (for win at least) and get it to show when a new software update is available.klauss wrote:Thing with Qt is that I'm not sure how hard it is to have windows installers that include Qt.
Just saying, can't put my finger on it before I do a proper review, but some of them seem like wrong. Only some.safemode wrote:More warning cleanups coming tonight. I hope to get through and finish all of them tonight.
Well, the last one about the redundant GFX update, that was required to properly update the camera unit's position. Otherwise, it was updated mid-render, and the background lagged a frame behind. Make sure you didn't regress that with that last commit.safemode wrote:some of them aren't warning fixes. A couple of them have to do with attempting to reduce unecessary cpu load.
No, it's bitwise xor.safemode wrote: first
int index = ix^(iz^1)+(iz<<1);
anything to ^1 is what you are raising.
Because the second happens after modifying lx (so it might return something different). In fact, the second one I think is dead code. Not sure though.safemode wrote: How is that if(lx < 0) lz=0; line not better combined with the first lx<0 conditional?
Narrowing are yours (they're trivially fixed with an explicit float cast, not that there's any other option anyway). I've been looking into the ffmpeg thing already, and I'll take care of those when time permits.safemode wrote:ok, warning fixes are done. All that's left is deprecated ffmpeg functions (so many) and double -> float narrowing. Both are serious and should be dealt with before we begin implementing new or changing current features in the game.
Narrowing are yours (they're trivially fixed with an explicit float cast, not that there's any other option anyway). I've been looking into the ffmpeg thing already, and I'll take care of those when time permits.
The ones I saw are initializers for coordinate arrays used in GFXDraw calls. For those, narrowing will happen regardless (on the hardware). So...safemode wrote:Narrowing are yours (they're trivially fixed with an explicit float cast, not that there's any other option anyway). I've been looking into the ffmpeg thing already, and I'll take care of those when time permits.
The problem with casting is it's just hiding the warning, not actually doing anything about fixing it. Some times that's ok. Other times it's not.
To be expected as you are using software rendering till you get that new GPU not that much of a hit with proper hardware rendering though it does not look all that good.and it should be default off until it's practical. As of now, it makes the game completely un-playable when rendered to screen.
I saw the patches. It's not so nice to add extern blah game_options to every cpp that uses it, include the extern in options.h.safemode wrote:Ok, so i'm cleaning up the optional variables... and finally consolidating _ALL_ of them into the vs_options class ...since that work was started and never completed years ago.
Um... an opcode collider itself isn't that expensive, but sure, it should be improved. Don't worry. I'm already reworking much of that code.safemode wrote:Came across the sparkles code in halo. Each particle initializes a opcode collider? There has to be a better way to signify damage.
Yes... got tons of ideas regarding this, though I'm sure my ideas would require hefty hardware (because of all the texture units it would require, far higher than average).safemode wrote:seems like a damage shader that can be executed on units with hull damage that modifies the textures similar to how we have planetary shaders that work on them would be far more functional.
I'm on it.safemode wrote:Either way, this particle system needs serious overhauling. and it should be default off until it's practical. As of now, it makes the game completely un-playable when rendered to screen.