Tremulous Forum
General => Feedback => Topic started by: vcxzet on December 10, 2006, 03:55:19 pm
-
I badly want to save my great base layout and load it
edit:
::IDEA::
it is really boring to play the same map with the same base layout all the time
but if you had base layouts saved you could load a different base layouts for the same map
which means different strategies for the same map each time it is loaded
-
I badly want you to stop spamming.
-
I badly want you to stop spamming.
damn this is no spam I want to save my base layout I dont want hardcoded layout in map anymore
sigh
stop flaming ppl
-
Vcxzet, normally your posts aren't so crappy, but lately, you have been a troll.
-
Vcxzet, normally your posts aren't so crappy, but always, you have been a troll.
fixed
-
Is it trolling to want a new feature in the feedback forum?
I am just requesting that feature
I call trolling what you are doing right now.
You are not doing anything useful for tremulous by calling me troll
you are wellcome to say my idea sucks but you just say troll troll blah blah
should I create a new account request new features from that account?
...
what is wrong with you
AND I STILL THINK SAVING BASE LAYOUT WOULD BE COOL
-
... for use in actual games? (instant building a whole base is bad)
Load it into what/why?
Don't really get this idea atm.. please elucidate.
-
it is really boring to play the same map with the same base layout all the time
but if you had base layouts saved you could load a different base layouts for the same map
which means different strategies for the same map each time it is loaded
-
Ah.. so you mean when the map loads it can load with a specific layout... might confuse the hell out of some people but I don't really see any problem with it as long as it happens at load, and not after.. sounds good to me :D!
-
Calm down people, this is not a troll thread!
Think about it - would it not make the game more interesting if each map could start with one of several "default bases" instead of always starting with the same hardcoded one every time? Wouldn't it make the debugging of building bugs easier if you could save the buildables layout? I like the idea, different servers could have their own sets of starting base locations, and the game could come with a set of example layouts of good bases as part of a building tutorial, etc.
-
Anyone here play Castles: Siege & Conquest? It's an old game published by Interplay in 1994. Anyway, in that game, you compete to be king of Bretagne. You can build castles on the different territories you capture. You can save your castle layouts to reuse for different territories if you are bored out of your mind of making a new castle for each of your territories.
I think for Tremulous it would make more sense to draw blueprints (so you know where to place things) than to actually start with the same base, otherwise it would just become like a saved game.
-
+1
one thing than bothers me is some geniuses from some servers for noobs (letter S comes to mind) making 1000BP fortresses load at the start. But its not like I play there anyway :)
It could even be a simple text file
-
I don't know about saving base layouts...
But I am definitely behind the idea of having more than 1 default base.
It definitely would mix gameplay up a bit and make it a hell of a lot more interesting.
-
Yes, this would make it exciting.
A number of random base locations at starting a map.
"Oh dear, seems the alien and human team started right next to each others!"
...
interesting.
-
Yes, this would make it exciting.
A number of random base locations at starting a map.
"Oh dear, seems the alien and human team started right next to each others!"
...
interesting.
or due to a bug they start in the same room.
The random starting base idea would be fun to try out.
-
you will form two bases and save the layout
it is easy to save and load
I dont see a reason for a bug
they cant start near to eachother if the one that saved the layout did not form them next to eachother
-
vcxzet look into the code what and where defines buildables placements at the beggining of the map
-
The two question on any feedback post:
1. Is it feasible to code?
I hope so.
2. Is it worth adding as far as game-play concerns go?
Yes it is.
-
This would be an interesting designated builder ability (otherwise, you'll have 3 different people trying to use 4 different layouts -- unless they are chosen randomly at map start).
-
This would be an interesting designated builder ability (otherwise, you'll have 3 different people trying to use 4 different layouts -- unless they are chosen randomly at map start).
I see it as a set of premade layouts that MAPPER puts in the pk3 with the map, then server op can randomize/loop/set favourite layouts to kick in on every map load. Nothing to do with ckit users in the game. That way you could use current maps with new (fun/risky/surprising) layouts, and make new ones with multi base locations in mind. With /loadblueprint and /saveblueprint server ops could use custom layouts made by anybody.
wait, got another idea, commands:
/saveblueprint:
Ability for a player to save own layouts locally. Lets call them blueprints. You build the base you like (or see the one you like in a game), go to console and to /saveblueprint myshittybase, do another base and do /saveblueprint myothershittybase.
Now you have two files in your /base folder called myshittybase and myothershittybase. Files should be pure text for easy editing in text editor (to shuffle buildings order, you could use one blueprint for 100BP and 200BP server, server would just ignore the rest of the list after counting to currentBP), server would of course validate coordinates (just like it validates when you build).
/loadblueprint:
available ONLY in /devmap mode, it would just load up the blueprint and place buildables accordingly. This way you could edit and fine tune your base layout. Just open console, devmp the mpa you like, then "/loadblueprint myshittybase" and you got whole base build. This command could be used by the server on every map load to load custop blueprints (reused code:P).
/hudblueprint:
Now this is hot. You bind for example
bind F6 "/hudblueprint myshittybase"
bind F7 "/hudblueprint myothershittybase"
you press F6 in the game and every time you get a granger/ckit you can see blue building shadows (you know, that stuff you see when placing buildable), now aiming ckit at one of those shadows and pressing LMB would build that particular structure (if you got BPs available). Basically it loads blueprint to an active buffer. You can see this buffer every time you are a builder.
/copyblueprint:
Collaboration - every other player could just look at you (point his crosshair at you and press a magic button with binded /showblueprint) to see your layout on the map, every granger/ckit could press his bind for /copyblueprint to copy your blueprint to his active buffer. This would make possible for few builders to build ONE base and for other players to see what you want to build and say "i like it"/"get the F outa here" or just know what to expect from you.
/showblueprint:
mentioned above.
5 commands to implement, first two need file parser for loading/saving buildable entities to a blueprinttable, /hudblueprint code for displaying that blueprinttable content + ability to build shit you aim at, /showblueprint could use simple "/m nick message" to send blueprint to asking player since blueprint is an ordinary text. /copyblueprint just copies from temporary blueprinttable to the actual blueprinttable.
Do you follow my drift? Anyone up for a fight with this? I can code it if someone decides to help me.
and BTW vcxzet, for all the trolling and spamming you do (even I do less :P) this IDEA makes me repent all your sins :). Making base layous independent from the map is a suggestion of the year imo!
-
I think this is a very good idea. Certain base spots, like lamer spot on Niveus or slow door at karith, shouldn't be default spots though, you should still have to move there.
Another idea: reactor and OM are each placed on a completely random place in the map. :P
-
vcxzet look into the code what and where defines buildables placements at the beggining of the map
src/renderer/tr_bsp.c
R_LoadEntities
But its a magic to me :(
-
vcxzet look into the code what and where defines buildables placements at the beggining of the map
src/renderer/tr_bsp.c
R_LoadEntities
But its a magic to me :(
not that far
-
vcxzet look into the code what and where defines buildables placements at the beggining of the map
src/renderer/tr_bsp.c
R_LoadEntities
But its a magic to me :(
not that far
not that far WHAT?
-
Hi 8)
-
vcxzet look into the code what and where defines buildables placements at the beggining of the map
src/renderer/tr_bsp.c
R_LoadEntities
But its a magic to me :(
not that far
not that far WHAT?
/renderer is just the visualization part It is related with /game . /game adds behavior to entities (g_spawn.c maybe I didnt have the time )
-
vcxzet look into the code what and where defines buildables placements at the beggining of the map
src/renderer/tr_bsp.c
R_LoadEntities
But its a magic to me :(
not that far
not that far WHAT?
/renderer is just the visualization part It is related with /game . /game adds behavior to entities (g_spawn.c maybe I didnt have the time )
not in Q3, renderer is the game engine, it loads bsp tree and stuff, and manages it, game/cgame/ui are only talking to the renderer and manipulate rendered world, anyway this is the only place I found that loads stuff from the bsp file, and since there is no file for base layout in pk3 it must be in the bsp. Someone who knows how this works could really speak up now :) please :P
-
so I change renderer code to make new entities for my mod :P
-
blah, i commented out that function and the game runs like nothing happened, loads base and everything, SHIT :)
-
If you're going to make it, I'll be happy. :)
But I don't understand one thing: do you want multiple default base spots, from which one would be picked at random (as in Gloom, I think), saving of blueprints for base(es) at your computer, saving the blueprints server-side by admins or what?
As far as I'm concerned, all of these have some merit in them.
I'm in favor of saving your personal blueprints, having random bases, and server side foolproof tested blueprints - all at once. :D
And one more thing: while you apparenly figured out a way of technically managing them, how would they load? Server side mod, or is it going too deep for it?
And how would you see blueprints ingame, like ghost-buildings in specific spots?
All around, I think it is a brilliant idea, especially with all those lame builders around.
-
If you're going to make it, I'll be happy. :)
I will If someone who knows how managing entities works :)
But I don't understand one thing: do you want multiple default base spots, from which one would be picked at random (as in Gloom, I think), saving of blueprints for base(es) at your computer, saving the blueprints server-side by admins or what?
all of this :)
And one more thing: while you apparenly figured out a way of technically managing them, how would they load? Server side mod, or is it going too deep for it?
First part of my post is basically vcxzet idea rephraset for the masses :)
The second one came to me when I sat for a while and thought about the possibilities of external layouts.
First part can be absolutelly server side, and if coded today you could play it tomorrow with current clients. Server would just load the map, delete default buildables and load custom/random/favourite layout from the text file.
The second one needs deep patching of the client code.
And how would you see blueprints ingame, like ghost-buildings in specific spots?
exactly, but with different color and more transparent to not confuse ppl. You toggle display of the current loaded "blueprint buffer" with a key/bind, peek other peoples current loaded "blueprint buffer" with another key/bind, and copy with another.
That would enable for example a team leader, or main builder to show other players how he wants his base build without typing in the chat every position. Imagine 2 ppl, one loads different blueprints, the second one just aims at him and presses /showblueprint, then looks arround at the ghost buildables and says "its shit, show me another one", after the third one he says "this is pure gold, do it" :).
Fast building when clicling on the blueprint ghost is the wet dream of every anal builder, imagine NO MORE 10 second fitting armory in that very special place you like :) just load your blueprint, aim at the ghost image of the armory and press LMB, Done! its building :).
All around, I think it is a brilliant idea, especially with all those lame builders around.
/me too, now all we need is a trem hacker who knows enough about entities.
-
Also, when a building is destroyed, how about it automatically add a blueprint there, so you can rebuild fast? You can just delete it if you don't want it.
Also, a pro builder can load a blueprint and some noob and build the base, while the pro goes killing.
Also, it would be cool to be able to name building, so you could number build order, or mark important bit, or stuff that looks stupid at first, but is really a good idea.
EDIT:
Can we get a dev's views on this?
Its obviously going to be a lot of work, and there is no point if it never gets added to the next version.
-
A lot of work, but it looks like an awesome feature.
-
in g_main.c
in func
G_InitGame
// parse the key/value pairs and spawn gentities
G_SpawnEntitiesFromString( );
-
in g_main.c
in func
G_InitGame
// parse the key/value pairs and spawn gentities
G_SpawnEntitiesFromString( );
jackpot
-
qboolean G_ParseSpawnVars( void )
in g_spawn.c
maybe if you parse a file in that function rather than the ones in the map
hmmm I have to try
first I need to save the layout in a format that function recognize
G_ParseSpawnVars
Parses a brace bounded set of key / value pairs out of the
level's entity strings into level.spawnVars[]
This does not actually spawn an entity.
-
Also, when a building is destroyed, how about it automatically add a blueprint there, so you can rebuild fast? You can just delete it if you don't want it.
just after building base player could press bind for /copyblueprint NOT aiming any players, so now this players buffer would contain current base, so after the attack he would see what is missing to rebuild.
Also, a pro builder can load a blueprint and some noob and build the base, while the pro goes killing.
yes, but the noob would have to press /showblueprint and then /copyblueprint to make the pro builder blueprint his own active. Forcing own blueprints on other players is a big NO NO imo.
Also, it would be cool to be able to name building, so you could number build order, or mark important bit, or stuff that looks stupid at first, but is really a good idea.
would be handy, but im affraid that too much information could be also a bad thing, hmm maybe toggleable like tutorial mode, yep that could work.
EDIT:
Can we get a dev's views on this?
Its obviously going to be a lot of work, and there is no point if it never gets added to the next version.
Ill PM some devs.
bzz bzz PMs send to Timbo Norfenstein ERR:OverFlow dolby
jackpot, i was toying with the code an hour ago and noticed entities arent just dropped on the map, but spawned just like 1000 underpants builder gnomes would build them in a split of a second on the map load :P
-
I havent looked completely through the code, but the way I see it, a change to the renderer would require a client side change, if not a complete client recompile. Just an idea that could help: have it remember the default locations without reloading map in case the different layout doesnt fit, such as something in a brush. For saved blueprints, it will probably need to remember not only each buildings position in relationship to eachother, but also their relationship to a specific spot in the map, possibly the center. I dont know how well this would work, but it might be a good idea to have it store blueprints in the map's .pk3 , in order to keep blueprints from different maps separated and with their own map, as well as to not have it need to look elsewhere when it loads the map--maybe put them in the scripts folder?
-
For saved blueprints, it will probably need to remember not only each buildings position in relationship to eachother, but also their relationship to a specific spot in the map, possibly the center. I dont know how well this would work, but it might be a good idea to have it store blueprints in the map's .pk3 , in order to keep blueprints from different maps separated and with their own map, as well as to not have it need to look elsewhere when it loads the map--maybe put them in the scripts folder?
automatically add map name before the file name, so on ATCS
/loadblueprint myshittybase
would load atcs-myshittybase.bpt
-
sounds interesting and fun :)
but sounds confusing and hard to follow because of all those weird sentences going / and : with codes and stuff :-?
-
Some people may like using the same base for every map. I can just imagine "No, that base sucks... but it might be cool on such and such map in such and such room".
I wonder if base layouts could be considered copyrighted...
[Edit]
You used my base. Pay royalties or I'll sue!
-
I wonder if base layouts could be considered copyrighted...
[Edit]
You used my base. Pay royalties or I'll sue!
>Location: Detroit, MI
no, the rest of the world is not retarded ...
sounds interesting and fun :)
but sounds confusing and hard to follow because of all those weird sentences going / and : with codes and stuff :-?
you use those "weird sentences going / and : with codes and stuff" EVERY time you play tremulous, every time you press a button you sent one of those weird sentences to the server :). All the user will se would be 2-3 new buttons to press, thats all.
-
Sounds like RollerCoaster Tycoon and saving my roller-coaster design.
Best game ever btw.
-
I think it a little bit
I need /fly and /nobuildtime commands
for creating layouts easily
-
Absolutely fantastic idea!
I usually end up being :granger: because either my team has better fighters or because if I don't the base ends up using 60bp on eggs and then 24bp on floor trappers...
Also it would make sharing innovative (read: new, untested, crappy) bases SO much easier than the current demo/1000 screenshots :P
Finally, if it could be integrated with !designate somehow, that would be IDEAL. I see futures of "!forceblueprint awesomebase.bpt" (And the following server changes from admin abuse :P). Along these lines, "/callvote blueprint foo" might be pretty spiffy also.
I'm looking forward to this mod...
-
Har har, I coded this idea this morning. Look for a patch against SVN 872 later today ... and of course, in Balance mod rev 11. :)
-
I'm a troll!
-
2 things
1 talk about this in pms
2 there's already a patch for this, browse around, or play balance mod servers
-
tjw released a patch which is based on risujins
they load the same way
in risujins you get invisible buildables
in tjw's you get start in solid error
risujin's is more funny but quite abusive
tjws not abusive ... but less funny
(abuse=fun for me)
I am happy. thanks to both :D
-
(abuse=fun for me)
I am happy. thanks to both :D
Games are all about abuse. Doing things in virtual reality you would never have the balls to do in life. Like slapping random strangers! The more abuse, the better the game. 8)
-
Back in the day, D!ABLO wrote an entity editor mod for q3a, it saves and loads files with new entities in the standard text based .map format. It was open source, and included in the CPMA mod. It requires running a client side mod to save layouts, but in load only mode it is a server side mod.
For trem, the simplest way would be to view base variants as though they were whole new maps, even though they are just a text file which refer to a bsp, so you could callvote map ATCS, or callvote map ATCS_myLeetBases_version4.
Havent seen Risujin or tjw's versions, do they work in a similar way?
Also, plugging my old blueprint idea again in this thread.
It would be cool if you could lay down blueprints in game, not an automatic whole base layout, but something where you can run around 'fake building' very quickly to show other players where you would build if you werent out killing the enemy
There's no build delay at all but each blueprint costs cash, say 200cr / 1 evo. When someone comes along and builds on your blueprint, they get that cash. This way experienced players can help out newbs or late joiners who only have a ckit because they cant afford light armour.
-
you would never have the balls to [...] slap random strangers!
lies
Havent seen Risujin or tjw's versions, do they work in a similar way?
Any way you implement it would sort of be similar. So yes, I guess. But layouts aren't loaded with /map
There's no build delay at all but each blueprint costs cash, say 200cr / 1 evo. When someone comes along and builds on your blueprint, they get that cash.
So people could get free money for picking up a ckit and movin a couple turrets? Seems a little problematic.
-
Back in the day, D!ABLO wrote an entity editor mod for q3a, it saves and loads files with new entities in the standard text based .map format.
!layout saves to a plain text file. I think TJWs does too.
It requires running a client side mod to save layouts, but in load only mode it is a server side mod.
This sort of thing is server-side, no client modifications are necessary. The server has a full list of entities and saves them to a file on the server.
-
Did you miss the part about the blueprint costing cash to begin with?
Person with money goes, "There should be a turret here, I'll pay you do do it."
Noob with Ckit builds it, buys light armor and helmet.
Money does not come free, it is just redistributed.
-
the layout patch in svn
https://bugzilla.icculus.org/show_bug.cgi?id=2973
compilation of tjw's comments
svn891 g_layouts
server commands:
layoutsave LAYOUTNAME
saves the layout to layouts/MAPNAME/LAYOUTNAME.dat
layoutload LAYOUTNAME1 [ LAYOUTNAME2 [ LAYOUTNAME3 [ ... ] ] ]
loads at random one of the named layouts ( ones that exist )
cvars:
g_layouts [string]
This is a latched cvar that is a space sperated list of allowed
LAYOUTNAME's. If this is empty any layouts found by g_layoutAuto will
be used.
g_layoutAuto [1|0]
Determines whether or not the server should search for all valid layouts
and select one at random (default 1)
Specifying layouts with maprotation.cfg:
For server admins who want to disable certain layouts a map comes with,
or want to force only their own layouts, a primitive "layouts" has been
added to the maprotation.cfg file. For example:
rotation1
{
karith
atcs
{
layouts "tjw tjw2"
}
niveus
}
This would allow only the layouts named tjw and tjw2 to be used when the
map is started by the maprotation system.
Other changes:
* buildings are created instantly when cheats are enabled
* build timer is instant when cheats are enabled
This is to make creating a layout less tedious.
* add optional parameter to the !restart command "!restart [LAYOUTNAME]"
* add new !map command "!map MAPNAME [LAYOUTNAME]"
* add new !listlayouts command "!listlayouts [MAPNAME]"
I've added a special name for the map's built-in layout called "*BUILTIN*"
This name is added to the list for random selection and can be named in the
list of allowed layouts.
-
what about adding support for storing "disabled classes/upgrades/weapons" in the layout file
and with the support for triggers and targets . you can have a mission layout
-
i like how the first 5 posts of this thread yelled at vcx for trolling but this is one of the best features ever (well the one that you turn on and off allowing a person to buy tons of shit is at least)