Thanks Elv,

Here's another one.

It's a building designed especially for the Item Shop, Weapon Shop & Depot

If I want an Item-shop then I'll disable the sign for Weapon-Shop and vice-versa.
And if I need a Depot then I'll just disable both of them

This time I've made the windows a bit bigger. They're shop-windows after all
A second texture will be added to the class-part of all the windows. It's a pre-computed cube-map. So, when you rotate the camera, you will notice the shininess of the windows



As for the town,

I've added a fountain , complete with sections of "falling water".

The church is added too, complete with moving church-bel.

The camerasystem is complete too. You can walk in one direction, and rotate the camera 360 deg. simultaneously .  

More houses are added. I've programmed it in such a way that not all chimneys will smoke and if you leave and re-enter the map, then it will be different from the last time.

I also made a few more textures for these houses, there are now different colors for the roof and walls. In short....  9 different textures for 1 house-model,  now.. if that's not efficient, I don't know what is.

More maps (almost complete):

The Harbour-map
This will map will feature a "slopey" terrain. It contains the Lighthouse , a dock , 2 or 3 ships , along with numerous crates and a number of Lanterns.
(I'll make a screenie of this one soon)

-#-

The Airfield-map (screenies coming soon)
This map will feature a landing-site for the air-ships. Ships will take off and land

I've modeled a new Battlecruiser (work in progress) . This will fit right in. (screenie!)

-#-

I've decided to make a seperate map for the graveyard.
It was scheduled to positioned in one of the sections of the main town, but it just felt
out of place. The graveyard is now located in a forest-area (wow , even more screenies to make )

-#-

I've also modeled a small part for a market (screenie..(this is getting boooriiiing )     
It's a market-stand complete with roof , and four crates with vegetables.
So, a few of these, a couple of carts , seperate cart-wheels ,  a lot of crates, and you have a nice market.

Phew , I'll rename this week the "make a few screenies week"

See Ya
   

Thanks for correcting me,
It's true that there are only units in Herzog Zwei.
I said C&C, but what I meant was Warhammer 40K Dawn Of War.
(I've played so many RTS's , it's difficult to tell them apart)

In DoW you capture strategic points.
1) All strategic points generate resources.
2) You build Generators with these resources.
3) The Generators produce energy.

The stronghold produces workers with which you build the rest of the buildings.
All buildings have (some sort of) upgrades.

Sooo,.....

Looking back , if we decide to keep all the different buildings, it is starting to look like the Settlers. Argh... Settlers is mostly about economy. ... Not want ....

Eerrrmmm... ok... to stay true to most of the mechanics of Herzog Zwei,
I say we drop all buildings, except the main base (the Castle) and the satellite base (the Keep).

We could still include the Mitril-upgrade .
The mine should always be positioned near one of the Keeps.
If the Keep is yours, you automatically receive the armor-upgrade,
From that moment on, every unit you build has the armor-upgrade.
And if you lose the Keep, you lose the upgrade. Simple
(Units that already have the upgrade, will not be affected)

The following is sooo Herzog Zwei:

1) All other units will emerge from the Castle.     
2) You can only build one unit at a time.
3) Every order costs money.

1) and 2) are definately in.

About 3) : We could do one of two things.

One: do exactly as in Herzog Zwei. So... when you right-click on a unit:

a) This brings up a small window,
b) This window contains info about the current unit,
c) It also has info about its current order,
d) Show the rest of the orders & the cost of each order
e) Click on the appropriate order
f) Click on OK to buy that order
g) Cost of the order is deducted from your credit-total
h) Window closes       

Two:

Use Rectangle Unit-Selection and still use the "buy order" procedure.
This means you would be charged for every unit that is currently selected.

The formula could be (NUMBER_OF_UNITS * ORDER_COST = COST_TOTAL )
That could mean that, if you have a large force selected and you give it a new order,
you may end up with no money left to buy another unit (for a short period of time).
But that is up to the player of course.

