About the veterancy system

1

I designed the current system, and gotta say I like the sound of option 2. Wish I'd thought of that. It's not quite the same, as it means the distribution of damage from units which regen or get repaired shifts, but tbh that is so ridiculously uncommon I was wrong to take it into account. The cost of the table lookups probably isn't worth it.

xp = (damageDealt / MaxHP) * massCost should do the trick. Probably doable in about 20 minutes by anyone familiar with unit.lua.

0

So people would get vet just from popping shots on the enemy commander? Two ACUs trade shots for a while and they both vet?

0

You could tune down the mass cost of the commander to make that effect negligible

0

@icedreamer said in About the veterancy system:

I designed the current system, and gotta say I like the sound of option 2. Wish I'd thought of that. It's not quite the same, as it means the distribution of damage from units which regen or get repaired shifts, but tbh that is so ridiculously uncommon I was wrong to take it into account. The cost of the table lookups probably isn't worth it.

xp = (damageDealt / MaxHP) * massCost should do the trick. Probably doable in about 20 minutes by anyone familiar with unit.lua.

I'm still running investigations into those table allocations. As indeed, the scenario you describe is rare and it introduces a lot of allocates in some situations.

For now it is important to first finish up the profiler in a reasonable state, then we can start looking at what really makes the sim tick 🙂

0

@jip Oh, that's easy - The vast lion's share of the compute time is taken up by function calls across the C++/lua boundary. It's about two orders of magnitude slower than anything else. Potential areas for improvement would be to look for areas where the lua makes repeated, unneccessary calls to engine. I worked with a couple of guys to eliminate all the points in the exe which make stupid calls the other way, so that's already done.

Other than that, you can try using more local variables in hot code - Intel, collision detection, economy events.

0

@icedreamer said in About the veterancy system:

@jip Oh, that's easy - The vast lion's share of the compute time is taken up by function calls across the C++/lua boundary. It's about two orders of magnitude slower than anything else. Potential areas for improvement would be to look for areas where the lua makes repeated, unneccessary calls to engine. I worked with a couple of guys to eliminate all the points in the exe which make stupid calls the other way, so that's already done.

Other than that, you can try using more local variables in hot code - Intel, collision detection, economy events.

Yes - I've been looking into using locals. LOUD applies a similar pattern to optimize functions or to push them as an 'upvalue' which is still better than a global. A wikipedia entry that I've learned from quite a bit: https://springrts.com/wiki/Lua_Performance

Do you happen to know about how the garbage collector works in Lua? I've been trying to find informative examples, but came out short.

0

Oh - and while I have you - how did you found out about the boundary passing being expensive?

0

I profiled the game while it was running and produced a statistical output of how much time was spend in each function, both in engine, in lua, and the time at which the function call was registered.

0

Do you still have that profiler?

0

option 2