Hay, I have and have been updated and am now re-updating and extending the scripts of excel spreadsheets of all the ship, subsystem, and weapons. Allowing very easy editing of bulk lua files and of tweaking in a very easy way (having all of the ships in columns on a xls sheet is priceless when balancing, exporting and testing)
This was from an original dev back in the day and still works well with modifications.
Now the question, does it make sense for me to keep working on it? or do you have or working on something better similar that would superseded it?
Just do not want to waist time if you are already going there.
Thanks!
Though I will say that simple spreadsheets arenāt ideal anymore from one aspect: some Ship files have switches by rubric (sp, mp, skirmish) for certain valuesā¦ Which makes automated updates very difficult.
From what I have seen I do not think it will be a big problem for what I am doing, the exporter can be changed to handle all of the current changes, and I am building a importer just for the hell of allot of data entry time if I want to get the current ship stats in there.
Also I tend to use this for all of the ships to be use in a MOD some may be original ships with modified stats, families, weapons etc but I expect most to be new ships. The exporter handles a full dump of all data or just one column (all the files or just one at a time)
And in all likely hood I would be making mods for only MP, and skirmish and there stats should be the same. so again in all likely hood I will no need to even go there -but if so the change is not impossible, unless I am missing something?
So I think I have that handled.
I am asking should I in the light of new tools or not? it is seeming from your response that a app to edit the ship, subsystem, and weapons etc is not? part of the modding tools coming out?
Hmm my mention of c access was due the assumption that the current LUA functions made available were pretty much all the options we had -forgive my ignorance.
With this info in mind I believe the following suggestions relate to many mod devs wants (That I have spoken to whilst working on complex).
.Ability to create a load level command from within another level during multi-player/Vs CPU, whilst transferring/importing player data - ship locations, RUās , ship counts etc. - the possibilities for this one are pretty obvious.
.Regarding UI / main menu: during discussion the idea of being able to add cutscenes to existing playback menu. Unfortunately the ones unlocked by default relate to the player profile files.
Would it be possible to include a LUA command that can add more video unlocked to the player config on map load or button cmd command -we did consider the possibility of including a custom profile data with our downloads although most get confused over these issues.
.Lastly, one that thus far has only really applied to the complex series (due to the amount of options):
The ability to add different build/research files dynamically - the idea being you add something like addAbility(NewShipType, āCanBuildShips_OptionlIst2ā, (enable: 0). That is then activated much like research unlocks from the main menuās. I admit this may be challenging to implement, although there are many obvious uses.
Our other issues I believe will be resolved with lessor CPU load via the new graphics solutions ,only time will tell
Thanks for your info and consideration.
It works and works well, also saving me from writing a UI to do effectively the same thing. (was going to do all of this in python).
Having all of the settings and stats for all of the most modded 100s of ship, weapon, missile and subsystem files easily viewable in 4 tabs, and dumpable into there game useable form with a press of a button really is helpful. (again the dev that made this originally thought so also)
It is not very elegant. The screen switches to the desktop when you start the game because you are accessing the file system using DOS. The custom save routines and normal HW2 save system are incompatible with each other. I think subsystems can not be saved between missions. Maybe there are other problems.
Yeah I played around with external shiz also, and notice others tried some solutions similar to your own. Issue is ofc; yet again from the player perspective, itās a hassel.
Damn. Some folks here are lucky they didnāt have to get results out of the original Homeworld 1. The hardcoded quirks of each ship slot, the inconsistencies of the SHP format, the many ways that the ETG scripts had almost enough but not quite the features needed to do what we needed would make LUA look like a cushy vacation!
ā¦Cups? Weād have been thrilled to have cups! We had to suck our tea out of a damp cloth, if we were lucky!
Though I will say that simple spreadsheets arenāt ideal anymore from
one aspect: some Ship files have switches by rubric (sp, mp, skirmish)
for certain valuesā¦ Which makes automated updates very difficult.
Actually thatās all the more case for automated updates, but you have to be smart about it. Thatās how I balanced Sacrifice of Angels: Perl and Python scripts ran off from a central table of coefficients, and I kept templates for each ship and each important ship subsystem to make sure all the ships had the right balance of canon, tactical distinctiveness, and fun. Your rubric switch would have been another coefficient to plug into the template system - and Iāve always found that if youāre going to do more than a half-dozen ships, itās best to just write the templates.
Is it in the least plausible to run a current lua interpreter in parallel with the old one? That is, have an old-lua method call new-lua function? It would probably take a lot of cycle-stealing wrappers both directions to call from one to the other, but seems hypothetically possible to this ancient C-speaking dinosaur. If an old-lua call could call a compute intensive new-lua method that got JIT optimized, it might more than pay for the overhead.
The syntax and formatting of most of the LUA this game uses doesnāt fly with newer LUA libraries - weāre a decade out of date. We came at this from a few directions, and it just wasnāt (and still isnāt) feasibleā¦ We really only gain if we gut things and use the newer LUA libs - which is just not an option at this point.
As a semi-observant non-user, I nevertheless have unfounded opinions. Functionally, one might arguably take the existence of luaJIT for performance first; support for current library/modules next. The live development community (documentation, other ecosystem) later. Iāll throw in thread/concurrency support to use additional cores as library/modules. Iām not so sure that the 5.x co-routines are worth much by themselves for using cores. Closures are nice, but not crucial IMO.
I have to use mostly Java/JVM based things, and thereās no way Iād use a Java 1.3 from 2000 for anything anymore. Thatās the Lua 4.0 vintage.