Elvenfyre......., you decide  
(I'm voting 1) btw)

-#-

Further improvements on a basic system could allow units to gain experience and level up allowing them to be recalled with a higher level in harder battles

We could add a level-cap to prevent player-character becoming too strong ?

-#-

Receiving credits: (as in HZ)

Code:

			o---------------o-----------------o
                        | No. of Bases  |   G per second  |
                        o---------------o-----------------o
                        | None          |       40        |
                        | One           |       80        |
                        | Two           |      120        |
                        | Three         |      160        |
                        | Four          |      200        |
                        | Five          |      240        |
                        | Six           |      280        |
                        | Seven         |      320        |
                        | Eight         |      360        |
                        | Nine          |      400        |
                        o---------------o-----------------o

None bases means that you have only your main base left (gives 40 G)

-#-

Capture base with 4 infantry.
If base is captured by RED, then BLUE must capture it with 4 infantry.
So, if base is owned by RED, and BLUE has 3 infantry in that base, it's still RED (so there.. )

-#-

Idea:
Change the iconography of Herzog Zwei to that of Shining Force (animated ?)

-#-

Idea:
Introduce Fog of War in CoGI ? HZ didn't have Fog of War (IIRC).
I'm working on a simple system of using VertexAlpha with transparency. (it's last on my TO-DO list)
If it doesn't work we could always chuck it out the window, yes ?   

-#-

Idea:
Introduce permanent radar ? 
Radar in HZ was only accessible through the buy screen.

-#-

I've been working on a number buildings the whole weekend (Both Dark Resurrection AND CoGI , and this is what I've come up with.

THE CASTLE:



On the flagpole you see two small cubes. These are refencepoints for the flags I'm putting in. The flags will move with the wind. This should be a nice effect. 

I'm using sprites as decals for the windows. These will applies from within the program.

THE KEEP:



For neutral Keeps there are no flags.
The flag (with your colors) for will go up, the moment you capture the base.
The same applies for the enemy.

The flag is a separate model , so that's why you cannot see it in these pictures.

So far, so good

Cheers

Well, I've played Herzog Zwei to death. It is an awesome game, and it has some great music too. I still have the game and play the music from time to time .

