torches in CSBwin

[Adamo]

http://www.dianneandpaul.net/CSBwin/Tec ... aneous.htm

Every ninety seconds each torch currently in use has its number-of-charges decremented by one. When it reaches zero the torch is marked as 'un-important'. So, if you want your torch to last forever, put it down on the floor for a moment during the ninety-second update period so that it will be ignored.

90 seconds is about 450 game ticks. Can I prevent a game somehow from cheating this way? It is extremally important in my dungoen, and tremendous task, I guess. I was thinking about many ways to do that.
Can it be changed that the game knows exactly how long the torch been already used to prevent the cheating? Like this: torch has been used by 200 ticks period and put down on the floor (or packed into the backpack), so the engine knows there`s 250 ticks left before torch decrease its state.

[Paul Stevens]

I really doubt that anyone cheats in this
way. But they certainly could if they were
very dilligent and developed some sort of
timing mechanism triggered by the rather
obvious 90-second updates to mana, etc.

You could have a instance of a DSA for each
torch in the dungeon. Every second you could
examine the torch to see if it is in a character's
hand. The new &ISCARRIED might be helpful.
Then, each second you could set the number of
charges as you please.

[Adamo]

I really doubt that anyone cheats in this
way.

in original games- i don`t think so. But in my dungeon light will be rather valuable; that`s the idea of my whole game. That`s why I need this feature.

Every 90 seconds torch changes its state; as there are 16 states, I guess there is 16*90 seconds when full torch become lit?
That gives about 6480 game ticks (as there are ~4.5 tick at a second).

You mean a DSA that constantly checks specified kind of item (here: torch) if it`s holded in party`s inventory (here: hands) and substracts the value?

In fact, the "torch" item contains of 4 items:
- torch full
- torch 2/3 lit
- torch 1/3 lit
- torch lit
because they are changing each other.

So the DSA should change not only the item (is it #1 torch, #2 torch or #3 torch), but also its state (1-5 for #1 torch, 6-10 for #2 torch and 11-15 for #3 torch) and substarct from 405 game ticks (if 1 second= ~4.5 ticks)..?
Like this: a torch#3 state 15 lies on the floor. Character takes the torch (hold it in his hand) and a DSA starts counting. After 405 ticks (90 seconds) DSA changes the torch#3 state to 14. Etc.
When a torch#3 (full) at state 11 expires, a DSA changes the item to torch#2 (2/3) state 10.

[Paul Stevens]

That is the sort of thing I had in mind. If
your arithmetic is correct then you could
set the torch's value to 6480 ( 16*90*4.5),
subtract 9 every two seconds that the torch
is actually in use, and set its state to the
current value divided by 405.

[Adamo]

ok. I made a lot of tests. I set the 1-15 value in the editor and checked when will torch expire.

0) torch state=0, torch graph=0 (lit torch)
1) torch state=1, torch graph=1 (almost burnt)
initial time=100, expire time=512
2) torch state=2, torch graph=1 (almost burnt)
initial time=100, expire time=1024
3) torch state=3, torch graph=1 (almost burnt)
initial time=100, expire time=1536
4) torch state=4, torch graph=2 (half burnt)
initial time=100, expire time=2048
5) torch state=5, torch graph=2 (half burnt)
initial time=100, expire time=2560
6) torch state=6, torch graph=2 (half burnt)
initial time=100, expire time=3072
7) torch state=7, torch graph=2 (half burnt)
initial time=100, expire time=3584
8 ) torch state=8, torch graph=3 (full)
initial time=100, expire time=4096
9) torch state=9, torch graph=3 (full)
initial time=100, expire time=4608
10) torch state=10, torch graph=3 (full)
initial time=100, expire time=5120
11) torch state=11, torch graph=3 (full)
initial time=100, expire time=5632
12) torch state=12, torch graph=3 (full)
initial time=100, expire time=6144
13) torch state=13, torch graph=3 (full)
initial time=100, expire time=6656
14) torch state=14, torch graph=3 (full)
initial time=100, expire time=7168
15) torch state=15, torch graph=3 (full)
initial time=100, expire time=7680

