I'm releasing the BOF compiler (Redstone) in the state it is now, because I'm getting demotivated. The archive includes the most recent versions of each tool, and a grammar summary for the Redstone language. The major changes are:
- The inclusion of the compiler in bofmake
- bofmake now only processes files ending in .bc (for assembly with the assembler you've been using) and .red (for compilation with the new compiler).
- bofmake does not recursively traverse subdirectories when looking for source files.
- "this" is now "self".
- bofmake now only generates one .rsc file for the server resources, which is identical to the .rsb file generated for the client.
I didn't finish with pattern matching.
It would be inconvenient if, in order for you to use the new compiler to make changes to a disassembled class, you had to rewrite all the code in the class in the Redstone high-level language - even in messages which you don't wish to modify. Therefore, I have provided a facility that allows you to rewrite bytecode one message at a time. In a .bc (bytecode) file, the statement compile {CODE} causes the assembler to invoke the compiler to process the text CODE. CODE should contain a single Redstone-style message definition. This is in some sense the opposite of inline assembly
There is a problem in the blakston.khd everyone has been using: several constants are defined in terms of others using operations such as / (division). The Renaissance server ignores these operations completely, and simply takes the first term of the operation as the final value. I have replaced the bad constants in blakston.khd with the correct values (by just manually evaluating the problematic expressions). That file is also included.
Because Redstone allows you to reference admin constants, a new line must be added to project.txt: "constants:". This specifies the filename of the constants file. A sample project.txt is also included.
Those looking for information on the assembler and Renaissance interpreter, try here http://forum.ragezone.com/f203/bof-tools-testing-238897.
Finally, some examples... nest1.red:
A1.bc (note that use of compile to have the compiler process the Constructed message):
As before feel free to ask questions, especially since the documentation is quite lacking.
- The inclusion of the compiler in bofmake
- bofmake now only processes files ending in .bc (for assembly with the assembler you've been using) and .red (for compilation with the new compiler).
- bofmake does not recursively traverse subdirectories when looking for source files.
- "this" is now "self".
- bofmake now only generates one .rsc file for the server resources, which is identical to the .rsb file generated for the client.
I didn't finish with pattern matching.
It would be inconvenient if, in order for you to use the new compiler to make changes to a disassembled class, you had to rewrite all the code in the class in the Redstone high-level language - even in messages which you don't wish to modify. Therefore, I have provided a facility that allows you to rewrite bytecode one message at a time. In a .bc (bytecode) file, the statement compile {CODE} causes the assembler to invoke the compiler to process the text CODE. CODE should contain a single Redstone-style message definition. This is in some sense the opposite of inline assembly
There is a problem in the blakston.khd everyone has been using: several constants are defined in terms of others using operations such as / (division). The Renaissance server ignores these operations completely, and simply takes the first term of the operation as the final value. I have replaced the bad constants in blakston.khd with the correct values (by just manually evaluating the problematic expressions). That file is also included.
Because Redstone allows you to reference admin constants, a new line must be added to project.txt: "constants:". This specifies the filename of the constants file. A sample project.txt is also included.
Those looking for information on the assembler and Renaissance interpreter, try here http://forum.ragezone.com/f203/bof-tools-testing-238897.
Finally, some examples... nest1.red:
Code:
requires monsroom
class SpiderNest1 : MonsterRoom
static vrName = res room_name_nest1
static viTeleport_row = 32
static viTeleport_col = 7
static viTerrain_type = TERRAIN_CAVES | TERRAIN_LAIR
private prRoom = res room_nest1
private piRoom_num = RID_NEST1
private prMusic = res nest1_music
private piBaseLight = 124
private prBackground = res background_mountains
private piMonster_Count_Max = 10
private piGen_time = 20000
private piGen_percent = 60
private ptQueen_gen = nil
// This is a comment.
message Delete =
if ptQueen_gen <> nil then
(delete_timer(ptQueen_gen);
ptQueen_gen := nil);
continue
message SomethingMoved(what = nil, new_row = nil, new_col = nil) =
if new_row = 26 and new_col = 16 then
(SYS.UtilGoNearSquare(what = what, where = SYS.FindRoomByNum(num = RID_CAVE2),
new_row = 53, new_col = 14, new_angle = what.GetAngle, fine_row = 16, fine_col = 16);
what.MsgSendUser(message_rsc = res Nest_to_Cave_2);
return nil);
if new_row = 2 and new_col = 19 then
(SYS.UtilGoNearSquare(what = what, where = SYS.FindRoomByNum(num = RID_CAVE2),
new_row = 50, new_col = 25, new_angle = what.GetAngle);
what.MsgSendUser(message_rsc = res Nest_to_Cave_1);
return nil);
continue
message Constructed =
plMonsters := [[class SpiderBaby, 80], [class Spider, 20]];
plGenerators := [
[ 8, 22], [27, 22], [22, 19], [19, 20],
[31, 15], [36, 11], [30, 2], [35, 19],
[19, 25], [15, 24], [24, 8], [23, 2],
[ 4, 13], [15, 16], [ 2, 12], [13, 5],
[ 9, 15], [ 5, 11], [17, 5], [20, 8],
[28, 12], [35, 16], [25, 24], [31, 10],
[34, 7], [ 4, 23]];
self.QueenGenTimer;
continue
message QueenGenTimer =
ptQueen_gen := nil;
queen_alive := FALSE;
for each object in plActive do
if self.HolderExtractObject(data = object) : SpiderQueen then
(queen_alive := TRUE; break);
if not queen_alive then
self.NewHold(what = new SpiderQueen, new_row = 21, new_col = 15);
ptQueen_gen := make_timer(self, QueenGenTimer, 3600000);
nilA1.bc (note that use of compile to have the compiler process the Constructed message):
Code:
requires feyforst
class OutdoorsA1 : FeyForest
static vrName = res room_name_OutdoorsA1
static viTeleport_row = 32
static viTeleport_col = 32
private prRoom = res room_OutdoorsA1
private prMusic = res OutdoorsA1_music
private piRoom_num = 511
private piGen_time = 150000
message CreateStandardObjects, 1 local
new class FeyTree, #local0
send self, msg NewHold, [what = #local0, new_row = 43, new_col = 26]
new class FeyTree, #local0
send self, msg NewHold, [what = #local0, new_row = 45, new_col = 24]
new class FeyTree, #local0
send self, msg NewHold, [what = #local0, new_row = 47, new_col = 31]
new class FeyTree, #local0
send self, msg NewHold, [what = #local0, new_row = 21, new_col = 46]
new class FeyTree, #local0
send self, msg NewHold, [what = #local0, new_row = 24, new_col = 42]
new class FeyTree, #local0
send self, msg NewHold, [what = #local0, new_row = 37, new_col = 42]
new class FeyTree, #local0
send self, msg NewHold, [what = #local0, new_row = 37, new_col = 36]
cont
compile {message Constructed =
// Blah!
plGenerators := [[11, 32], [16, 15]];
continue}
message CreateStandardExits, 1 local
mov nil, plEdge_Exits
list 4, 531, 6, 1, 8, #local0
cons #local0, plEdge_Exits, plEdge_Exits
contAs before feel free to ask questions, especially since the documentation is quite lacking.