Project 2612 ( http://project2612.org/index.php ) has the music in the archives. They are currently trying to find a new host, so it is possible that not all files are ready for downloading.
(You have been warned!  ) 

-#-

As for the resource model - We could mimic the procedure from Herzog Zwei ?
For each base under your control (including your main base ) you get a certain amount of credits (per second).

-#-

Also, to capture a base, you had to send 4 infantry to effectively get it under your control.
We could make it so, that not only the units will capture the base , but also defend it.

This way you could have some great battles, because you would have to fight for each occupied base in order to capture it.

-#-

We can still include the mithril though.
Just always position one base near a mithril-deposit.
If you've captured the base then instead of credits, you receive mithril. (......just a thought   )

As for the rest of the buildings,.. we could always "buy" them , yes?
 
-#-

Anyway, for a good start of this project:

I think it would be a good idea to start with the story.

- Introduce the main characters, locations & period when it happens, etc.
- Explain the reason why they are fighting.. and who.

If you would like to start with drawing a map (1024x1024 px) for the first mission, then that would be great too.

I'll start piecing together the main program.
 
-#-

About the Mapsize:
 
The maximum dimension for a battle-map in Dark Resurrection is a grid of 400x400 tiles. The tiles have a size of 2 (blitz3d-)units , so I can assure you, these are very large maps!!

You see.., the AI has to figure out a path to its destination. It returns a "1" if a path has been found , and "2" if a path is non-existent.

When it returns a "2" then the AI has already checked the ENTIRE grid of 400x400 tiles.
That's why I treat this size as a maximum (for now).

On a P4 with 1G memory it's almost an immediate return, so that's good thing.
 
-#-

About the Buildings:

There are a number of buildings (made many moons ago) I can use as a placeholder, so I can get a feeling on how to work on them. These are early previous versions of models I made for Dark Resurrection. So they will do just fine .   

For example:

1- Where to place a building, and perform a check if you place the building.
2- "Hitpoints"of a building
3- Using the numerous "build-timers" to represent the unit-construction
4- Check how far the player is in the "tech-tree", so he can actually build the thing.
 
-#-

About the Units:

On my harddrive I still have the sprites of SFII, so I could use these as placeholder for the moment.
It certainly looks much better than a bunch of white cubes and spheres.

Recently I've bought a few books on how draw characters in manga-style.
These were bought to make character-references for Dark Resurrection.
There are enough ideas in these books to create new characters in Shining RTS

This is not going to be the definitive title.
Maybe something like: Crusade of Great Intention  (just of the top of my head )
 
-#-

About the AI:

I can safely say that the AI, in its current state, works great.
Just modifying it for group-AI and alternative pathfinding for choke-points.
 
-#-

Bits & Bobs:

It's probably a good thing to already think about unit-acknowledgements.
You know the drill:

"yes sir"
"acknowledged"
"moving out"

Maybe a bit like C&C. Also, I think it would be ace if there is a female voice that announces if a "unit is ready" or "your base is under attack" ... something like that. 


0_O .... Oh my...... another long post
Think I'll shut up for now.

Bye everyone             

Before I started Dark Resurrection in Blitz3D, I was busy programming a remake of  "Herzog Zwei" .
It was one of the first RTS-games (if not THE first) , and that's in 1989,  waaayy before Dune II.

Anyway, there were a number of things that stopped me from completing it. Group-AI and pathfinding for example.
Now that I finally started to understand A* pathfinding, it doesn't seem to be that difficult anymore.
My first thoughts were to finish Herzog Zwei alongside Dark Resurrection.
(Trust me , when you work too long on -a part of- a game, you're beginning to lose focus on what you're doing)
That is why I switch from programming to studying character-animation , and from character-modelling to texturing & skinning.

Ahem..., to cut a long story short ..., it could be fun to alter Herzog Zwei into a Shining Force RTS.
It could even be more fun if this was a group effort.

Someone could focus on writing the story and another one could design the campaign.

Maybe there could be an option to play the good guys as well as the bad guys ?
And who wants to do the balancing, in order to finetune the units and/or buildings ?
I could write the program in Blitz3D. It can be either 2D or 3D.
My code-library is literally overflowing with specific functions.

Code that can already be used:

1 - Unit selection by drawing a rectangle with the mouse.
2 - assigning unit to function keys (CTRL + F1,F2,F3 etc etc).
3 - double-clicking a specific unit will select all units on screen.     
4 - left-click a unit will select/de-select a unit.
5 - right-click a selected unit will move that unit to the clicked position.
6 - build-timers to represent the -length of the- construction of a unit.   
7 - saving & loading of data of units if you decide to quit during play.

For units , we could take a number of characters with specific abilities and/or specific weapons

Here are some ideas:

Code:

Player-Units:
-------------
5 of 6 player-units each with his/her own profiency.

Possible capabilities:

1 - extra defense
2 - healing capabilities
3 - extra movement-speed
4 - better skilled in short range weapons
5 - better skilled in mid range weapons
6 - better skilled in long range weapons

Groups will consist of up to 9 units. 
Each unit-type will have his own movement-speed, but when a group has mixed units,
its combined movement will drop to the speed of the slowest-unit within that group.

It is possible to have a group with mixed units (for example 2 archers , 1 priest , 3 knights & 3 dwarfs )
When you attach a player-unit to a group, then a number of statistics (if not all) will be affected.
Let's say that I have a group with 4 archers , 1 priest and 4 dwarfs.
I'll attach a player-unit that is proficient with a bow. 
This will affect all archers in this group.

Or you can attach a player-unit with healing capabilities that affects all units within that group.

Normal Units:
-------------
1 - Priests with offensive spells   
2 - Wizard with defensive spells
3 - Archers with long range weapons (arrows)
4 - Knights with mid range weapons (javelins or spears ,.... no..... not britney spears.. :) ) 
5 - Dwarfs with short range weapons (axes and/or swords )         
6 - Sniper (very long range, very expensive ;)  )

Mechanized units: 
-----------------
1 - Big Arrow-Launchers 
2 - Laser Eyes
3 - Mecha dragon
4 - Cyborgs

A super unit for each side:
---------------------------
1 - Volcanon
2 - Zeon (or Lucifer or Dark Dragon)

Buildings - overview:
---------------------
1  Castle 	- your main building
2  Weaponsmith	- forge mithril- weapons and\or armor
3  Church	- bring back the fallen player-units
4  Mine		- ...erm ... mine the mithril
5  Barracks 	- training the "short range" weapon users
6  Keep		- training the "mid range" weapon users
7  Archery	- training the "long range" weapon users
8  Mill		- process wood for building ...errr.. buildings 
9  Forest Hut	- chop wood
10 Shrine	- summon your super-unit
11 Masonry	- process stone for buildings 
12 Spell Tower	- research new spell-levels , spell-efficiency , extend spell-range  
13 Laboratory	- research new ways for being more efficient with resources. (do more with less)    
14 Shop		- buy extra personal defense-items

