Editing core aspects of the game

[RegisCastus]

Now on more complex ideas that I've been curious about:
New classes/Stats when leveling.
Starting at different levels (perhaps based on which class you pick)
New "Game Over" graphic
Is it possible to have the game Auto-Load back at the last save point after the player dies? Hardly necessary, but I'm curious if it's doable.

[mahric]

Now on more complex ideas that I've been curious about:
New classes/Stats when leveling.
Starting at different levels (perhaps based on which class you pick)
New "Game Over" graphic
Is it possible to have the game Auto-Load back at the last save point after the player dies? Hardly necessary, but I'm curious if it's doable.

I've been thinking about these and with my knowledge it's going to be very very tough to so most things, if not impossible.

1) New classes are hard-coded and changes are not possible as far as I know
2) Starting at different level: technically everyone starts at the same point, but you can make a pressure plate that executes script, looks at the class, sets a teleporter destination and activates the teleporter. That way you still have the result you want.
3) A new game over graphic would be impossible since it's build in the game. The only thing you might try (but really isn't worth it imo) is to fiddle with the onDie() function, transport the party to another level with a transparant tileset (so everything is black) and make some custom tiles with your new game over graphic. But personally I don't think it's worth it.
4) Auto load is not possible either, but if you are going to implement the previous point, you might as well teleport your party back to the last checkpoint. No clue how you're going to reset their skillpoints and inventory though.

[Komag]

I think he doesn't mean dungeon level, but character level, which you could have increase based on class I suppose, but since you can't make custom classes yet it wouldn't make a whole lot of sense right now. And you don't need a pressure plate, just a script outside a function that will run on map start.

Other than that, I would pretty much second everything that was said.

[JohnWordsworth]

Just out of curiousity, if you have a script entity with a script in (no functions), does it...

(a) Do nothing,
(b) Run the first time you start the dungeon with a party,
(c) Run everytime you start/load a save game in that dungeon?

From what you said @Komag, I'm assuming not (a), but would you need to do something like the following to catch it from running more than once?

SpoilerShow

Code: Select all

if ( runOnce == nil ) then
  // Do Something
  runOnce = true;
end

[mahric]

Just out of curiousity, if you have a script entity with a script in (no functions), does it...

(a) Do nothing,
(b) Run the first time you start the dungeon with a party,
(c) Run everytime you start/load a save game in that dungeon?

From what you said @Komag, I'm assuming not (a), but would you need to do something like the following to catch it from running more than once?

SpoilerShow

Code: Select all

if ( runOnce == nil ) then
  // Do Something
  runOnce = true;
end

A quick test reveals that it's only once, at the start of the dungeon. So if you want to keep any information, be sure to store it in things that get saved in games (like counters)

[Xanathar]

As far as I tested, if you put script in a scripting entity but outside of functions:

It's run once, at dungeon initialization, in the game. In the editor it's run everytime you press "play" from a stop state.

It can safely access its own scripting entity, it can see that other entities exist, but it cannot call functions or read data of other scripting entities as, predictably, the order of initialization is not guaranteed. Probably if you play with the levels the entities are on, you can get a reliable behaviour, but I wouldn't trust it unless it is the only solution to a problem.

So, to contribute to the pressure-plate vs. free-code debate: the pressure plate solution has the advantage that it's not run everytime in the editor (if you place your start point elsewhere) and it can freely access other scripting entities. The free code has the advantage that it's run everytime also in the editor (it depends on what your code does if this is an advantage or not so I put it in both ).

As a side note, I tried to play with scripting_entity:setSource method, and it seems that the Lua code is parsed "some time after" the call (probably the next frame or something), so it couldn't be used to generate code on the fly and execute it (at least, not immediately). BTW it's not documented so it's probably not safe to use anyway

[Komag]

It can safely access its own scripting entity, it can see that other entities exist, but it cannot call functions or read data of other scripting entities as, predictably, the order of initialization is not guaranteed. Probably if you play with the levels the entities are on, you can get a reliable behaviour, but I wouldn't trust it unless it is the only solution to a problem.

This I did not know. I'll have to check through my stuff and make sure I'm not relying on anything in this way, but I don't think I am. Most if not all of my non-function code is just setting variables, such as "bigTrapDoorOpen = 0" so that at map start all those variables are defined (throughout many different script entities, right next to the functions that use them later on).