it seems whole time (from 100% full to 0% full torch) lasts 7580 ticks. State 1 has 412 game ticks and states 2-15 uses 512 game ticks each.
Torch state 0 uses "lit" torch graphic, torch states 1-3 uses "almost empty" torch graphics, torch states 4-7 uses "half burnt" torch graphics, torch states 8-15 uses "full" torch graphics.

[Adamo]

Code: Select all

torch brigh pal  torch 
state tness num* graph 

15    100   0    #1(full) 
14    97    1    #1(full) 
13    94    1    #1(full) 
12    89    1    #1(full) 
11    82    1    #1(full) 
10    76    1    #1(full) 
9     68    2    #1(full) 
8     59    2    #1(full) 
7     51    2    #2(partially burnt) 
6     46    3    #2(partially burnt) 
5     40    3    #2(partially burnt) 
4     33    3    #2(partially burnt) 
3     24    4    #3(almost burnt) 
2     12    4    #3(almost burnt) 
1     5     4    #3(almost burnt) 
0     0     5    #4(completely burnt) 

"torch state" means "torch intensity" 
and is used for calculating brightness 

"brightness" is used for calculating ingame 
palette number 

(*) -here: in case of one light source 
only (one torch) 

EDIT: incorrect (unexisting!) values removed

The intensity must be a number between 0 and 15 and is converted to 'Brightness' by the following table which is contained in the 'graphics.dat' file

so can I change brightness that each "torch state" (intensity) gives for the calculations by editing graphics.dat file? for example I would like state 2 to give 11 brightness instead of 12, as it is now?

[Paul Stevens]

so can I change brightness...by editing graphics.dat file

I think so.

[Adamo]

You can set "lighted torch" flag in CSBwin editor. But I don`t get the idea.. The torch will have a disabled first use; when you hold it first time, it won`t give any light. Second time it will work properly. Moreover, in the backpack it has its own graphic (#1, #2 or #3 - depending how you set it in the editor), while normally it has #4 graphic. What is it for?

Btw, how can I change the brightness in graphics.dat file (which are the bytes, where is it)?

[Adamo]

a DSA that constantly checks specified kind of item (here: torch) if it`s holded in party`s inventory (here: hands) and substracts the value

the DSA should have to manipulate the states of the torch by itself, not by the engine. By substracting from 512 (there`s no need to substract from 412 in state 1 as it`s in the original code; it`s doesn`t make a big difference and makes it all less complicated).
When a party takes a full (state 15) torch in its hand, the DSA starts counting from 512. When a party put torch on the floor, it stops counting. When the party holds torch again, it continues substracting (now, if you put the torch on the floor, the "duration" value will reset and again start from 512). When the duration reaches 0, DSA switches its state to 14 and starts counting again... etc.

That would make torch usefull EXACTLY in 7580 ticks (actually 7680 ticks if we set state 1 duration to 512). want to change that to prevent cheating.

Or I see another method - without using DSA: can we force the engine to remember duration values somehow (*)? Now it remembers the only in which state the torch is, and a duration value is lost each time when the torch is taken away from hand.
(*) - the duration value could be assigned to the torch for example..

[Paul Stevens]

can we force the engine to remember duration values somehow

There is no such thing as "duration value" in the
current CSBwin. So I see no way to force the
engine to remember it.

CSBwin does something very simple: About
every 90 seconds it decrements the charge count
of all 'active' torches - torches in someone's hand.
I suggested that you override this behaviour by
using a DSA to examine each torch every two
seconds and setting the number of charges as
you think appropriate. This would avoid the
remote possibility that the player somehow
synchronize his play with that 90-second event
and place all his torches on the ground for a few
seconds while the update occurs.

I think that the brightness table is about 744 bytes
into graphic 0x232. I have never used any
graphics.dat editor and cannot tell you anything
else other than it is defined in CSBwin in file data.h
and is called "PaletteBrightness".

[Adamo]

oooh, I see!!!
The engine counts from the BEGINNING of the game, whether the party holds torch or not for all torches together- one to eight (I though the engine starts counting for each torch independently since it is in use).. that would explain my confusion about 412 ticks in state 1.. I need to remove the table above then, it`s totally incorrect.
So, when you will hold a torch with state 1 exactly in 510th tick of the game the light would last exactly 2 tick... need to test that.

EDIT: tested. In time= 510 I put torch in state 1 into char`s hand in dark area. The light last 2 ticks.

[Adamo]

ok, I`ve got two more ideas to avoid this (possible) cheat:

1) the DSA that prevents a player to remove the torch from its hand (it`s "stick" to the hand) since its totally burnt. That would definitely prevent the cheating