Building-Tech-Tree:
-------------------
Castle Lv1	- 1 barracks
		- 2 weaponsmith
		- 3 masonry
		- 4 forest hut
		- 5 mine
		- 6 mill

If you have all of these buildings then you are eligible to construct:

Castle Lv2	- 7  church
		- 8  keep
		- 9  shop

If you have all of these buildings then you are eligible to construct:

Castle Lv3	- 10 archery
		- 11 spell-tower
		- 12 shrine
		- 13 laboratory

All buildings have their own efficiency level.
If a building has a high efficiency-level then it will cost less to produce units from it.

Lv 1 : 10% less construction costs 
Lv 2 : 20% less construction costs
Lv 3 : 30% less construction costs

Shop:
-----
Bracelets
Rings
Shields

Player can buy these items for their player-units.

Items can affect:
1 - movement-speed
2 - rate of HP-point regeneration
3 - rate of Spell-point regeneration
4 - increase sphere of command 
5 - ???? 

Spells: 
-------
1 - Fire
2 - Ice
3 - Lightning ( Bolt ?)
4 - Earth
5 - Holy
6 - Dark 
7 - ????

Spell-points are automatically regenerating.
New spell-levels are researched in the Spell-Tower.
Player can find rare spell-books in missions.

Resources:
----------
Gold		- mine gold to buy units & construct buildings
Mithril		- mine mithril for the best armor
Wood		- chop wood for constructing buildings
Iron		- mine iron for making normal armor 
Stone		- cut stone for constructing buildings

Mission-Types:
--------------
1 - reconnaissance
2 - basic "expand base & defeat enemy"
3 - convoy
4 - take defensive position
5 - search & destroy
6 - search & rescue
7 - stealth mission
8 - a combination of one or more of the above :D  

Pff. now that's a long post.

Again, these are just ideas., so everything can be changed.
So, when you're up for it, just let me know ok ?

Cheers, 
Peter

Great, your music is exactly what I'm looking for. 

My question is: are you interested in composing for my game DARK RESURRECTION ?

If you want financial compensation, then that's no problem at all.

"Should you accept this mission" ( ) then PM me and we can talk some more , yes ?

Cheers   

Happy New Year everyone,

Here are some screenies:






It's a work in progress at the moment.

I'm busy with placing (and positioning) the houses .The streetlanterns are up next. (There are already a few on this map, just to see if these fit with the rest of the scene.)

To do: bushes, trees, crates, benches,fences. My goal is to create a datafile for each collection of objects (one file for the houses, one for trees, etc)

I've written a function that takes care of reading these files.
The idea is to give each map a unique name.

Like this:

Function Create_Town ( MapName$ ) 

create_house ( MapName$ )
create_lantern ( MapName$ )
etc
etc

End Function 

The "Mapname$" parameter is where the unique name is entered.  It's transferred through all the other function-calls. This way it's easy for me to load the data for all these different objects.

All files are read until the pointer reaches the end of the file.

So, it's possible  to have a very large file with data for positioning trees, or a very short one with data for crates.

Also , not all maps need houses, and not all maps need trees ( dungeon maps for example )
I've taken care of this problem. 
There's a check to see if a file exists for a certain object.
If there IS a file then the contents are read.
If it isn't there, then it simply skips the reading part.
This way I can avoid reading-errors.

After all , you can't read what isn't there, yes ?

That's all folks.

See you soon

Pathfinding is coming along quite nicely 
It can now detect obstacles and can move around them.
It's tested to death with numerous configurations, and it's working well ...
with one exception: 

When a character tries to access a free tile surrounded by occupied tiles , it may cause a hiccup FRAMERATE-wise.     

Some things I'm working at the moment:

---------------------------------------------------------------------------

The general idea is avoid the tiles which are occupied by a character.
I'm thinking of including the LANDEFFECT just for defense-purposes, and not in terms
of movement-cost. Just playing with the idea, so nothing is set in stone.

---------------------------------------------------------------------------

Camera-movement is almost complete. When you control the cursor, the camera tries to keep looking at the cursor. It's a smooth movement because I've used a method that computes the vector between the CURRENT angle of the camera and the ACTUAL vector between the camera and the cursor.

So, when the player has decided a good spot for his/her character to move (by pressing SPACE) the camera is "glued" to that character. And now the camera will turn to that same character with the aforementioned vector-method.

---------------------------------------------------------------------------

