NanoBlobs 0.54b - Page 2

NanoBlobs 0.54b

WolfeGames and projects headed by Argh.

Moderators: Moderators, Content Developer

User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

Why are there big red N's? =s

Is it part of a strange new unit or art?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Um, the big red Ns are a little idea I had, about how to better see which units are yours, in the middle of ferocious melees, for better micromanagement. Very simply, my units have pretty drab teamcolor, and I felt like I should improve that situation, but I didn't want to make the units ridiculously colored, like most mods do. Now that I've done things this way, I'm pretty tempted to paint out all the teamcolor on the units themselves... this actually looks a lot better.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

For some reason i like the idea but I dont like the implementation.

How about if you simply had a bar or rod floating next to the unit to the left of where you'd expect its hp bar to be and of similair height, it'd be a lot cleaner imo than having the big N over unit B obscuring unit A from view.

Perhaps if they looked more like neon lights than blocks of colour.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

The only problem with that idea is that I'd have to write an uber-fancy script to keep it "to the left" at all times. Maybe just a simple, low-poly sphere, instead of an N?
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

Wouldnt it just rotate as the unit rotated? Or did you think I meant always to the left of the hp bar.....
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

See, if I don't make it rotate, it'll sometimes draw over the unit health bar. I'm thinking that the low-poly spheres might work... it'd also mean I don't need an animation ongoing all the time (I've been rotating the Ns).

Honestly, though, maybe I should get the next unit done-done, and release it as-is... and let people give me a little more feedback- the screenie doesn't give you the best feeling for how it actually looks in the game, tbh.

But I'm still converting over all of my scripts to the Zszwg Format, so I'm not ready to release yet. I got the Strider done last night, and it looks soooo much smoother and less lame, it's absolutely amazing. The SpireRook is the only one that hasn't been converted over yet... I thought I'd save it for last, because it's by far the most complex animation in NanoBlobs, and it's going to take awhile to re-create it using the new methods- probably at least a few hours tonight.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

hmm I dont see how that could happen unless I'm not making it clear....

You'd position the bar on the unit so it appeared alongside the unit, the healthbar would be higher up than the bar,I didnt mean it'd be in the air and it'd be vertical, pointing upwards, not horizontally like the health bar...

I think you're thinking of a horizontal bar floating above the units head like a halo parrallel to the units health bar
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

I will be putting up a new version of NanoBlobs soon... I've changed so much, and added so much new code... it deserves a version number.

The biggest change in the upcoming version is that I'm moving the code over to stuff that's safe to release under the GPL, so long as your projects are also qualified (i.e., you aren't "borrowing" other people's IP).

That means that all libraries used commonly by units, such as explosion definitions and other things, is getting re-written.

I've been able to cut out big swathes of code this way, among other benefits. Spring doesn't need, for example, to have BITMAP1 defined- it doesn't actually use the BITMAP calls from COB (which, to be honest, should be fixed- we should have the ability to define custom explosiongenerators via BITMAP declarations, but I'll put that in Feature Requests- probably we'll head towards a new scripting system before this becomes a priority, but meh).
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

I don't think any of Spring's effects use OTA content. However, the COB system is lifted straight from TA so you can't make a completely clean mod yet.

GPL also means (more exactly, ONLY means) that your scripts directory must contain all BOS files, not just the COBs.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

To clarify... the BOS files will be released under GNU.

The rest of the content will have to be released under the Creative Commons license, as defining a bunch of 3D datasets and bitmaps as "sourcecode" won't fly.

As for COB... erm, well... if Cavedog, or Cavedog's parent firms, wanted to defend the file format, they should've done so years ago. They can't defend it now, any attempt to assert copyright at this point would be a joke in court. Especially after Xect vs. Mynn explicitly was made (originally, a loooong time ago) to be sold commercially... and Atari did nothing.

In short... I'm going to release it all under GNU and Creative Commons licenses, and give this puppy to the world.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

But why are you complaining about using OTA content if using COBs is okay?
Egarwaen
Posts: 1207
Joined: 27 Feb 2006, 21:19

Post by Egarwaen »

KDR_11k wrote:But why are you complaining about using OTA content if using COBs is okay?
There's a difference between a file format (which can only be protected by patents, which must be applied for) and textures/sounds/models/actual script source code (which are protected by copyright by default). The implementation of COB in Spring was, AFAIK, developed without referring to the original TA source code, so it should be legal.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

^^ What he said. Not that I even am all that worried about that- Spring's been distributing said works for quite awhile now, and various OTA mods have been doing so for YEARS. I'm just being very conservative. I am sure that COB is entirely safe... I am not willing to risk things with the icons or sounds before I go the final yard.

Mainly, I'm just getting all the code cleaned up right now... I'd say I have 8 hours or so to go. You will NOT BELIEVE how much excess crap I have been able to remove from my code, now that I have zszwg's invaluable examples to draw upon... until you see it for yourselves.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Woot! Scripts are DONE.

Here's a sample of what you're going to find (with more comments, once I get to that) in the final release.