2) the DSA that decrements torch value by 1 every time the torch is removed from player`s hand. The engine still works in its own way (every 512 ticks decrement torch value, as it`s now), but every time when a player removes torch from char`s hand (extinguish the torch) it would ALSO cause a decrement.
Of course, I would have give a warning, that extinguishing a torch (removing from hand) decrements its usefulness a bit each time, so better not to play with that.

[Paul Stevens]

Those two ideas would work if you can
figure out a way to do them. I can't think
of any way.

[Adamo]

hmm.. would this be possible: "each time the party takes torch in its hands, the DSA substracts 1 from torch value (intensity)"...?

I know it means that torch with intensity= 15 would be never used.

[Zyx]

You'd need an "equip filter". CSBwin doesn't have one.
If Paul ever makes one, I would have uses for it too.

[Adamo]

the DSA that decrements torch value by 1 every time the torch is removed from player`s hand.

How about that:
The player put a torch into character`s hand. The DSA checks that torch:
- If the torch has value 15, then DSA replaces(*) it with object from, say, 0(0,0) cell, where lies torch with value 14.
- If the torch has value 14, then DSA replaces it with object from, say, 0(0,1) cell, where lies torch with value 13.
- If the torch has value 13, then DSA replaces it with object from, say, 0(0,3) cell, where lies torch with value 12.
- If the torch has value 12, then DSA replaces it with object from, say, 0(0,4) cell, where lies torch with value 11.
... etc....

(*)- by "replacing" I mean deleting the old object and putting a new object

This way torch value will be decremented by 1 each time the player put it in character`s hand (each use).

[Adamo]

You'd need an "equip filter". CSBwin doesn't have one.
If Paul ever makes one, I would have uses for it too.

I though it could be done without using filters by simply &DEL and &MOVE commands with sources: (char.1handL, char.1handR, char.2handL, char.2handR, char.3handL, char.3handR, char.4handL and char.4handR) and destination to the proper object (torch1, torch2, torch3 etc.).