That's how far I am at the moment. To do the same thing for the computer is a different kettle of fish. A good start would be to think how "I should do it" .

Thank you , Ty and Elvenfyre for your input. 

I've emailed Devlyn about this , and he supplied me with a small list with a number of
possibilities for attack-preference. He's on the case right now.

First, I'll start with a basic "when-near-then-attack" pattern.
When this works well , I will add more choices for random attacks.
(Probably a combination of all the ideas that were discussed previously.    )

Again,... Thanks     

Thanks Elvenfyre, 

There already were a few thoughts about which enemy to attack.
A quick look at your list made me realize that you have thought this process over far more better than me

The methods I have so far are:

1) Attack closest one
2) If leader is closest and not targeted -> make leader the target.
3) Check enemies in range for less than half HP of maximum
4) Check the position to attack enemy.
( attack from the side , rather than from the front / attack from the rear , rather than from the side )

-------------------------------------------------------------------

My 1) , 2) and 3) are on your list too. So these are definately 'in'.

-------------------------------------------------------------------

What do you think of my no. 4) ?

-------------------------------------------------------------------

I like the randomness of choosing, so that goes in as well.

-------------------------------------------------------------------

Your 'type'-attack looks quite interesting.
Is it possible to compile a list of enemies that would 'prefer' to attack certain characters ?

-------------------------------------------------------------------

It is probably a good idea to give all possible actions a certain priority and combine
them with the flow-chart I made some time ago.

*rummaging through year-old posts*

Ok.. found it.



-------------------------------------------------------------------

More news from the 'programming front':
The entire pathfinding Lib is now in 3D . HUZZAH! 

Started adding code from characterdata-arrays.

Also found some old code for smooth cameramovement. That goes in as well.

Looking back ,....the biggest hurdle was getting some good pathfinding.
Lucky for me it's now a thing of the past.  

Well.... that;s it for this time

Ta.
       

The last two weeks were used to find a respectable way for implementing a pathfinding routine for computer-enemies.

