![[de]](/mwf/flags/de.png "Germany")
I tweaked the TeleGlove to add a small feature: If "debug" is set via SetDebug(true), its range is not any more limited. Also, I fixed a minor bug that caused every object manipulated by the glove to get his mass permanently halved, resulting in less damage when hitting a Clonk.
To the less Code-savyy players:
Do FindObject(Find_ID(TeleGlove))->SetDebug(true) and if theres only one TeleGlove on the map, its range limit is lifted!
I plan to maybe expand the features of the Debug Mode of the teleglove to compensate for HUD elements clogging up the Editor mode games so that you cant access any important objects easily.
Lets see if I can find out how to append my patch...
I hereby license the following file(s) under the CC-by license
To the less Code-savyy players:
Do FindObject(Find_ID(TeleGlove))->SetDebug(true) and if theres only one TeleGlove on the map, its range limit is lifted!
I plan to maybe expand the features of the Debug Mode of the teleglove to compensate for HUD elements clogging up the Editor mode games so that you cant access any important objects easily.
Lets see if I can find out how to append my patch...
I hereby license the following file(s) under the CC-by license
Attachment: TeleGloveTweak - Fix of a minor bug and adding of a script-activated range lifter for the teleglove (2k)
![[ca]](/mwf/flags/ca.png "Canada")
Sounds like a neat tool for messing with objects in debug mode. A whole range of debug specific tools that appear on the HUD may be interesting (object positioning/rotation, landscape modification tools). Though of course there are more important things at the moment.
But debugging tools should not depend on the loaded objects. If there is the need to have a selection tool that only moves objects (and not Clouds and other HUD elements), why not implement that for the dev mode itself?
Then it would not depend on the player having crew, carrying objects and having the game in non-pause mode.
![[ie]](/mwf/flags/ie.png "Ireland")
I think Caesar(?) already began working on something to prevent this debug glove from getting into the repos.
Began is the right way to put it... That code would OS-dependant and a mixture of gui-code and access to properies and FindObject. Oh, and my semester tests are round the corner...
I know, the pros would do it in no time.
I know, the pros would do it in no time.
By not accepting it? Sounds like a whole lot of work to me.
What's wrong with scripted scenario development helpers? Back in the newbie days, many Clonk players created scenarios by "playing" on an empty map, then saving the scenario. It's a fun way to develop :)
But we already have the edit cursor which is far more powerful. I don't think many people would use this debug glove but rather network hosts exploiting it.
>but rather network hosts exploiting it
Wouldn't that be awesome?
Nothing against a whole "sandbox" environment with something like the old CR cheatclonks that could spawn stuff out of nowhere.But then that should be targeted to the normal player who would not be able to do a "FindObject(..)->SetDebug()"
PS:
Thinking about that..
With the right toolset (spawnpoint spawners / start item selectors / respawn settings) that would be a pretty cool way for new players (not developers!) to create own scenarios to show off.
Like a WYSIWYG editor for players.
We need a way for scripted stuff to affect the world while that is paused.
And a way of pausing that ignores that stuff.
...a pause that gets some priority number, which pauses all objects/effects/timers that have a lower pause-surpassing priority than the pause.
And a way of pausing that ignores that stuff.
...a pause that gets some priority number, which pauses all objects/effects/timers that have a lower pause-surpassing priority than the pause.
I understand the idea, but I think this will get ugly really fast.For my CR tower scenario development (it's done soon; next project will be for OC!), I have the guideline that every room should be in a stable state when it is running unpaused without players. Animals may hop, run and swim around, water may flow etc. But anything that is destructive (such as T-Flint chain reactions as part of riddles) should be started by script that is triggered by player join. I think this guideline works really well. If people develop "pause mode" scenario, they run into all kinds of problems. Objects aren't probably aligned to the ground; they fall a few pixels when the game is started. Object orders are sometimes messed up.Animals are stuck and they don't notice. They cannot test if doors work because they cannot unpause. Etc.
Developing in running mode is always a good test if your stuff really works, so that way of development should be encouraged.
Well, but animals can get stuck if you save and load cause the landscape my differ. Because of that it is often advisable to move the Animals um into the air bevor saving. Especially if the animals live in small caves with lots of rock, which gets chunky random.
![[at]](/mwf/flags/at.png "Austria")
Sounds more like an engine than script problem.Maybe it's possible to save the seed used for landscape-generation, to re-generate it? Or are you talking about dynamic scenarios in general?
No just about the Random for a fixed map, MapZoom introduced. Sven2 once said that if we would use the same seed every time it wouldn't be that save to changes to the landscapegenerator. But perhaps one could argue about that.He said you should be able to pass tunnels in a sczen at every seed, cause a change in the genarator could result in a different random too and could make the tunnel unpassable every time you load the szen.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
