Dev meeting minutes 2012-08-13

Dev meeting minutes 2012-08-13

Minutes of the meetings between Spring developers are archived here.
Post Reply
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Dev meeting minutes 2012-08-13

Post by jK » 20 Aug 2012, 16:36

Date: 2012-08-13
Present: abma, jK, Tobi, zerver



_Agenda_____________________________________________________________________
  • FYI single threaded spring is 1.1% faster than MT with 1 thread (1.1% higher FPS, 1.1% faster Sim).
  • can INTERNAL_ORDER be removed?
  • 90.0?


_Main Conclusions___________________________________________________________
  • target lock should be customizable somehow either modkey or config




_The meeting________________________________________________________________
>> zerver joined!
>> jK joined!
>> abma joined!
abma: heyhey!

FYI single threaded spring is 1.1% faster than MT with 1 thread (1.1% higher FPS, 1.1% faster Sim).
abma: zerver?!
jK: we need a objective benchmark buildbot
abma: + we need a benchmark?
jK: I got some work on that
abma: imo its hard to get always the same result. some simple background task (auto-updates, some disk sync, lock rotation, cron jobs, ...) could lead to completely different results...
abma: but.... better as no benchmark, yep
abma: next?

can INTERNAL_ORDER be removed?
abma: https://github.com/spring/spring/blob/d ... mand.h#L94
abma: someone responded "maybe remove DONT_REPEAT instead"
abma: uhm... ideas/hints?
jK: http://home.arcor.de/jkei/bench_results.zip
jK: with non-deterministic script.txt
abma: aah, nice
abma: at least thats some start point
jK: with deterministic replay it converges very good
jK: the given benchmark was non-deterministic cause I wanted to check the LuaJit performance
jK: and LuaJit isn't syncing w/o additional work
jK: @INTERNAL_ORDER, imo both make sense, I more wonder why they translate to the same bit o_O
>> Tobi joined!
jK: e.g. it's all commands spawned from area commands (& patrol) should be internal (even when kloot is breaking that atm afaik)
jK: -it's
jK: so lua and engine can identify 2nd class commands (automatic ones) and 1st class ones (given by user)
jK: offtopic again can someone update buildmaster?
abma: i'lll do that...sure
jK: if everything goes right I am near zero library dependencies
jK: even when I am unsure if getting rid of libm, libc & libpthread make sense >_<
jK: but it might be possibly some distros don't got .6 ones
jK: *le
abma: [LCC]jK: updated
abma: that means we need an upload script? :D
jK: yup
jK: binary itself is <20MB
jK: debugsymbols will make again 200MB uncompressed (duno yet how well it compresses)
zerver: hi, sry I was afk
jK: wonder if it is even faster (static libs `can be` faster than shared ones)
jK: perhaps just with LTO
jK: didn't tried 4.6.3 LTO yet
abma: [LCC]jK: do you have enough bandwith for uploading?
jK: yup
zerver: If 1.1% performance diff for MT/ST is acceptable we could merge them as suggested.
jK: MT still got a lot special code
zerver: Also, I used CPU affinity during the MT vs ST benchmark. The performance boost with affinity set is so huge that I am wondering if we should make it default.
jK: I fixed the problem without affinity on linux
zerver: I tried to disable the "special" codes when only 1 thread is active.
jK: windows can be fixed w/o affinity too
jK: oh
jK: nice
zerver: If you are referring to healthbars and such...
jK: healthbars, command processing, model loading, ...
zerver: Yeah, all that is fixed
jK: nice to hear
zerver: Plz try it, and we can vote about what to do later
jK: still want a benchmark before :/
jK: @affinity: http://msdn.microsoft.com/en-us/library/ms684247.aspx
zerver: I have my benchmark in detail, but if you want to make your own, sure
jK: that's the way to go
jK: problem is it needs mingw64
jK: in particular http://msdn.microsoft.com/en-us/library ... s.85).aspx
zerver: Yeah, saw your comments about it in the spring sources

90.0?
zerver: so what about release?
jK: ppl seem to unhappy with auto force target
zerver: so we ask kloot to revert it / make it optional?
jK: revert is impossible already
zerver: yeah, it was the root cause of the majority of all bugs in 89.0 :P
zerver: huge number of fixes, hard to revert
jK: so yes, needs a way to be optional (either by pressing a modkey or my setting)
jK: -my +by
zerver: I agree. I somewhat like the feature for artillery and such, but I also feel it may be very confusing for noobs
abma: have to sleep, gn8! :)
<< abma left!
0 x

Google_Frog
Moderator
Posts: 2434
Joined: 12 Oct 2007, 09:24

Re: Dev meeting minutes 2012-08-13

Post by Google_Frog » 22 Aug 2012, 10:34

zerver: I agree. I somewhat like the feature for artillery and such, but I also feel it may be very confusing for noobs
Apparently I have to repeat myself.Spring is an engine so why does it implement this feature which is:
  • Forced.
  • Unwanted by a fair proportion of people.
  • Easy to implement in lua.
  • Unconfigurable if engine side but extremely configurable if done in lua.
Moving it to settings is fine but a modkey doesn't work. Meta is already used by the command insert widget which as far as I can tell is commonly used.

