That is unfortunate. I've bought my first 64 bit CPU in 2007, 10 years ago and when I built 64 bit version of my C++ code base I had ZERO bugs because I either use fixed width types like std::uint64_t or never assume sizes of variables.

Well... I imagine if you're only doing 64 bit builds, you're not gonna have any bug reports from 32 bit users, since they can't use it.

OpenPandora for example runs Hedgewars, but is a 32 bit Arm chip.

32 bits is not uncommon still in the mobile world, and I don't think ASM.js would have worked if we'd forced 64 bit...
And, well, Hedgewars has always been fairly undemanding spec-wise, so it's nice to still have it as an option for people who can't afford the latest hotness.

But, eh, I'm sure the fundamental reason for all these decisions was just the age of the codebase. Not that I'd advocate 64 bit only at this point still. 32 bit is fairly safe and cheap to support, even if engine was rewritten in rust, would still want to support as many architectures as possible.

Well the only problem will be when you need to work with a big chunk of memory, otherwise using 64 bit for indexes and sizes are fine. I still have a Pentium 4 PC which compiled my code just fine. Also, I'm getting an ARM based PC which is also 32 bit. (x86 is dead with its hardware backdoors (Intel ME and AMD PSP)).

If your app works 'sactly same in 32 bit , then 64bit is just a needless extra cost.. Best be clear as to what you need I think. But anyway, yes shortstring is veryvery short. You could change it if you want tho. Just would need changing a bit the network unit.

I only wrote Pascal in school so it would be a bit hard to fix this. Maybe some time in the future.

I had Pascal for just few months in high school, and yet, I was able to do all the things you can see in my contribution topic. Pascal is object-oriented language, and if you know at least one object-oriented language, you know all of them. It just takes a little Googling to find how to do what you want, but if you are skilled programmer, it's perfectly doable.

If it helps any, Hedgewars is *NOT* OOP.
It's basically C with pretty syntax, operator overloading and unit scope.
So accounting for a bit of difference in things like begin/end vs { } or "and" vs "&&" or ^. instead of -> you probably should manage fine.
This made unc0rr's pas2c much less painful I imagine ☺

But maybe stop by and run any major protocol changes past him first.

I think having a nice "lua config" tab in UI would be much better. That would be more frontend C++

It is mostly a question of time. I have tons of personal projects which require years to complete. This makes it hard to allocate time for something else.

How do I shoot a bazooka shell, that has the same speed and relative angle to an existing shell? SetGearValues doesn't work, apparently.

All you need for same angle/relative velocity is dX/dY
SetGearValues is kind of a grab bag of various gear values that weren't in the existing methods.

CopyPV will copy position (X,Y) and velocity (dX/dY)
GetGearVelocity/SetGearVelocity get/set only dX/dY

LuaAPI documents both

GetGearVelocity was what I needed. Thanks.

EDIT:
This one is interesting.
I want to triple the fire time. I assume I need to get some time value when gtFlame is created and then change it to 3x. Is it even possible?

Also, what about my question from post #35? >_>

EDIT2:
Apparently, dx/dy is can also be used to calculate angle of gtSineGunShot. Is it the proper way to do it? I assume it uses the direction of the vector, but does its length affect anything?

Fire does a bunch of stuff, but setting the Tag value 3x larger should probably do what you want.

As for knowing when an attack was totally complete, no, you're just going to have to keep track of weapon yourself in onHogAttack.

At present there's no hook in onUsedAmmo or AfterAttack.

It didn't. It made less burns and then hanged the turn infinitely.

That's... too much work.

Shouldn't be hard to make. Maybe.

'k. lemme look at the fire I guess. this is the sticky flames right. maybe misremembering.

Nope... That's exactly how ClimbHome does it.
https://hg.hedgewars.org/hedgewars/file/44b06731278b/share/hedgewars/Data/Maps/ClimbHome/map.lua#l192

But... it freezes the game. I mean, the turn never ends after using Napalm Strike.

Also, is there a way to see where the game crashed?
For some reason, my script makes engine die with code 217. Last thing the log shows is deleting a gear. I'm not sure what happens next and why it dies ;_;

I did ask you what flame type ☺
I assumed you meant sticky since napalm strike flames last, well, until they burn something.
Will have to see what values napalm strike uses, but it might not be possible to make them "last" longer since they probably delete themselves after the first terrain erasure.
So to make napalm strike last 3x longer you probably either have to spawn 3x more flames or else respawn a flame 3x after it dies in DeleteGear - spawning 3x more at start is probably easier. Might cause more spread in mid-air.

huh, I was actually right.

I still don't know what to do about the crash ;_;