For the new wait commands:
http://taspring.clan-sy.com/phpbb/viewt ... p?p=141887
0.74 testing
Moderator: Moderators
It appears to work right with all non-flying things, but does not work with flying things.
I reported that bug awhile ago, and then it got fixed, and now it's borked again. Sorry for not being absolutely clear- I was in the middle of the last major coding binge and was exhausted
Very minor bug, so long as you aren't heavily into unit limits and don't use a lot of flying things. Unfortunately, to make a low-limit NB variant for speedy/competition play, I need to limit Wolf production, or it's all kind've moot
I reported that bug awhile ago, and then it got fixed, and now it's borked again. Sorry for not being absolutely clear- I was in the middle of the last major coding binge and was exhausted
Very minor bug, so long as you aren't heavily into unit limits and don't use a lot of flying things. Unfortunately, to make a low-limit NB variant for speedy/competition play, I need to limit Wolf production, or it's all kind've moot
The mouse rocker gestures are always enabled,
when you are using the invqueuekey mode. You'd
probably never notice them unless their existance
was pointed out to you.
How they work:
In invQueueKey mode, you have to hold down the
SHIFT key while releasing the mouse button to issue
a command in immediate mode (non-queued). This
will flush all of the currently queued commands and
add the new command. If you want to do the same
thing without using the SHIFT key, do either of the
following:
Default Commands:
Press RIGHT button (do not release it)
Press LEFT button (do not release it)
Release RIGHT button (order is sent in immediate mode)
Release LEFT button (at your leisure)
Standard Commands (from a keypress, or GUI button click):
Press LEFT button (do not release it)
Press RIGHT button (do not release it)
Release LEFT button (order is sent in immediate mode)
Release RIGHT button (at your leisure)
It sounds a lot harder to use then it actually is. It becomes
quite natural fairly quickly. Then again, using the SHIFT key
isn't all that hard either
when you are using the invqueuekey mode. You'd
probably never notice them unless their existance
was pointed out to you.
How they work:
In invQueueKey mode, you have to hold down the
SHIFT key while releasing the mouse button to issue
a command in immediate mode (non-queued). This
will flush all of the currently queued commands and
add the new command. If you want to do the same
thing without using the SHIFT key, do either of the
following:
Default Commands:
Press RIGHT button (do not release it)
Press LEFT button (do not release it)
Release RIGHT button (order is sent in immediate mode)
Release LEFT button (at your leisure)
Standard Commands (from a keypress, or GUI button click):
Press LEFT button (do not release it)
Press RIGHT button (do not release it)
Release LEFT button (order is sent in immediate mode)
Release RIGHT button (at your leisure)
It sounds a lot harder to use then it actually is. It becomes
quite natural fairly quickly. Then again, using the SHIFT key
isn't all that hard either
oh so invquekey mode is just the equivilant of not having to hold shift all the time to queue up commands, and when you wanna issue a command without queuing you hold shift?
Sounds wierd tho I guess at times it can be useful.
Maybe it could be tied to the capslock button as long as there's a little message thats in the corner saying its turned on so noobs dont get confused.... And of course ti beign ignored if the user's typing a message...
Sounds wierd tho I guess at times it can be useful.
Maybe it could be tied to the capslock button as long as there's a little message thats in the corner saying its turned on so noobs dont get confused.... And of course ti beign ignored if the user's typing a message...
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
btw, may I point out that this might be a good time to stop including the OTA Copyrighted stuff with spring. The modders can include it with their mods if they still need it. That way, if atari etc gets pissed off then it is a deal with the mods, not with spring itself.
Including that stuff is only asking for trouble.
Including that stuff is only asking for trouble.
Great great great! Can't wait to playTobi wrote:It is this releasemalric wrote:I also assume this is not the version in which we can play lin vs win... Any news about that release ?
malric wrote:I know they would sync if they would be build with gcc.
Are the windows binaries build with a gcc higher than 4.0 ?
.No problem with compiling, but maybe there should be a notice somewhere, that with this release is possible to play win vs linux (otherwise without a linux package, it is not that obvious)Yes, I built them using MinGW w/ gcc 4.1.1 (latest stable GCC)
trepan: the release exes aren't from the automated builds, I've build them manually because I haven't succeeded to build a MinGW crosscompiler from a stable GCC release.
You'll still need to compile from source, unless someone makes binary packages for your distribution. (I myself am trying to motivate me just enough to build debian/ubuntu packagesWill there be a linux release or should linux guys compile from source ?
-
FoeOfTheBee
- Posts: 557
- Joined: 12 May 2005, 18:26
+1, why not go legal? Nanoblobz is fun, in a weird way. It would make a fine default mod.Forboding Angel wrote:btw, may I point out that this might be a good time to stop including the OTA Copyrighted stuff with spring. The modders can include it with their mods if they still need it. That way, if atari etc gets pissed off then it is a deal with the mods, not with spring itself.
Including that stuff is only asking for trouble.
Modders can take their own risks with the law. A separate download for TA based mods is a small price to pay for keeping the project safe from legal trouble.
New Bugs:
1. Invoking CSmokeProjectile, as opposed to [smoke], is very interesting. The smoke does not obey commands, and seems to be abnormally affected by wind-drift. Worse yet, the bitmaps are not getting offset properly, and are clipping.
2. One user has reported that the "black-line" bug is still occurring on some systems. I've brought this up before- the textures or their alpha channels don't seem to be getting properly clamped or aligned at different mip levels, which is resulting in this behavior.
3. I don't suppose HeatCloud could be made Alpha/Colormap-conformant? It'd be nice if there weren't any bitmaps in the AtlasedTexture that didn't have alpha values- this also applies to the WeaponProjectiles that are still using non-alpha-value bitmaps. Maybe I need to add a black border around mine, to get rid of the black-lines issues... Spring recognizes they have an alpha, it just refuses to read any values except for black and white...
4. Projectiles spawned by scripts are subject to a large number of limitations which currently make them impractical to actually use, except for lasers.
5. I would like to vote for CannonProjectile to just be a special instance of BeamWeapon, so that the textures are aligned with vector. It already has code to align models... why not do so with textures, and allow us to have non-circles for projectiles that are GravityAffected?
6. SeismicDetector doesn't seem to be working for me. It did for awhile, and now it doesn't. Has something changed in the code or support code? I've put FBI tags in like so:
... but it doesn't work. What else do I need to do here?
Still haven't encountered any crash bugs- this is all minor stuff, or stuff that will require a serious look-see. The whole AtlasedTexture thing really bugs me, though- if Trepan's icon-loading code could be used to do fast draw/swap of particle textures, it'd have the obvious advantage of being animated, plus it wouldn't be shoving a big DDS file around in front of a virtual camera frustum...
1. Invoking CSmokeProjectile, as opposed to [smoke], is very interesting. The smoke does not obey commands, and seems to be abnormally affected by wind-drift. Worse yet, the bitmaps are not getting offset properly, and are clipping.
2. One user has reported that the "black-line" bug is still occurring on some systems. I've brought this up before- the textures or their alpha channels don't seem to be getting properly clamped or aligned at different mip levels, which is resulting in this behavior.
3. I don't suppose HeatCloud could be made Alpha/Colormap-conformant? It'd be nice if there weren't any bitmaps in the AtlasedTexture that didn't have alpha values- this also applies to the WeaponProjectiles that are still using non-alpha-value bitmaps. Maybe I need to add a black border around mine, to get rid of the black-lines issues... Spring recognizes they have an alpha, it just refuses to read any values except for black and white...
4. Projectiles spawned by scripts are subject to a large number of limitations which currently make them impractical to actually use, except for lasers.
5. I would like to vote for CannonProjectile to just be a special instance of BeamWeapon, so that the textures are aligned with vector. It already has code to align models... why not do so with textures, and allow us to have non-circles for projectiles that are GravityAffected?
6. SeismicDetector doesn't seem to be working for me. It did for awhile, and now it doesn't. Has something changed in the code or support code? I've put FBI tags in like so:
Code: Select all
SeismicDistance=3000;Code: Select all
Mass=2000;
SeismicSignature=0.5;Still haven't encountered any crash bugs- this is all minor stuff, or stuff that will require a serious look-see. The whole AtlasedTexture thing really bugs me, though- if Trepan's icon-loading code could be used to do fast draw/swap of particle textures, it'd have the obvious advantage of being animated, plus it wouldn't be shoving a big DDS file around in front of a virtual camera frustum...
From FoeOfTheBee's test report:
[EDIT] Big fat nevermind. Must've been leftovers sitting in Foe's directories somewhere. [/EDIT]
I'm not using explofade anywhere in my code- everything is custom, or is included in my Bitmaps directory. Which means this bugger's hard-coded, when it should be looking at AtlasedTexture instead.The error I get is:
Quote:
Could not load texture from file bitmaps/explofade.tga
[EDIT] Big fat nevermind. Must've been leftovers sitting in Foe's directories somewhere. [/EDIT]
Adding UnitRestricted=5; to the wolf in NB 0.64 works fine here.Argh wrote:It appears to work right with all non-flying things, but does not work with flying things.
I reported that bug awhile ago, and then it got fixed, and now it's borked again. Sorry for not being absolutely clear- I was in the middle of the last major coding binge and was exhausted
Very minor bug, so long as you aren't heavily into unit limits and don't use a lot of flying things. Unfortunately, to make a low-limit NB variant for speedy/competition play, I need to limit Wolf production, or it's all kind've moot
Do you mean this (the blackish contour of the particles)?Argh wrote: 2. One user has reported that the "black-line" bug is still occurring on some systems. I've brought this up before- the textures or their alpha channels don't seem to be getting properly clamped or aligned at different mip levels, which is resulting in this behavior.
Pre test Minor stuff.
The mouse icon distance, does it have to have such a high limit in the settings program?
I have the impression the upper half wont be used, and sucha high scale with a slider makes it hard to be precise.
The total war camera, needs some fixing, the curve it describes when zooming in/out rigth now, is too "closed". Somehow the scale of the game has grown, and makes this camera mode a bit outdated.
This is important, as this is the easiest camera mode for observing units and landscape in close.
Rotation speed (and maybe scroll speed) settings would be sweet.
e: A note on rotation speed, is that you dont want the camara to rotate as fast when close than when you are zoomed out.
The installer doesnt make separate program group, as it did in previous dev builds. Does it use the same registry data?.(irrelevant).
Now to testing chamber.
Lolz, commander now accepts "dgun friendly" order.
Lol. made a brawler move and patrol to the same spot -> crash. (couldnt reproduce :/ )
e: i Just did, ... it didnt crash, but took 99% cpu usage. Its bit tricky to get, move and patrol same spot..
Also, the select group ai dialog, is now selectable by mouseclick, but is not selectable by arrowkeys.
where you can do that invqueue thing?..(think found it).
Also, the spring.exe has lost its icon, and the "select script" lists at start aint "mouse click selectable".
Now you cant control-v paste stuff in command line.
Createvideo doesnt seem to be working.
heh, commander can have a "dgun self" order: hit repeat, issued dgun self.
It wont fire but the order is there.
The "C" (fps mode) key, will take you to commander if you dont have a unit selected. (which is wrong imo). Also, it will dgun when you leave fps mode (not all the times).
Dgun order is lost after 2 or 3 dguns, (mobile target), which is ok, but inconsistent.
The mouse icon distance, does it have to have such a high limit in the settings program?
I have the impression the upper half wont be used, and sucha high scale with a slider makes it hard to be precise.
The total war camera, needs some fixing, the curve it describes when zooming in/out rigth now, is too "closed". Somehow the scale of the game has grown, and makes this camera mode a bit outdated.
This is important, as this is the easiest camera mode for observing units and landscape in close.
Rotation speed (and maybe scroll speed) settings would be sweet.
e: A note on rotation speed, is that you dont want the camara to rotate as fast when close than when you are zoomed out.
The installer doesnt make separate program group, as it did in previous dev builds. Does it use the same registry data?.(irrelevant).
Now to testing chamber.
Lolz, commander now accepts "dgun friendly" order.
Lol. made a brawler move and patrol to the same spot -> crash. (couldnt reproduce :/ )
e: i Just did, ... it didnt crash, but took 99% cpu usage. Its bit tricky to get, move and patrol same spot..
Also, the select group ai dialog, is now selectable by mouseclick, but is not selectable by arrowkeys.
where you can do that invqueue thing?..(think found it).
Also, the spring.exe has lost its icon, and the "select script" lists at start aint "mouse click selectable".
Now you cant control-v paste stuff in command line.
Createvideo doesnt seem to be working.
heh, commander can have a "dgun self" order: hit repeat, issued dgun self.
It wont fire but the order is there.
The "C" (fps mode) key, will take you to commander if you dont have a unit selected. (which is wrong imo). Also, it will dgun when you leave fps mode (not all the times).
Dgun order is lost after 2 or 3 dguns, (mobile target), which is ok, but inconsistent.
-
PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
And about a lobby for Lin? Multiplayer in Linux would actually be inexistant without a lobby for Linux (due to the dificulty to set up multiplayer games)... I haven't been keeping up with the development of the lobbies...Tobi wrote:It is this releasemalric wrote:I also assume this is not the version in which we can play lin vs win... Any news about that release ?
...
That would earn some major news in Happypenguin!
-
PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
ILMTitan wrote:When a mex is queued, it no longer shows the extraction range circle when showing the queue. It's not that important for maps with ota style metal, but for maps like small divide, queuing up a bunch of mexes is imprecise.
Is this intentional, or a bug? (or a setting?)
When you change the colour of the extraction radius, in that new config file added this version, it only changes when placing a mexx. After a mex is placed, when you are placing more, it shows the previous ones but in red, not the new colour defined by me. (unless that has also been fixed in the svn)trepan wrote:ILMTitan: Thanks, that was a bug. SVN has been fixed.