But that was most devil's advocate, I was mostly annoyed at zerver's comment because whether it is a good feature for some units in some games is irrelevant. I the latest post_release tested (89.0.1-90-g2a49c60) the engine side set target is innocuous enough. As far as I can tell it cleanly overlaps with my implementation such that ZK users with the default UI will not notice any difference. So I would like 90.0.
0 x

User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes 2012-08-13

Post by smoth » 22 Aug 2012, 16:47

I know this may have been asked but why was the lock code added
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Dev meeting minutes 2012-08-13

Post by jK » 22 Aug 2012, 21:43

Command insert is rarely used with attack cmds, don't see a problem with it. (if at all the widget might break the engine side and not the other way around)

I like the target lock feature in the way it is now implemented in 90.0
Good work kloot :)

@smoth, it was a longterm requested feature. And GF even implemented something similar in lua for ZK. Still the way it is implemented in upcoming 90.0 it shouldn't conflict anymore.
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2012-08-13

Post by zerver » 23 Aug 2012, 13:11

What I dislike with the fixed target lock is that it still fires at other targets while moving forward to get the target in weapon range. This means that pressing META + attack is not enough to snipe an enemy comm, you still need to set hold fire to avoid the snipers wasting ammo on other units.

At the same time I realize that a very strict locking, that does not unlock automatically unless the target dies, is prone to fail unless the user remembers to unlock it.
0 x

Google_Frog
Moderator
Posts: 2434
Joined: 12 Oct 2007, 09:24

Re: Dev meeting minutes 2012-08-13

Post by Google_Frog » 23 Aug 2012, 17:44

I implemented something similar in ZK so to me that means it doesn't need to be in the engine. Also this engine side implementation is worse and forced.
What I dislike with the fixed target lock is that it still fires at other targets while moving forward to get the target in weapon range. This means that pressing META + attack is not enough to snipe an enemy comm, you still need to set hold fire to avoid the snipers wasting ammo on other units.
People should have to set their unit to hold fire if they want to exclusively fire at the locked unit. This is how attack commands already work.

To workaround the issue of forgetting that you have something locked you could draw some sort of command line from the unit to the target. I would suggest this if I wanted this feature but my gadget target lock already had this attack line at it's implementation. It also makes the system more visible to users.
0 x

User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes 2012-08-13

Post by smoth » 24 Aug 2012, 02:19

I really wish the targeting was stripped from the engine and gadgetized
0 x

User avatar
Jools
XTA Developer
Posts: 2804
Joined: 23 Feb 2009, 16:29

Re: Dev meeting minutes 2012-08-13

Post by Jools » 24 Aug 2012, 08:09

Google_Frog wrote:People should have to set their unit to hold fire if they want to exclusively fire at the locked unit. This is how attack commands already work.
Wait a minute ... if unit is set to hold fire it should hold fire. Not fire at all.
0 x

gajop
Moderator
Posts: 3021
Joined: 05 Aug 2009, 20:42

Re: Dev meeting minutes 2012-08-13

Post by gajop » 24 Aug 2012, 09:31

Jools wrote: Wait a minute ... if unit is set to hold fire it should hold fire. Not fire at all.
Nah.. hold fire really means it will wait for an explicit attack order.
0 x

User avatar
Silentwings
Moderator
Posts: 3577
Joined: 25 Oct 2008, 00:23

Re: Dev meeting minutes 2012-08-13

Post by Silentwings » 24 Aug 2012, 10:46

+1 to removing the target lock (which I personally like) from the engine and using a gadget for it.

Although if the target lock only affects targets which fixed to the ground rather than fixed to a unit, I think it won't affect gameplay much anyway.

Btw, any clues as to when 0.90 comes out? ;)
0 x

User avatar
Jools
XTA Developer
Posts: 2804
Joined: 23 Feb 2009, 16:29

Re: Dev meeting minutes 2012-08-13

Post by Jools » 24 Aug 2012, 13:18

gajop wrote:
Jools wrote: Wait a minute ... if unit is set to hold fire it should hold fire. Not fire at all.
Nah.. hold fire really means it will wait for an explicit attack order.
That explicit attack order should override the hold fire order and put it on return fire or something.
0 x

User avatar
Johannes
Posts: 1265
Joined: 17 Sep 2010, 15:49

Re: Dev meeting minutes 2012-08-13

Post by Johannes » 24 Aug 2012, 13:52

Silentwings wrote:Although if the target lock only affects targets which fixed to the ground rather than fixed to a unit, I think it won't affect gameplay much anyway.
I know I've said it here several times before but...
It's always been possible (unless it was somehow removed really recently?) to lock on a spot of ground, by after the attack command making a move command somewhere holding shift.

Which is much better than always locking, since it gives you more flexibility (to lock or not to lock, without pressing Stop somewhere along the way), and has the usually wanted behaviour (not locking) as the default.


Since always we've had the option to focus on a target or not to focus, by a single key press to put units on Hold Fire. Now you cannot ever use attack commands if you want to not do that - which is often what you want.

Jools wrote:
gajop wrote:
Jools wrote: Wait a minute ... if unit is set to hold fire it should hold fire. Not fire at all.
Nah.. hold fire really means it will wait for an explicit attack order.
That explicit attack order should override the hold fire order and put it on return fire or something.
No, why should making single orders change the units allocated DEFAULT behaviour? Are you serious...
0 x

Post Reply

Return to “Meeting Minutes”