Building Bind Issue

[Nux]

For a while now I've been using something like the following for selecting buildings.

Code: [Select]

set ab1 "echo ^5Egg;build overmind;build eggpod"
set ab2 "echo ^5Overmind;build overmind"
set ab3 "echo ^5Acid Tube;build overmind;build eggpod;build acid_tube"
set ab4 "echo ^5Trapper;build overmind;build eggpod;build trapper"
set ab5 "echo ^5Booster;build overmind;build eggpod;build booster"
set ab6 "echo ^5Hive;build hive;build overmind;build eggpod"
set ab7 "echo ^5Hovel;build hovel;build overmind;build eggpod"
set ab8 "echo ^5Barricade;build overmind;build eggpod;build barricade"

set hb1 "echo ^5Telenode;build repeater;build reactor;build telenode"
set hb2 "echo ^5Reactor;build reactor;vstr altn"
set hb3 "echo ^5Turret;build repeater;build reactor;build mgturret"
set hb4 "echo ^5Medistation;build repeater;build reactor;build medistat"
set hb5 "echo ^5Armoury;build repeater;build reactor;build arm"
set hb6 "echo ^5Repeater;build repeater"
set hb7 "echo ^5Def-Comp;build repeater;build reactor;build dcc"
set hb8 "echo ^5Tesla;build repeater;build reactor;build tesla"
The idea is that for each building there is a specific key to select it (as usual) but whenever that building can't be built there (i.e. no power) the necessary building required to allow you to build it there is brought up instead.

Say for example I wanted to build an armoury but I had no reactor. I would press the key for armoury and the reactor would pop up in front of me. This would both alert me to the reactor being down and give me the plans to lay a new one simultaneously. Or perhaps I'm a granger and I want to build a trapper but I'm far from the OM and eggs. Pressing the key for trapper would give me the egg I'd need to build in that area first.

This has been working great so far, but I've had trouble with certain QVMs (particularly MG dev) which seem to have changed how the game handles consecutive selection of unbuildables. Have they made any building selection cancel the previous despite the unbuildability of the latter selection? I'd like to know how this has changed, how it will end up in later versions and whether I'd be able to have a similar system in those version.

[jackForward]

well, this is way beyond my skills, so i can't really help you here, nux.
Only thing i noticed on the MG server was that my sprint binding didn't work there ('unknown command boost' or such).

Code: [Select]

bind UPARROW "+forward; boost"
bind DOWNARROW "+back; boost"
bind LEFTARROW "+moveleft; boost"
bind RIGHTARROW "+moveright; boost"
bind SHIFT "+speed"
 

[Annihilation]

well, this is way beyond my skills, so i can't really help you here, nux.
Only thing i noticed on the MG server was that my sprint binding didn't work there ('unknown command boost' or such).

Code: [Select]

bind UPARROW "+forward; boost"
bind DOWNARROW "+back; boost"
bind LEFTARROW "+moveleft; boost"
bind RIGHTARROW "+moveright; boost"
bind SHIFT "+speed"
 

On Development server it is +button6 instead of +boost.

[kevlarman]

1) the tremulous forums are not the place to discuss bugs
2) the tremulous forums are DEFINITELY not the place to discuss mgdev bugs
3) http://svn.mercenariesguild.net/mgdev?view=rev&rev=93
4) it's midnight, so i'm not even going to try to figure out why that change was made.

[Lakitu7]

3) http://svn.mercenariesguild.net/mgdev?view=rev&rev=93

http://source.mercenariesguild.net/mgdev?view=rev&rev=93
 

[Nux]

1) the tremulous forums are not the place to discuss bugs
2) the tremulous forums are DEFINITELY not the place to discuss mgdev bugs
3) http://svn.mercenariesguild.net/mgdev?view=rev&rev=93
4) it's midnight, so i'm not even going to try to figure out why that change was made.