Eureka...... as Archimedes would say( except I'm not running around in the streets naked  )

Okay, it's (very) early days at the moment, but for now... a red cube is chasing a white cube, and if you click anywhere on the screen, the white cube is moving towards the mouse.

Yup, it starts out in 2D and it ends in 3D . That's because it is a reprogrammed version of the 2D A*-pathfinding-lib by Patrick Lester.

( http://www.policyalmanac.org/games/aStarTutorial.htm )

The goal is to turn the entire 2D lib into 3D, but this shouldn't be much of a problem. 

More news soon....

Kthxbye 

I've programmed an "equipment-check"... finally
It was one of the things I "forgot" to do

All you need is the name of the character who does the buying, and
the name of the weapon that the character buys. The function takes care of the rest.
There's even a check for weapons meant for the characters that did not have a promotion.
(in other words: weapons that can only be used by promoted characters.)

#####################################################################################################

Other things that are finished:
When a character levels up, he/she receives a certain number of points, distributed over:
HP , MP , AGI , ATT , DEF. The computer deals, ... and that's it.

My idea for point-distribution is the following:
 
Let the player decide how many points go to HP , MP , AGI, ATT or DEF.
As long as you are in "distribution-mode" you can change the allotted points to your heart's content.
I'll even throw in a check to make sure that all points are used , before you return to the battle-screen.   

According to a walkthrough made by Apathetic Aardvark (at GameFaqs) it seems that promoted characters receive
a bit more point than not-promoted characters. I'll take that into account.

######################################################################################################

There seems to be an annoying bug in Blitz: it looks like there's a maximum number of data-statemens you can use.
I struggled with this one for a long time.
It doesn't matter if you divide the code in numerous files.
( one file for globals , another for constants etc)

When I use a DATA-statement and then run/compile the code, it automatically opens the "OPEN BLITZ FILE" window
for no apparent reason. ...What a bummer . Luckily most of the data is already present , and this works.
If , for some reason, I still need more data, then I'll simply create a very small program to store all data in a DAT-file.
The program will read the Data and stores it into a DIM , very simple.
Now that I know where the bug is, I'll work around it    

Tally Ho, 

 BTW (here's the code for the equipment check:)

Code:

Function Equipment_Check( PlayerName$ , WeaponNumber )

	Select PlayerName$
	
		Case "bowie" 	Name  = bowie 	: Prom0 = sdmn 	: Prom1 = hero 	: Prom2 = 0
		Case "sarah" 	Name  = sarah 	: Prom0 = prst 	: Prom1 = vicr 	: Prom2 = mmnk
		Case "chester" 	Name  = chester : Prom0 = knte 	: Prom1 = pldn 	: Prom2 = pgnt 
		Case "jaha"  	Name  = jaha 	: Prom0 = warr 	: Prom1 = gldt 	: Prom2 = brn
		Case "kazin"  	Name  = kazin 	: Prom0 = mage 	: Prom1 = wiz 	: Prom2 = sorc
		Case "slade" 	Name  = slade 	: Prom0 = thif 	: Prom1 = ninj 	: Prom2 = 0
		Case "kiwi" 	Name  = kiwi 	: Prom0 = tort 	: Prom1 = mnst 	: Prom2 = 0
		Case "peter" 	Name  = peter 	: Prom0 = phnk 	: Prom1 = phnx 	: Prom2 = 0
		Case "may" 		Name  = may 	: Prom0 = rngr 	: Prom1 = bwnt 	: Prom2 = 0
		Case "gerhalt" 	Name  = gerhalt : Prom0 = wfmn 	: Prom1 = wfbr 	: Prom2 = 0
		Case "luke" 	Name  = luke  	: Prom0 = bdmn 	: Prom1 = bdbt 	: Prom2 = 0
		Case "rohde" 	Name  = rohde 	: Prom0 = brgn 	: Prom1 = brgn 	: Prom2 = brgn
		Case "rick" 	Name  = rick 	: Prom0 = knte 	: Prom1 = pldn 	: Prom2 = pgnt
		Case "elric" 	Name  = elric	: Prom0 = achr 	: Prom1 = snip 	: Prom2 = brgn
		Case "eric"  	Name  = eric	: Prom0 = knte 	: Prom1 = pldn 	: Prom2 = pgnt
		Case "karna"  	Name  = karna	: Prom0 = prst 	: Prom1 = vicr 	: Prom2 = mmnk
		Case "randolf" 	Name  = randolf	: Prom0 = warr 	: Prom1 = gldt 	: Prom2 = brn
		Case "tyrin"	Name  = tyrin	: Prom0 = mage 	: Prom1 = wiz 	: Prom2 = sorc
		Case "janet"	Name  = janet	: Prom0 = achr 	: Prom1 = snip 	: Prom2 = brgn
		Case "higgins"	Name  = higgins : Prom0 = pldn 	: Prom1 = pldn 	: Prom2 = pldn
		Case "taya" 	Name  = taya	: Prom0 = sorc 	: Prom1 = sorc 	: Prom2 = sorc
		Case "skreech"	Name  = skreech : Prom0 = 0 	: Prom1 = 0 	: Prom2 = 0
		Case "frayja"	Name  = frayja	: Prom0 = vicr 	: Prom1 = vicr 	: Prom2 = vicr
		Case "jaro"		Name  = jaro	: Prom0 = pgnt 	: Prom1 = pgnt 	: Prom2 = pgnt
		Case "gyan"		Name  = gyan	: Prom0 = gldt 	: Prom1 = gldt 	: Prom2 = gldt
		Case "sheela"	Name  = sheela	: Prom0 = mmnk 	: Prom1 = mmnk 	: Prom2 = mmnk
		Case "zynk"		Name  = zynk	: Prom0 = rbt 	: Prom1 = rbt 	: Prom2 = rbt
		Case "claude"	Name  = claude	: Prom0 = glm 	: Prom1 = glm 	: Prom2 = glm
		Case "chaz"		Name  = chaz	: Prom0 = wiz 	: Prom1 = wiz 	: Prom2 = wiz
		Case "lemon"	Name  = lemon	: Prom0 = brn 	: Prom1 = brn 	: Prom2 = brn

	End Select
	
	For T = 1 To 7
		Select Warray ( Name ,  1 )

			Case  -1
				If Prom0 <> 0 
					If ( Weapon_Data ( WeaponNumber , ( 6 + T )) = Prom0 )
						Return True
					EndIf
				EndIf

			Case  0
				If Prom0 <> 0 
					If ( Weapon_Data ( WeaponNumber , ( 6 + T )) = Prom0 )
						Return True
					EndIf
				EndIf

			Case 1 
				If Prom1 <> 0 
					If ( Weapon_Data ( WeaponNumber , ( 6 + T )) = Prom1 )
						Return True
					EndIf
				EndIf

			Case 2
				If Prom2 <> 0 
					If ( Weapon_Data ( WeaponNumber , ( 6 + T )) = Prom2 )
						Return True
					EndIf
				EndIf 

		End Select 
	Next

	Return False
	
End Function

Well, a few years ago I played Warhammer 40K on the PC. In that game I noticed that some characters did have some sort of 'aura' around their heads.

Especially the Space Marine Chaplain. Other character did have a flare for the Magic Rods. Don't know for sure if it's the same flare or perhaps only differently programmed.

I can sure use it,.. only NOT for lanterns. 
   

Hi Everyone,

I've done some major stuff lately.

First off:

The event-system:

This system will take care of events that are currently running:
Each event has a unique ID-number. This way I can check if a certain event is initated or not.
It is flexible enough to do a number of things:

1) Play a sound
2) Start a scripted event (cutscenes)
3) Start NPC-related stuff
4) Change active zones (see Zone-System for more info)

