Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Can you believe it?
Another few question to all you professional map-makers out there
Are extra2 links meant to work at all between switches? I'm presuming not since after noticing that they didn't, the pdf manual talks about them only working for when the sprite in question is 'picked up' or destroyed.
Force fields (and other triggers) is it possible to make a trigger into something by a means other than the name? I'd like to call my force field something else (or even "foo.Force Field") so as to allow switch deactivation to work. (unless someone knows a way to do this otherwise since as I mentioned above, extra2 doesn't seem to work?)
Is it possible to create mini timed sections of your map like the race-course and forest mini-games?
Is it possible to remove pickups from the player at a later stage? (I'm trying to work around the fact that the players can always use all colours of all the guns they have - e.g. I'd like to especially be able to control the colours of the wave gun - even if that means removing some colours once the player gets it).
Damage - is it possible to control how much damage is taken by impact with enemy sprites? It seems to be dependent on what sort of sprite it is from what I can see (or is it the AI?)
(Just a vague hope really thinking of AI's, rather than any real belief it exists but...) is it possible to get the editor to show the AI's in a sane order like e.g. alphabetically. I really couldn't care less what order their id's are - which I guess is what it is 'ordered' by.
Is it possible to 'resurrect' dead/removed sprites at all? Big levels get a little empty once you've blown everything up without having the leaving and re-entering the map trick the main game uses to (mostly) reset the level.
Thanks for all the answers. I'm guessing the answers are going to be no, no, no, nope, no, no and uhhh... no.
@crono, on Feb 6 2007, 04:35 PM, said in A few more editor questions:
They should, but they don't. May be fixed in a future version.
No, but I know that "Super Force Field2" is a valid name. It is possible that "Force Field2" will work, although I have not tested it.
I do not think so- from my tests of the Forest Race arrangement, the "race" code in the game uses the same timer as the "custom map timer" code. If you put in a minirace, it will activate the map's timer, even if the map is untimed , counting up. When the race ends, the timer will start counting down, witht he map ending when the timer reaches 0. This is definitely unintended behaviour, and should not be counted on to work in later versions.
No. Sorry.
It's the sprite (or, more generally, the Solid Type). Read my Sprite Guide (pinned, and linked to in my sig) for more information- there are a couple of sprites with variable damage.
Put it in the suggestions thread. It's been mentioned before, but it's a good idea.
That's going to be one of the nice points about saving- a save-reload should reset the enemies. As-is, your best bet is to hide extra enemies behind doors, and let them out when the player reaches checkpoints beyond them.
no, no, no, nope, no, no and uhhh... no.
Well, four and three halves out of seven ain't bad.
Edwards
Thanks for the replies - a few other comments here
@edwards, on Feb 6 2007, 11:56 PM, said in A few more editor questions:
Presumably putting in a minirace is a form of trigger? I didn't notice that documented anywhere - although your AI page did say most of the triggers were documented in the pdf, and hence some were not... A suggestion for the next version then.
Yup - I had read about that a few times before asking. In effect, I was wanting to make a non-wall sprite that enemy bullets passed over but yours did not - whilst still only doing the normal 1% damage when you impacted it. Unfortunately, that doesn't seem to be possible.
Incidentally, is there any way of making sprites which will block enemies but not the player? Th best I could come up with was the version that damages and vanishes a colliding enemy sprite - as opposed to something that just repels it.
Do you mean the suggestion for 1.0.1 topic? I got the impression that 1.0.1 was all but finished now with only critical bug fixes left to do - or are they still taking requests? Also that topic seems a bit long.
It might be useful to have a (maybe pinned) topic of suggestion for 1.0.2 (or whatever is coming after 1.0.1) and also a list of things which already have been fixed (or are definitely going to be) in the next release to stop duplicates.
That's true - although presumably we have to be a little careful about things which come back on re-load unless we accidentally leave the player trapped because a door resurrects when the player is on the wrong side of it! Is there a list of events that will and won't be remembered after load/save?
Thanks again
p.s. (out of curiosity) was the whole custom levels idea quite late on in development? I get the impression that there is far more hard-coded and locked to various sprites than would be if the game had originally intended to be (at least semi-) 'modular'.
@crono, on Feb 7 2007, 12:31 PM, said in A few more editor questions:
It is, it isn't, and nice catch on the "most". I put that in deliberately. However, I think that all the really useful ones are listed in the pdf.
As a matter of fact, I ran into a way of doing this entirely by accident a couple days ago, while attempt to find the "lets the player through, but blocks enemies" wall type (still absent. If anyone has any ideas on this, please post them).
Basically, through some strange interactions between sprite types, if you place a Player-type sprite in the same location as and slightly larger than a Solid-type sprite, and give the Player-type sprite an Extra1 of -1, all enemies, including shots, will be able to pass through the wall, but the player will not. This appear to be a completely unsupported feature, so use it with care, but hopefully it won't get "fixed". Do note that this allows passage to all enemies, not just shots.
Good idea. If any beta testers wish to go through the existing thread and pull out the suggestions that haven't been implemented, that would be nice. Otherwise, we'll need to wait until 1.0.1 actually comes out to know what has been changed.
I imagine it will use roughly the same system as the main game's saved game files, so any doors you open will stay open after a reload (possibly any named sprite will stay dead, and all Extra2 links that have been triggered will stay so? I have no idea how things are actually stored).
p.s. (out of curiosity) was the whole custom levels idea quite late on in development?
Yes. The editor itself wasn't added until more than half-way through the beta testing (about five/six months before release?).
This post has been edited by Edwards : 07 February 2007 - 03:16 PM
@crono, on Feb 7 2007, 08:31 PM, said in A few more editor questions:
It might be useful to have a (maybe pinned) topic of suggestion for 1.0.2 (or whatever is coming after 1.0.1) and also a list of things which already have been fixed (or are definitely going to be) in the next release to stop duplicates. That's true - although presumably we have to be a little careful about things which come back on re-load unless we accidentally leave the player trapped because a door resurrects when the player is on the wrong side of it! Is there a list of events that will and won't be remembered after load/save? Thanks again
A good idea, we'll see about the pinning, but I'd be willing to start / update it. Btw: There's a full list of the 1.0.1 features in the new package.
@edwards, on Feb 7 2007, 09:13 PM, said in A few more editor questions:
The editor itself wasn't added until more than half-way through the beta testing (about five/six months before release?).
Yeah, maybe even a bit later.
@freq245, on Feb 7 2007, 01:35 PM, said in A few more editor questions:
What new package now?
Re: lateness of addition of custom levels: that explains a lot, actually. My hope is that they take the idea and really run with it, even though the product is already released. We'll see some of that in the form of the new save feature, but that's one that doesn't break forward compatibility. Will we see truly new features that do?
Because make no mistake, a lot of these things we're suggesting would make it so maps created with the newest version that used the new features would not play on the old. IMHO, this is not a bad thing; computer software is only rarely forwards compatible, and users don't really expect it to be most of the time.
My biggest wish for such a feature? A switch, trigger, or pickup that activates something instead of strictly deactivating. Think of the crazy awesome tricks you could pull with that...
This post has been edited by cheleball : 07 February 2007 - 04:02 PM
@cheleball, on Feb 7 2007, 10:01 PM, said in A few more editor questions:
I just meant the 1.0.1 folder.
Gaah! To much stuff to reply to! But I'll try...
@crono, on Feb 7 2007, 12:35 AM, said in A few more editor questions:
-snip-
Yes, some trigger names are not documented... intentionally. Everything useful for a custom level is documented. I'm sorry I don't know any answer to "is there a thing that can let this and that through but not this", ask Edwards who is slightly more likely to have an answer. The suggestion topic is still very open to use, just they will be implemented in a version later than 1.0.1 if ever. Though, just like bugs, we'll probably restart from scratch in a new topic when 1.0.1 is released (AFAIK every bug mentioned in the bug topic is fixed for 1.0.1, I've tested for some of them myself).
Custom levels indeed appeared on request from us beta testers (be glad!) a few months after the beta began, and I cannot count the number of times the explanation for a bug in custom levels was "Oh, yeah, that comes from a time I was the only one to use the editor, you need to..." or "Oh, that was never really intended to be done, I'll fix it so that it behaves better"; this game is not like EVs in that respect. In fact an issue Edwards reported to me recently (and that you can see if you open his One Page template in the editor) is that shadow corners are not placed the same way in-game and in the editor, and we investigated and it's because the rotation center position is hardcoded in the game while the editor uses the LMSprite data, and it turns out the reason for this is that Lars never placed them in a level, but these are only placed at runtime by code, and he needed to make sure they were placed with superior accuracy (to avoid both overlap and holes, both of which are easily spotted with non 100% opaque sprites) so he resorted to hardcode a few things about them (aargh!), but he fixed the editor so that it's hardcoded in it the same way too (and one more thing I'll have to hardcode in SketchMapMerge... sigh...) so that the editor is WYSIWYG for this sprite too.
We'll tell which suggestions have actually been implemented in 1.0.1 when it will actually be out, because we don't want to post a list that will end up being inaccurate. So I guess you could find out yourselves...
The matter of what will come back and how after restarting from a save point after dying (oh btw, sorry to disappoint you, but saving in custom level will only be in a single session, you can't save in a file to go away and play some other way, and reload your save later) is a very good one, in fact FireFalcon's Level.SketchMap has an issue in that respect: if you disable the turrets using the switch intended for that purpose, save, die, and come back from the save point, the turrets will stay disabled but the wall with explosives that can only be triggered by enemy fire will be back, and you'll end up being blocked! Basically, when remains dead/removed is the Boss if any, the MiniBoss if any, any switch and its effects, any pickup, and any Extra2 effect. I'll have to ask Lars for the actual details on how this is done because it may not necessarily be that simple.
Well, I shall wait and bide my time (though as mentioned in the other thread, am more than willing to lend a hand, rather than just sit and whine about missing features)
Regarding map compatibility - the map file ought to be version'd in its XML header - and each SFA codebase knows the largest major version that it will open. Assuming updates are free, if it sees a map in the custom folder with a version number higher than its hard-coded default, then it simply disallows it. Preferably it also prompts the user to go to Ambrosia's site for an update
That way you can safely make completely incompataible changes to the way the level is stored (like for example adding 9 or 10 extra's to sprites for holding things like
- rotation offsets, - flags for weapons that won't hurt it rather than just those that do, - damage on impact - multiple AI scripts
... the list is endless, the possibilities boundless ... and it belongs in another thread...
Then the game engine is updated along with it to take into account these extras, and be able to render each different map form. (alternatively, and much more simply for the main game code, the editor which ships with the game can be used to 'upgrade' the map from one storage format to the next so users can keep playing older maps.) That way Lars only has to deal with the 'current' most recent map format in each rev of the main code.
But I digress <_<
I am a little worried about the concept of only 'session saving' though. It does sound quite cute, but could be tedious for large levels that you cannot quit SFA in the mean-time, and equally tedious about having to curtail the location of save points so as not to accidentally lock the player out of somewhere.
Oh well... we shall see...
Edit: p.s. I'm very glad to hear that the beta testers got the custom level editor added. I for one would have been very disappointed to have beaten the game as quickly as I did after registering if that had been it - and would have felt it didn't really justify more than a $10 top price tag. I'm sure many others would have been too.
This post has been edited by Crono : 07 February 2007 - 05:29 PM
@zacha-pedro, on Feb 7 2007, 02:32 PM, said in A few more editor questions:
Deactivating force fields by Extra2 works, so use that instead.
At least, that will be the case once 1.0.1 comes out, since as you say, Extra2 links don't work with switches currently. Now, it would be nice to be able to link force fields to bosses or moving blocks, but I'll file that with "children rotate around center of parent sprite" on the list of requested features.
Yes, some trigger names are not documented... intentionally.
Given that my list of warnings ended up as long as the basic descriptions for the Race trigger sets, I'm forced to agree.
I'm sorry I don't know any answer to "is there a thing that can let this and that through but not this", ask Edwards who is slightly more likely to have an answer.
The best I've come up with so far is a carefully-calibrated parent-child link that will make a wall appear behind you when you get to the side of it nearest the parent, and vanish when you get close to it again from that side.
(oh btw, sorry to disappoint you, but saving in custom level will only be in a single session, you can't save in a file to go away and play some other way, and reload your save later)
That's about what I expected. Does the save stick around when you exit the custom level but don't quit the game? Also, do custom levels keep track of the shots fired and deaths the way the main game does?
@crono, on Feb 7 2007, 03:26 PM, said in A few more editor questions:
Regarding map compatibility - the map file ought to be version'd in its XML header...
They already are, and I'm pretty sure I accidentally triggered a "this file is from a higher version" warning once.
...and equally tedious about having to curtail the location of save points so as not to accidentally lock the player out of somewhere.
What exactly do you mean by that?
@edwards, on Feb 8 2007, 01:20 AM, said in A few more editor questions:
Does the save stick around when you exit the custom level but don't quit the game? Also, do custom levels keep track of the shots fired and deaths the way the main game does?
No, it doesn't, for both questions.
Custom levels are indeed versioned (just not in the XML header since that's out of SF4kA control, since SketchMaps are actually plists, and the plist format itself hasn't changed), just check out the "Format version" key... But any forward-incompatible change (I can never remeber which way is forward and which way is backward...) will be for a later version if ever; also notice that the main levels are run (almost) the same way as the custom levels and have the same format (modulo a few wrappers).
Hmm... One undocumented trigger name you could concievably use is "Boss Warning", which does just what you think it does (it's the one just before the Wasteland Boss in the main game).
@zacha-pedro, on Feb 8 2007, 12:49 PM, said in A few more editor questions:
I've noticed people discovering a lot of triggers that are not mentioned in the editor manual (The race Start for example). Will the manual be updated for 1.0.1?
@edwards, on Feb 8 2007, 12:20 AM, said in A few more editor questions:
I mean that since I have more than a few 'doors' which don't actually use the normal door sprites and are type 'enemy' rather than 'solid', but are triggered by switches or extra2 links. If I were to put a save point on the far side of one of these. It might be possible that they 'resurrect' on re-load of the save leaving the player forever trapped on the far side of it.
Hence it is important to know which sprites will and which won't come back after the map is re-laoded.