1) This is not a bug with the game. This is a discrepancy between my config and specific versions of the game. Also, I posted this in case those without these binds might be interested in using them.
2) MGdev is an example. My question is more general than that if you care to reread.
3) Thanks for the link, but it's a little code-heavy for my liking. I'm no programmer.
4) It would be nice to know WHY they would change it. What I'm more interested in knowing is what effects such changes will have to my ability to reproduce the feature I've been using and whether such changes are planned for 1.2 (since MGdev is frequently given as an example of what should be expected to come).

For all these reasons I don't see the problem with posting this on these forums.

[Amanieu]

Well instead of waiting for someone to decon the reactor before you can select it, you can select it, and then it becomes green when someone decons the reactor.

[Nux]

Marked decon...

Well instead of waiting for someone to [mark] the reactor before you can select it, you can select it, and then it becomes green when someone [marks] the reactor.

I'll mention that I don't like marked decon (even including the traditional decon ability with it would be better) but it looks like it's becoming part of the game nonetheless.

So this requires more communication than before. A green plan no longer means that the reactor is down. This in itself isn't necessarily a bad thing but it will effect my binds.

So is the intended system one in which the building you select last is the one you end up with the plans for? In that case it looks like I won't be able to reproduce this handy feature in the newer versions. It would be nice if you would allow this to be optional through something like 'cg_buildpriority 1'. Or maybe you'll decide that this method makes things to easy for builders.

[benmachine]

First of all, this is an mgdev experimental change and whether or not it will be included in the official development line is uncertain. It is somewhat controversial as some people believe it to be more confusing for newbies, but is essentially in place to allow you to select a building before it can be built or where it can't be built and move or wait for it to become available. The issue you describe is not one that had occurred to me, but I'm not sure I will do anything about it, because I kind of prefer the current behaviour. A client-side setting is possible but there is such a thing as too much customisability, so one has to weigh the benefits of the added choice with the drawbacks of feature bloat, more potential for bugs, space used in the userinfo string, etc.
That said, you do raise an interesting point, and thanks for the feedback. I'll try to address it if I get the time

[Nux]

Ok, thanks benmachine.

I'd understand if this 'feature' were overridden in later versions. The fact that (in the old system) these binds had no downside is something akin to how I made my crouch bind combined with my slow-walk bind. There was no reason not to do it as it gave crouch-moving the benefit of stamina regen. Similarly these build binds only have benefit. It's that sort of 'work-around' feature which IMO should be impossible to bind or else be a part of the standard system.

So long as we're on the subject, can someone give me an idea why the marked decon system can't be additional to the traditional decon? If it's just because of deconners then I put it to you that that is no reason at all. (If this can't be answered quickly enough to warrant the off-topic nature then I'll duly make a new thread for it.

[Bissig]

Ok, thanks benmachine.

I'd understand if this 'feature' were overridden in later versions. The fact that (in the old system) these binds had no downside is something akin to how I made my crouch bind combined with my slow-walk bind. There was no reason not to do it as it gave crouch-moving the benefit of stamina regen. Similarly these build binds only have benefit. It's that sort of 'work-around' feature which IMO should be impossible to bind or else be a part of the standard system.

So long as we're on the subject, can someone give me an idea why the marked decon system can't be additional to the traditional decon? If it's just because of deconners then I put it to you that that is no reason at all. (If this can't be answered quickly enough to warrant the off-topic nature then I'll duly make a new thread for it.

p-q-qvm uses a combination of marked and non-marked decon:

You can decon as usual with the decon key but for the marked decon at least I use the console, look at the object in question and do /mark... which I should move into a bind possibly. ;-) I think this feature set is called "semi-marked decon".

What sucks about marked decon thus far is, that if you just want to move a building you can only do it outside the hitbox or outside the center of the building that you are going to replace (haven't figured out yet if it is the hitbox of the old building that interferes). So, for those perfectionists out there or if there is no other place to put the new building you can not do a "marked decon pixel perfect replacement move".

Also, if marked decon is the only option on the server getting those feeder nodes off the default base is becoming a pain in the ass.