Code: Select all

// Argh's GPL AutoFac Script

// This script is released under the terms of the GNU license.  
// All contents were created by Wolfe Games.
// You may use these scripts as the basis of your mod, so long as you adhere to the terms of the GPL.
// Credit would be nice, too.

// This Include is absolutely VITAL.  
// You must call it FIRST.  PERIOD.
// Don't say I didn't warn you ;-)
#include "STANDARD_COMMANDS_GPL.h"

piece base, body, nanopoint;

// SmokeUnit_GPL is a completely optional Include.  It *requires* STANDARD_COMMANDS_GPL.h
// ...to be included (or the code) *BEFORE* you call it.
// And SMOKEPIECE1 through SMOKEPIECE4 MUST BE DEFINED!
// It doesn't matter if they all refer to the same part.
#define SMOKEPIECE1 body
#define SMOKEPIECE2 body
#define SMOKEPIECE3 body
#define SMOKEPIECE4 body
#include "SmokeUnit_GPL.h"

static-var IsBuilding;
#define SIG_ACTIVATE 2

BuildScript()
{
while(TRUE)
	{
		if(IsBuilding)
		{
			wait-for-move body along y-axis;
			move body to y-axis [50] speed [5];
			spin body around y-axis speed <25> accelerate <5>;
			wait-for-move body along y-axis;
			set YARD_OPEN to 1;
			set INBUILDSTANCE to 1;
		}
		if(IsBuilding)
		{
			wait-for-move body along y-axis;
			move body to y-axis [40] speed [10];
		}	
		while(!IsBuilding)
		{
			sleep 100;
			wait-for-move body along y-axis;
			move body to y-axis [10] speed [25];
			spin body around y-axis speed <5> accelerate <1>;
			set YARD_OPEN to 0;
			set INBUILDSTANCE to 0;
		}
	}
}

Create()
{
	hide base;
	IsBuilding = FALSE;
	start-script BuildScript();
	start-script SmokeUnit_GPL();
	return (0);
}

QueryNanoPiece(piecenum)
{
	piecenum = nanopoint;
	return (0);
}

Activate()
{
	signal SIG_ACTIVATE;
	IsBuilding = TRUE;
}

Deactivate()
{
	signal SIG_ACTIVATE;
	set-signal-mask SIG_ACTIVATE;
	IsBuilding = FALSE;
	set-signal-mask 0;	
}

QueryBuildInfo(piecenum)
{
	piecenum = base;
	return (0);
}

SweetSpot(piecenum)
{
	piecenum = base;
	return (0);
}

Killed(severity, corpsetype)
{
	explode body type FALL | SMOKE | FIRE | EXPLODE_ON_HIT | BITMAP_GPL;
	return (0);
}
Yes, that's a complete, fully-functional Plant. With references to new Include code, among other things. No Cavedog code.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Image
Image


... and yes, the Ns have weird black near the top, due to welding issues. Gonna fix that tomorrow, and try to re-create these screenies, I really liked the feel on these.

Oh yeah... and I've ... nevermind, I'll just show it off when I have a screenshot or ten...
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

those archers look cute
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

The Archers haven't been changed, nor has anything else, other than the new units that have gotten added. The animations, though... you've gotta see 'em to understand why I'm so stoked about this. They're smooth and run very nicely. The SpireRook has finally gotten the offset-series script it always deserved, too!

Oh yeah, and I'm going to re-master the DDS files before final... forgot about that... I didn't realise how cruddy they were starting look up close, after being re-zapped by me about 50000 times during earlier dev.

More screenies:

Image
Image
Image

I really love that last one... the fake WWI look really drives home where the good ol' SpireRook came from- bad pop sci-fi from the 1930s :-)
User avatar
NOiZE
Balanced Annihilation Developer
Posts: 3984
Joined: 28 Apr 2005, 19:29

Post by NOiZE »

TBH i don't like those big N's, I would prefer more teamcolor.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

I dropped the Ns in favor of spheres that look like circles. The last screens are current solution- what looks like a perfect circle unless you're really close, but is a 264-tri sphere.

I hate teamcolor with a passion, and tbh I'm tempted to remove it from the models entirely, now that I have an alternative, since I'm already intending to re-master the DDS files.

It's mainly just a matter of taste there- players obviously need to know what team a given unit is on. Most games use teamcolor, which I find lame- IRL, we don't drive around with bright red stripes on our tanks, and neither should we in Spring, imo.

I'd rather see the models look natural and have some other means of identifying them... whether an icon above them, or a glowing bitmap below them... I'm trying to talk colorblind into maybe giving us a wee icon above the unit health bar... that'd do it, and it'd both be more attractive than my current solution, and probably perform better too.
User avatar
NOiZE
Balanced Annihilation Developer
Posts: 3984
Joined: 28 Apr 2005, 19:29

Post by NOiZE »

Like a decal below them would be kool, but something above the units just looks wrong IMO because instead of units we see dots now...

I mean the dot above the archer is almost half the size of the archer itself.
Post Reply

Return to “Argh's Projects”