There are a number of events:

1 ) Switching from Day to Night ( O rly ?)
2 ) Switching from Night to Day ( Ya rly !)
3 ) Fog
4 ) Rain
5 ) Storm (mainly storm-SOUNDS for now)
6 ) Thunder
7 ) Falling leaves from the trees
8 ) (De)Activating lightflares from lanterns
9 ) a few other ones I'm working on at the moment

Switching between Day/Night (and vice versa) will take approximately 2 to 3 minutes. So it's hardly noticable.
Until you realize: Hey , wait a minute, it's dark (!!) 

######################################################################################

The Zone-System:

Each map or dungeon is divided into a number of zones.
Each zone has a unique ID-number.

Here's how it works:
Each zone checks its location in the Gameworld and its relation to other zones nearby.
Each zone checks also its contents: trees , treasurechests , torches . Basically all NON-moving stuff.
And because these entities are non-moving, it's very easy to catalog these things and store their ID-number,
entitytype , X-Y-Z-position , X-Y-Z rotation , etc.

All this info is then put into a datafile. The program reads the file, copies the appropriate models and puts
them on the same position and turns them at the correct rotation.

Now comes the tricky part:

Please look at the picture below.



The BLUE zone is the zone where the camera is in.
This zone is related to all the surrounding GREEN zones.
The YELLOW zones are currently 'sleeping" because they are not close enough to the camera.

The camera is always connected to the player ( it moves to a position behind it -> = third person )
Thus, when the player moves, the camera moves with it. (so far so good )

Eventually, the camera will leave the current ( BLUE ) zone and move into a GREEN ZONE.
Now, this zone contains info about all the zones around it.
The camera will now activate the nearest sleeping zones and deactivate the furthest active zones.

And as long as a zone is active, it will perform a number of tasks.
(Move trees , leaves , check visibility of lanternpositions in relation to cameraposition etc.)

########################################################################################

Lanternflares:

Ooh boy. Do I have this one sussed out or what?
It's actually a lighting trick you can find in today's AAA-games.
In c++ (and pascal I think) there is a statement called PRIORITY. The Blitz-equivalent is ENTITYORDER.
If you activate this for a certain entity, you can determine it's "drawing-order"

Normally it's default position is 0 (zero). Now, when I change this into a "1" or a "-1" you can change the order.

"1" means that it is drawn FIRST, so that it appears BEHIND everything else. ( SkyBoxes are a very good example )
"-1" means that it is drawn LAST, so that it appears in FRONT of everything else. ( A good example is said lantern-flare).



The lantern on the left has its flare drawn first and looks very unimpressive.
The lantern in the middle has its flare normally , and is just plain wrong.
The lantern on the right has its flare drawn last , and looks very good.     


More news very soon,

Toodle Pip

Here are some more houses. Different models , same supertexture 





The skull is nearly complete, hold on to your hats !
Screenies very soon (Film at eleven)

Also: Puzzle-Dungeons are nearly complete. I'll make some screenies of these dungeons this weekend.

See ya in a few days. 

Ta!

The top-part of the carriage can be flipped inside-out.
This way, you can see the inside of the carriage without obstructions.

Four of these [carriages] will make a nice "moving" battlefield.







This is one of the "inhabitants".
Warning: completely ignore the head (skull), laugh at it's "naffness".
I'm working on a much better skull.