EDIT: oh, ok, the engine wouldn`t know if something has been put into inventory, right?

[Paul Stevens]

Zyx: What do you want? A filter that
is activated with a SET 0 everytime an
object is placed in the cursor and a CLEAR 0
everytime an object is removed from the cursor?
Two different DSAs? One for PICK and one
for PUT?

The parameters would give some notion of
where the object was/is?

No promise . . but I could look into it.
And no changes by the filter, please. This would
be a notification only. You could probably fire off
another DSA to fiddle with the object.

[Zyx]

One Filter with S0 / C0 would be fine. And yes, knowing where the object was/is is essential.

No changes by the filter. OK. Got that. Sure. No problem.

...


Would "cancelling the action" be considered a change? (sticky objects, unpickable/forbidden objects)

[beowuuf]

Lol, did I ever show the 'freeze life' I made where the DSA cancelled your actions, retated you around to a fixed point, cancelled your spells and dropped any cursor-held items to the ground?

This would certainly allow for somehting much more elegant than the last solution!

[Adamo]

Originally, the engine modifies torches every 512 ticks. But I would like to modify that a bit (set my own duration) to 128 ticks.
I would like the DSA to multiply torch value by 128, every 16 ticks substract 16 and divide it by 128 to get the torch intensity.
16*128=2048

[Paul Stevens]

Try CSBwin10_010.exe and CSBuild253.exe.

Look at:
http://www.dianneandpaul.net/CSBwin/doc ... ilter.html

[Adamo]

thank you for implementing CursorFilter!
How properly written Cursor Filter DSA should look like?

The DSA receives six integers as parameters:

1. The objectID of the object being put into the cursor or taken from the cursor
2. A code telling what sort of transaction is taking place (see enum CURSORFILTER_TYPE below)
3. P1
4. P2
5. P3
6. P4

Is there a need to add &function that calls these parameters (&PARAM!) ?

L6 L0 &PARAM@

Could you provide a demo?

when the ScreamerSlice is eaten, the door is toggled. That would be DSA with parameters P1=172 (Screamer Slice ID), P2=8 ("CURSORFILTER_EAT" function), P3=0, P4=0, P5=0, P6=0 /unused in this case/ ..?
So, while eating, an object is removed from cursor. Should it be line C0 then?
Should call a line wchich sends a toggle message to a door..?

[Paul Stevens]

Hmmmm. The way I implemented it, we always
send a Set-0 message and you have to infer from
the 'transaction code' whether the object was added
or removed from the cursor. You and Zyx are the
only ones interested right now. If you both agree,
I will change it so that 'adds' send Set-0 and 'removes'
send a Clear-0.

I will make an example that toggles a door when a
screamer slice is eaten. Using the Cursor Filter
rather than the Feeding Filter.

[Zyx]

I think the S0/C0 messages would be redondants since the second parameter already tells the kind of operation. Anyway, I'm not against it.

But would it be possible to cancel the operation? Like you cannot pick/drop an item?

Also, I'm not sure about the meaning of
CURSORFILTER_ReadGame = 1

[Adamo]

it depends how much work would it require for you to modify the code. If much, there`s definitely no need to. If < 10 minutes, why not? I was just curious if the filter recieves CLEAR messages at all, because I experimented a bit with that filter and C0 line always gave no results, instead of S0. Even that I used to put the wrong code in S0, I`ve seen that it, more or less, works, though not necessarily in a way I wanted to.

[Paul Stevens]

But would it be possible to cancel the operation? Like you cannot pick/drop an item?

No changes by the filter. OK. Got that. Sure. No problem.

Well, I will look. Perhaps in some of the cases.
Certainly not all.

CURSORFILTER_ReadGame: This is what initializes
the cursor when the game is started or restarted.
You might use this to count how many times the
player has reloaded the game.

[Paul Stevens]

Try the:
http://www.dianneandpaul.net/CSBwin/Cur ... erDemo.zip

[Adamo]

thank you for the demo!

Code: Select all

0S0: L6 L0 &PARAM@ L0 &@ L2 &= ?JC0
0C0: L1 &@ L8 &= ?JT0
0T0: LA MT*

Strange: the filter recieves a SET message, so it should work many times (always start from 0S0 line), but it doesn`t. This DSA works oo (once only). The door is toggled once only - eating 2nd, 3rd, 4th etc apples doesn`t do anything. What should I change to force this DSA to work repeatadily?

[Paul Stevens]

It cannot work repeatedly as designed. There
is only one apple that will toggle the state of
the door. It is the bottom apple in the pile.
The other apples do nothing. If you want
another apple to work you could modify it as
follows:

Code: Select all

0S0: L6 L0 &PARAM@ L0 &@ L2 &= ?JC0 L0 &@ L3 &= ?JC0
0C0: L1 &@ L8 &= ?JT0 
0T0: LA MT*

Then the second apple from the bottom will also work.

Zyx: See new documentation for Cursor Filter
and get CSBwin10_012.exe.